howto get rid of 'pointer arguments differ in signedness' - Linux

This is a discussion on howto get rid of 'pointer arguments differ in signedness' - Linux ; Excuse me if this is still common knowledge, but there is reason to believe in the opposite ... Since gcc 4, gcc has acquired the annoying habit to warn about sign differences in pointed-to types, for instance, as in #include ...

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast
Results 1 to 20 of 49

Thread: howto get rid of 'pointer arguments differ in signedness'

  1. howto get rid of 'pointer arguments differ in signedness'

    Excuse me if this is still common knowledge, but there is reason to
    believe in the opposite ...

    Since gcc 4, gcc has acquired the annoying habit to warn about
    sign differences in pointed-to types, for instance, as in

    #include
    #include

    int main(void)
    {
    unsigned char buf[256];

    gets(buf); /* dear ld, this a toy example program */
    if (strcmp(buf, "abc") == 0) puts("def!");
    return 0;
    }

    When compiled with -Wall, this will result in the following output:

    a.c: In function 'main':
    a.c:8: warning: pointer targets in passing argument 1 of 'gets' differ in signedness
    a.c:9: warning: pointer targets in passing argument 1 of 'strcmp' differ in signedness
    /tmp/cc4kzfkW.o: In function `main':
    a.c.text+0x20): warning: the `gets' function is dangerous and should not be used.

    The idea of the gcc-team in this respect appears to be that everybody
    must change every ocurrence of a certain construct in all inherited
    sources whenever the gcc-team choses to (again) change the behaviour
    of its fscking 'product' (If you have the option of using a compiler
    whose developers have an interest in not causing their users needless
    troubles, you should certainly do so. With 4, the people that used
    to break random C++ sources differently with each release have
    apparently turned their attention to the C-compiler and this matter
    will get worse).

    If you are so unfortunate that you have to use 'linty freeware
    available on the internet' to compile large amounts of legacy code
    (and, like me, are using different releases of those 'linty
    freeware'), there is (at least there still is) a way to get rid of
    this nonsense. gcc is just a driver program that calls other binaries
    to perform the actual work in a way that is defined by a set of
    so-called 'spec strings', which describe what commandline switches
    need to be passed how to which programs. This mechansim can be used to
    selectively disable certain warnings for particular gcc versions.

    For gcc-4.1.2 on Debian stable, the procedure is (as root):

    cd /usr/lib/gcc/i486-linux-gnu/4.1.2
    gcc -dumpspecs >specs

    and then to add %{!Wpointer-sign:-Wno-pointer-sign} to the
    line below *cc1_options:. This will disable warnings about sign
    differences in pointed-to types unless specifically requested.






  2. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat writes:

    > Excuse me if this is still common knowledge, but there is reason to
    > believe in the opposite ...
    >
    > Since gcc 4, gcc has acquired the annoying habit to warn about
    > sign differences in pointed-to types, for instance, as in




    As far as I know, you've got three options:

    (1) fix the broken code that has escaped without warnings in older
    versions of gcc. Over the past decade or so, gcc has gotten
    increasingly strict about spotting errors like the one you're
    describing. I've got to confess I find it amusing that in a
    three-line (executeable code) toy example showing annoying gcc
    behavior, you've managed to create a buffer overflow, and spent
    more keystrokes complaining about the warning it gives you than it
    would have taken to fix it (fgets).

    (2) Use older versions of gcc that don't complain about code
    constructs that are likely to be buggy.

    (3) Ignore the warnings.

  3. Re: howto get rid of 'pointer arguments differ in signedness'

    Joe Pfeiffer writes:
    > Rainer Weikusat writes:
    >> Excuse me if this is still common knowledge, but there is reason to
    >> believe in the opposite ...
    >>
    >> Since gcc 4, gcc has acquired the annoying habit to warn about
    >> sign differences in pointed-to types, for instance, as in

    >
    >
    >
    > As far as I know, you've got three options:
    >
    > (1) fix the broken code that has escaped without warnings in older
    > versions of gcc. Since the code Over the past decade or so, gcc
    > has gotten increasingly strict about spotting errors like the
    > one you're describing.


    There are two replies to this, one based on practice and the other
    based on theory:

    a) the practical consideration: Most C-code existing on this
    planet has been written before gcc has chosen to output this
    particular noise warning. A compiler that can translate
    existing code (like iptables, for instance) is a much more
    useful tool than one that cannot. Additionally, the time spent
    changing old source code could be better spent solving new
    problems.

    b) the theoretical consideration: The code isn't broken to
    begin with, cf ISO/IEC 9899:1999, 6.3.1.3

    > I've got to confess I find it amusing that in a three-line
    > (executeable code) toy example showing annoying gcc behavior, you've
    > managed to create a buffer overflow, and spent more keystrokes
    > complaining about the warning it gives you than it would have taken
    > to fix it (fgets).


    The idea was to tell people like you that I am well aware of the gets
    documentation in the (vain) hope to stop them from posting a lot of
    noise like you the one above.

    [...]

    > (3) Ignore the warnings.


    That could be achieved very easily by not enabling them in the first
    place. Which isn't a good idea.

  4. Re: howto get rid of 'pointer arguments differ in signedness'

    Tim Southerwood writes:

    [...]


    > BUGS
    > Never use gets(). Because it is impossible to tell without knowing the
    > data in advance how many characters gets() will read, and because gets()
    > will continue to store characters past the end of the buffer, it is
    > extremely dangerous to use. It has been used to break computer security.
    >
    > Use fgets() instead.
    > ...
    > ###################
    >
    > Seems clear enough to me. Unfortunately, idiots continue using a library
    > routine that should never have existed *ever*. It is fundamentally broken,
    > always has been and always will be.


    It is totally adequate for use in an example intended to demonstrate
    something different. Or in all other kinds of throw-away code.

    [...]

    >> The idea of the gcc-team in this respect appears to be that everybody
    >> must change every ocurrence of a certain construct in all inherited
    >> sources whenever the gcc-team choses to (again) change the behaviour
    >> of its fscking 'product' (If you have the option of using a compiler
    >> whose developers have an interest in not causing their users needless
    >> troubles, you should certainly do so. With 4, the people that used
    >> to break random C++ sources differently with each release have
    >> apparently turned their attention to the C-compiler and this matter
    >> will get worse).
    >>

    >
    > I have three responses:
    >
    > 1) As a sysadmin,


    you would be well-advised to keep your mouth firmly shut here, because
    you are floating in territories beyond your expertise.

  5. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat writes:
    > >
    > > (1) fix the broken code that has escaped without warnings in older
    > > versions of gcc. Since the code Over the past decade or so, gcc
    > > has gotten increasingly strict about spotting errors like the
    > > one you're describing.

    >
    > There are two replies to this, one based on practice and the other
    > based on theory:
    >
    > a) the practical consideration: Most C-code existing on this
    > planet has been written before gcc has chosen to output this
    > particular noise warning. A compiler that can translate
    > existing code (like iptables, for instance) is a much more
    > useful tool than one that cannot. Additionally, the time spent
    > changing old source code could be better spent solving new
    > problems.


    Why is this warning different from any of the other warnings that gcc
    has started issuing that it didn't in the past, like type conflicts on
    stdio functions? Or is it your argument that the set of warnings
    issued by gcc should be set in stone and never changed?

    > b) the theoretical consideration: The code isn't broken to
    > begin with, cf ISO/IEC 9899:1999, 6.3.1.3


    That's why it's a warning and not a syntax error.

    > > I've got to confess I find it amusing that in a three-line
    > > (executeable code) toy example showing annoying gcc behavior, you've
    > > managed to create a buffer overflow, and spent more keystrokes
    > > complaining about the warning it gives you than it would have taken
    > > to fix it (fgets).

    >
    > The idea was to tell people like you that I am well aware of the gets
    > documentation in the (vain) hope to stop them from posting a lot of
    > noise like you the one above.


    And this was, of course, easier for you than just writing your example
    so it didn't have the error.
    >
    > > (3) Ignore the warnings.

    >
    > That could be achieved very easily by not enabling them in the first
    > place. Which isn't a good idea.


    But that's exactly what you're asking for. You want to turn on all
    warnings, and then have a particular warning you don't want to hear
    about not turn up. You really can't have it both ways.

  6. Re: howto get rid of 'pointer arguments differ in signedness'

    Joe Pfeiffer writes:
    > Rainer Weikusat writes:
    >> >
    >> > (1) fix the broken code that has escaped without warnings in older
    >> > versions of gcc. Since the code Over the past decade or so, gcc
    >> > has gotten increasingly strict about spotting errors like the
    >> > one you're describing.

    >>
    >> There are two replies to this, one based on practice and the other
    >> based on theory:
    >>
    >> a) the practical consideration: Most C-code existing on this
    >> planet has been written before gcc has chosen to output this
    >> particular noise warning. A compiler that can translate
    >> existing code (like iptables, for instance) is a much more
    >> useful tool than one that cannot. Additionally, the time spent
    >> changing old source code could be better spent solving new
    >> problems.

    >
    > Why is this warning different from any of the other warnings that gcc
    > has started issuing that it didn't in the past, like type conflicts on
    > stdio functions?


    This is a direction of discussion that doesn't really lead anywhere
    (except into areas to complicated for many people to understand and
    too theoretical for them to care about). Empirically, it has caused me to
    modify the compiler settings such that it is never displayed anymore.
    Ergo, it is different.

    [...]

    >> > I've got to confess I find it amusing that in a three-line
    >> > (executeable code) toy example showing annoying gcc behavior, you've
    >> > managed to create a buffer overflow, and spent more keystrokes
    >> > complaining about the warning it gives you than it would have taken
    >> > to fix it (fgets).

    >>
    >> The idea was to tell people like you that I am well aware of the gets
    >> documentation in the (vain) hope to stop them from posting a lot of
    >> noise like you the one above.

    >
    > And this was, of course, easier for you than just writing your example
    > so it didn't have the error.


    It was indeed easier to add the comment to the code I compiled and
    tested for the demonstration then it would have been to modify,
    recompile and retest this code for no particular reason (Never assume
    you didn't make a mistake, no matter how stupid. In hindsight,
    everything is obvious). Apart from this, since no specification of
    intended behaviour was provided, it is not possible if the code is
    erronous.

    >> > (3) Ignore the warnings.

    >>
    >> That could be achieved very easily by not enabling them in the first
    >> place. Which isn't a good idea.

    >
    > But that's exactly what you're asking for. You want to turn on all
    > warnings, and then have a particular warning you don't want to hear
    > about not turn up.


    So, obviously, that's not 'exactly what I am asking for' according to
    your own words.

    > You really can't have it both ways.


    I would like to 'have' compiler warnings that may be useful to me
    (eg the still-disabled -Wpointer-arith) and that don't routinely
    appear when translating 'de facto' standard constructs (like calling
    strcmp with one argument with an explicitly specified signedness and
    one argument with the 'default char signedness' and both happen to be
    different).

    Both of these preferences together basically imply that I have a set
    of 'warnings that are personally sensible for me' and the 'sensible
    warning set' for other people may well be different. Since 'spec
    files' are an occasionally very useful gcc-feature that is in the
    process of being removed (judging from the fate of other useful gcc
    features in the past [last 10 - 12 yrs]) and the existence of a
    'default specs file' is already just 'how the code behaves' I
    considered it desirable to explicitly document "something" about them.
    Hence the posting.

  7. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat wrote:

    > Tim Southerwood writes:
    >
    > [...]
    >
    >
    >> BUGS
    >> Never use gets(). Because it is impossible to tell without knowing the
    >> data in advance how many characters gets() will read, and because gets()
    >> will continue to store characters past the end of the buffer, it is
    >> extremely dangerous to use. It has been used to break computer security.
    >>
    >> Use fgets() instead.
    >> ...
    >> ###################
    >>
    >> Seems clear enough to me. Unfortunately, idiots continue using a library
    >> routine that should never have existed *ever*. It is fundamentally
    >> broken, always has been and always will be.

    >
    > It is totally adequate for use in an example intended to demonstrate
    > something different. Or in all other kinds of throw-away code.


    Fine. Accepted as an example.


    >>> The idea of the gcc-team in this respect appears to be that everybody
    >>> must change every ocurrence of a certain construct in all inherited
    >>> sources whenever the gcc-team choses to (again) change the behaviour
    >>> of its fscking 'product' (If you have the option of using a compiler
    >>> whose developers have an interest in not causing their users needless
    >>> troubles, you should certainly do so. With 4, the people that used
    >>> to break random C++ sources differently with each release have
    >>> apparently turned their attention to the C-compiler and this matter
    >>> will get worse).
    >>>

    >>
    >> I have three responses:
    >>
    >> 1) As a sysadmin,

    >
    > you would be well-advised to keep your mouth firmly shut here, because
    > you are floating in territories beyond your expertise.


    And exactly how would you claim to know that? Perhaps it's because you are
    an pompous buffoon who thinks that all the world exists to serve you? Do
    forgive me great master. We are not worthy.

    gcc is free. Don't like it, don't use it. Or pay them to do it your way.

    Now, when your proctologist has found your head, perhaps you would consider
    what I wrote about using an earlier version, or indeed what everyone else
    has been telling you - ignore the sodding warnings, because that's all they
    are.




  8. Re: howto get rid of 'pointer arguments differ in signedness'

    On Jun 6, 3:04 am, Rainer Weikusat wrote:

    > Since gcc 4, gcc has acquired the annoying habit to warn about
    > sign differences in pointed-to types, for instance, as in


    No, you *ASKED* it to do so.

    > When compiled with -Wall, this will result in the following output:


    You specifically chose to compile with '-Wall' which means you *ASKED*
    it to warn about anything that might potentially be an issue. If
    that's not what you wanted, why did you ask for it?

    Are you seriously arguing that if GCC acquires new sophisticated code
    analysis that can detect potential problems that it couldn't detect
    before, it should remain silent, even if all warnings are enabled?

    Perhaps we need a new GCC option "-Wall -
    Wireallymeantallwhenisaidall".

    DS


  9. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat writes:
    > Joe Pfeiffer writes:
    >
    > >> > (3) Ignore the warnings.
    > >>
    > >> That could be achieved very easily by not enabling them in the first
    > >> place. Which isn't a good idea.

    > >
    > > But that's exactly what you're asking for. You want to turn on all
    > > warnings, and then have a particular warning you don't want to hear
    > > about not turn up.

    >
    > So, obviously, that's not 'exactly what I am asking for' according to
    > your own words.


    Hey, you're the guy who said -Wall. If you didn't want all the
    warnings, you shouldn't have asked for them.

  10. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat wrote:

    > Excuse me if this is still common knowledge, but there is reason to
    > believe in the opposite ...
    >


    I usually strive for code that yelds no warning, because every one could be a
    bugs source. Anyway, couldn't you just add the -Wno-pointer-sign to the
    makefile? It could be disturbing, IMHO, using -Wall believing that every
    warning is issued and discover only hours later that, by default, it was
    disabled (i.e.: let's suppose someone else be programming on your machine).

    --
    SF

    "Spartani... mangiate tanto a colazione perchè stasera ceneremo nell'Ade!!"

  11. Re: howto get rid of 'pointer arguments differ in signedness'

    Dildo Baggins writes:

    > Rainer Weikusat wrote:
    >
    >> Excuse me if this is still common knowledge, but there is reason to
    >> believe in the opposite ...
    >>

    >
    > I usually strive for code that yelds no warning, because every one
    > could be a bugs source. Anyway, couldn't you just add the
    > -Wno-pointer-sign to the makefile? It could be disturbing, IMHO, using
    > -Wall believing that every warning is issued and discover only hours
    > later that, by default, it was disabled (i.e.: let's suppose someone
    > else be programming on your machine).


    -Wall doesn't actually enable all warnings. Try adding -Wextra to see
    some real pedantry.

    --
    Måns Rullgård
    mans@mansr.com

  12. Re: howto get rid of 'pointer arguments differ in signedness'

    Måns Rullgård wrote:

    > Dildo Baggins writes:
    >
    >
    >>Rainer Weikusat wrote:
    >>
    >>
    >>>Excuse me if this is still common knowledge, but there is reason to
    >>>believe in the opposite ...
    >>>

    >>
    >>I usually strive for code that yelds no warning, because every one
    >>could be a bugs source. Anyway, couldn't you just add the
    >>-Wno-pointer-sign to the makefile? It could be disturbing, IMHO, using
    >>-Wall believing that every warning is issued and discover only hours
    >>later that, by default, it was disabled (i.e.: let's suppose someone
    >>else be programming on your machine).

    >
    >
    > -Wall doesn't actually enable all warnings. Try adding -Wextra to see
    > some real pedantry.
    >


    Ok, but I guess my point is clear anyway. When you set -Wall you expect
    something that in your machine really behaves in a different way, since
    someone changed the spec file, and you could waste precious time before
    realize it.

    --
    SF

    "Spartani... mangiate tanto a colazione perchè stasera ceneremo nell'Ade!!"

  13. Re: howto get rid of 'pointer arguments differ in signedness'

    David Schwartz wrote:

    > Perhaps we need a new GCC option "-Wall -Wireallymeantallwhenisaidall".


    cf. -Wextra ;-)

    http://gcc.gnu.org/onlinedocs/gcc-4....ml#index-W-253

  14. Re: howto get rid of 'pointer arguments differ in signedness'

    David Schwartz writes:
    > On Jun 6, 3:04 am, Rainer Weikusat wrote:
    >> Since gcc 4, gcc has acquired the annoying habit to warn about
    >> sign differences in pointed-to types, for instance, as in

    >
    > No, you *ASKED* it to do so.


    No, I didn't *ASK* it to enable this particular warning. -Wall does
    not mean 'all warnings' but 'some subset of them the gcc developers
    consider exceptionally useful'. This subset has been changed, aka 'gcc
    developed the habit'.

    >> When compiled with -Wall, this will result in the following output:

    >
    > You specifically chose to compile with '-Wall' which means you *ASKED*
    > it to warn about anything that might potentially be an issue.


    That may be how you believe it to be, but not how it is.

    `-Wall'
    All of the above `-W' options combined. This enables all the
    warnings about constructions that some users consider
    questionable, and that are easy to avoid (or modify to prevent the
    warning),

    The all doesn't even theoretically mean 'all possible warnings', it
    means 'all warnings that have been documented so far'.

  15. Re: howto get rid of 'pointer arguments differ in signedness'

    Dildo Baggins writes:
    > Rainer Weikusat wrote:
    >> Excuse me if this is still common knowledge, but there is reason to
    >> believe in the opposite ...
    >>

    >
    > I usually strive for code that yelds no warning, because every one
    > could be a bugs source.


    There are actually arguments against using obfuscation tricks too
    'sophisticated' for the gcc code analyzer to silence pointless
    compilation noises. At least they ... well ... obfuscate the
    code.

    > Anyway, couldn't you just add the -Wno-pointer-sign to the makefile?


    The same way I could just change all the code I am using, could just
    maintain a compiler for x86 separate from the one included in the
    distribution I am using, could just ignore the warning, could just
    fork the compiler outright, could just write my own compiler etc.

    None of which is going to improve the behaviour of this compiler.



  16. Re: howto get rid of 'pointer arguments differ in signedness'

    Dildo Baggins writes:
    > Måns Rullgård wrote:


    [...]

    >>>I usually strive for code that yelds no warning, because every one
    >>>could be a bugs source. Anyway, couldn't you just add the
    >>>-Wno-pointer-sign to the makefile? It could be disturbing, IMHO, using
    >>>-Wall believing that every warning is issued and discover only hours
    >>>later that, by default, it was disabled (i.e.: let's suppose someone
    >>>else be programming on your machine).

    >> -Wall doesn't actually enable all warnings. Try adding -Wextra to
    >> see
    >> some real pedantry.
    >>

    >
    > Ok, but I guess my point is clear anyway. When you set -Wall you
    > expect something that in your machine really behaves in a different
    > way, since someone changed the spec file, and you could waste precious
    > time before realize it.


    Yes, you're point is perfectly clear. It means "users shouldn't
    customize preferences to suit their need but should stick to what
    developers have wiselty chosen for them".

    Which isn't a point worth discussing.

  17. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat wrote:

    > Yes, you're point is perfectly clear. It means "users shouldn't
    > customize preferences to suit their need but should stick to what
    > developers have wiselty chosen for them".
    >
    > Which isn't a point worth discussing.


    No, my point is "make clear what you are doing". So, use Makefile or whatever
    developing system you are using.

    --
    SF

    "Spartani... mangiate tanto a colazione perchè stasera ceneremo nell'Ade!!"

  18. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat wrote:

    >>Anyway, couldn't you just add the -Wno-pointer-sign to the makefile?

    >
    >
    > The same way I could just change all the code I am using, could just
    > maintain a compiler for x86 separate from the one included in the
    > distribution I am using, could just ignore the warning, could just
    > fork the compiler outright, could just write my own compiler etc.
    >


    Adding -Wno-pointer-sign is far less complicated than that.

    > None of which is going to improve the behaviour of this compiler.
    >


    What would be qualified as an improvement, then?

    --
    SF

    "Spartani... mangiate tanto a colazione perchè stasera ceneremo nell'Ade!!"

  19. Re: howto get rid of 'pointer arguments differ in signedness'

    Dildo Baggins writes:
    > Rainer Weikusat wrote:


    [...]

    >> None of which is going to improve the behaviour of this compiler.

    >
    > What would be qualified as an improvement, then?


    Not warning about correct strcmp-calls.

  20. Re: howto get rid of 'pointer arguments differ in signedness'

    Rainer Weikusat wrote:

    > Dildo Baggins writes:
    >
    >>Rainer Weikusat wrote:

    >
    >
    > [...]
    >
    >
    >>>None of which is going to improve the behaviour of this compiler.

    >>
    >>What would be qualified as an improvement, then?

    >
    >
    > Not warning about correct strcmp-calls.


    Maybe you should complain with the standard committee, since it's the C99
    standard that establish that chars, signed chars and unsigned chars are three
    different types. So, it's correct for the compiler to issue warnings since
    even pointers to chars, signed chars and unsigned chars are distinct types.

    --
    SF

    "Spartani... mangiate tanto a colazione perchè stasera ceneremo nell'Ade!!"

+ Reply to Thread
Page 1 of 3 1 2 3 LastLast