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 ; Dildo Baggins writes: > 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? >> ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 49

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

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

    Dildo Baggins writes:
    > 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.


    Since 'compiler warnings' are not specified by ISO-C, the statement
    above is nonsense. After checking this with the C-standard,
    apparently, passing an unsigned char * to a function expecting a char
    * is undefined behaviour.

    But this is actually besides the point. It is possible to translate
    code that does this to 'something sensible' on all target
    architectures supported by Linux and that is the way this has always
    been handled. Lots and lots of existing software has been written
    under the assumption that mixing different pointers to character types
    results in nothing more than possibly interpreting the same bytes in
    different ways. The 'base question' is not 'is the new behaviour
    compliant to some paper specification' but 'what is useful
    behaviour'. 'Useful behaviour' is if the compiled code does what it
    was likely intended to do if at all possible. 'Not useful behaviour'
    is to force people to do cosmetic changes to known-to-be-working code
    in exchange for nothing.


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

    Rainer Weikusat writes:
    > 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.


    Clarfication to prevent spreading of disinformation:

    When calling a function with a prototype in scope, argument
    conversions happen 'as if by assignment' (6.5.2.2|7), pointer
    conversions require a cast except if the meet the constraints for
    simple assignment (6.5.4|3), the applicable 'constraint' is that
    both pointers must be pointers to compatible types (6.5.16|1) and the
    types char, unsigned char and signed char are not compatible (follows
    from 6.2.7, cf footnote 35).

    This means that

    unsigned char *xyz = "abc";

    (and anything similar) is a language construct whose behaviour is not
    defined by the ISO-C-standard (NB: This does not mean 'it is wrong',
    but 'it is not C', the same way 'Guten Tag' is not English, although
    it is pretty similar to 'good day').

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

    Tim S writes:
    > Rainer Weikusat wrote:
    >> Tim Southerwood writes:


    [...]

    >>> 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?


    It is pretty obvious from your posting. Eg, the only conceivable
    problem wrt using gets is that the responsibility for not overflowing
    the buffer rests on the thing that causes input to be generated. If
    some user runs a command-line program he can cause to segfault by
    feeding a more than a certain amount of data into it, that's kind-of
    ugly and certainly not a sensible interface design for application
    programs intended to be distributed for general use, but apart from
    that, it is totally harmless. Nothing to exploit here. In order for
    something to 'expoit' here, there must be the possibility of some
    privilege escalation, meaning, the program does run with privileges
    the user providing the input for it does not already have, and part of
    its intended function is to enable this user to do a specific
    operation that requires some kind of 'elevate privilege', confining
    the possibilities available to the user to just the operation
    intended.

    The classical example for this would be the fingerd daemon used during
    'the Morris Worm' in 1988. That was supposed to enable users without
    accounts on a particular system to get 'some information' about users
    logged into this other system. Because this particular finger daemon
    used gets to read input from an untrusted source on the network, a
    stack-smashing attack could be mounted against it, eventually yielding
    the ability to run arbitrary code on the sucessfully attacked system
    with the privileges associated with the uid the finger daemon ran as.

    [...]

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


    A statement like the above makes it fairly clear that maintenance of
    large amounts of legacy C-code without the time to do more than the
    absolutely necessary modifications to it, and that time given only
    very grudgingly ('Do you really need to do this? Doesn't it work?') is
    none of your problems, too. Which hardly brings you into the position
    of judging the impact of sudden changes in compiler behaviour
    that could have been avoided and yield no immediate benefit.

    Getting philosophical, for 'Free Software' to be sucessful, it must
    not only be 'free' as in 'cheap to acquire for people who are not
    affected by the problems arising from its use', but actually useful to
    the people that use it. "**** off and die, I don't care about YOUR
    PROBLEMS" isn't exactly an efficient way of ensuring this, even if
    worded much mor cozy.



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

    Rainer Weikusat wrote:

    > The 'base question' is not 'is the new behaviour
    > compliant to some paper specification' but 'what is useful
    > behaviour'. 'Useful behaviour' is if the compiled code does what it
    > was likely intended to do if at all possible. 'Not useful behaviour'
    > is to force people to do cosmetic changes to known-to-be-working code
    > in exchange for nothing.
    >


    Not correct: gcc is not forcing you to make any change, since the warning you
    are arguing about is just a warning (and not an error) that, you proved, can
    be quieted without any harm. To me, more warning do are 'useful behaviour', if
    they can help me writing more portable code, provided that my target is
    writing portable code, or prevent suble bugs. 'doing what was likely intended
    to do' is a personal concept that nothing has to do with an ANSI C99 compliant
    compiler and with machine computation in general.

    --
    SF

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

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

    On 2007-06-07, 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.


    Using unsigned or signed char* with strcmp() yeilds
    implementation-defined behavior. (whenever the first difference is a
    high bit)

    This is a potential source of bugs (if you're using the comparison to
    determine ordering, and not just as an equality test)

    It's perfectly reasonable to warn.

    Bye.
    Jasen

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

    Dildo Baggins writes:
    > Rainer Weikusat wrote:
    >> The 'base question' is not 'is the new behaviour
    >> compliant to some paper specification' but 'what is useful
    >> behaviour'. 'Useful behaviour' is if the compiled code does what it
    >> was likely intended to do if at all possible. 'Not useful behaviour'
    >> is to force people to do cosmetic changes to known-to-be-working code
    >> in exchange for nothing.

    >
    > Not correct:


    For every text I write, you will be able to construct a
    'misunderstanding' that matches the wording.

    > gcc is not forcing you to make any change, since the
    > warning you are arguing about is just a warning (and not an error)


    By virtue of it being a device, nothing originating from a computer
    itself actually 'forces' me to do anything, because device isn't
    operating on its own intention. It is nevertheless useful to describe
    certain aspects of its operation as if it would, to facilitate easier
    understanding of them by humans.

    > that, you proved, can be quieted without any harm.


    Would like to have it both ways, do we? "First, no action is
    necessary, second, the action is trivial", aka "there hasn't been a
    car here and it wasn't green"?

    > To me, more warning do are 'useful behaviour', if they can help me
    > writing more portable code, provided that my target is writing
    > portable code,


    Can you distill that down to an actual statement, instead of a string
    of possibilites?

    > 'doing what was likely intended to do' is a personal concept
    > that nothing has to do with an ANSI C99 compliant compiler and
    > with machine computation in general.


    Warning: You have got the references wrong. This may change semantics.

    I hope to above helps 'somebody' to avoid the subtle bug you have
    included here.

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

    Jasen writes:
    > On 2007-06-07, 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.

    >
    > Using unsigned or signed char* with strcmp() yeilds
    > implementation-defined behavior. (whenever the first difference is a
    > high bit)


    The behaviour is actually undefined.

    [...]

    > It's perfectly reasonable to warn.


    A warning that appears 'out of the blue' with a new compiler version,
    doesn't tell anything of interest about properties of the
    generated machine code and has no documentation regarding its likely
    intent is about as 'unreasonable' as it can get.



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

    Rainer Weikusat wrote:

    > Dildo Baggins writes:
    >
    >>Rainer Weikusat wrote:
    >>
    >>>The 'base question' is not 'is the new behaviour
    >>>compliant to some paper specification' but 'what is useful
    >>>behaviour'. 'Useful behaviour' is if the compiled code does what it
    >>>was likely intended to do if at all possible. 'Not useful behaviour'
    >>>is to force people to do cosmetic changes to known-to-be-working code
    >>>in exchange for nothing.

    >>
    >>Not correct:

    >
    >
    > For every text I write, you will be able to construct a
    > 'misunderstanding' that matches the wording.
    >


    Yes, but I promise to not take advantage from it.

    >
    >>gcc is not forcing you to make any change, since the
    >>warning you are arguing about is just a warning (and not an error)

    >
    > By virtue of it being a device, nothing originating from a computer
    > itself actually 'forces' me to do anything, because device isn't
    > operating on its own intention. It is nevertheless useful to describe
    > certain aspects of its operation as if it would, to facilitate easier
    > understanding of them by humans.
    >


    Ok, but it's not forcing you to do anything anyway, because your source code
    can actually be compiled. With brand new annoying warnings, I'll concede it.

    >
    >>that, you proved, can be quieted without any harm.

    >
    > Would like to have it both ways, do we? "First, no action is
    > necessary, second, the action is trivial", aka "there hasn't been a
    > car here and it wasn't green"?
    >


    For every statement I write, you will be able to remove part of it to put in
    my finger something I didn't write. But, in the hope you will miss this chance
    in your following round, I'll restate it: Action is necessary IF and only IF
    you can't live with the warnings.

    >
    >>To me, more warning do are 'useful behaviour', if they can help me
    >>writing more portable code, provided that my target is writing
    >>portable code,

    >
    >
    > Can you distill that down to an actual statement, instead of a string
    > of possibilites?
    >


    "cast discards 'const' from pointer target type" is a warning that helps
    writing portable code.

    --
    SF

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

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

    Dildo Baggins writes:

    > Rainer Weikusat wrote:
    >
    >> Dildo Baggins writes:
    >>
    >>>Rainer Weikusat wrote:
    >>>
    >>>>The 'base question' is not 'is the new behaviour
    >>>>compliant to some paper specification' but 'what is useful
    >>>>behaviour'. 'Useful behaviour' is if the compiled code does what it
    >>>>was likely intended to do if at all possible. 'Not useful behaviour'
    >>>>is to force people to do cosmetic changes to known-to-be-working code
    >>>>in exchange for nothing.
    >>>
    >>>Not correct:

    >> For every text I write, you will be able to construct a
    >> 'misunderstanding' that matches the wording.
    >>

    >
    > Yes, but I promise to not take advantage from it.


    Guess what? You cannot.

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

    Rainer Weikusat wrote:

    >>>For every text I write, you will be able to construct a
    >>>'misunderstanding' that matches the wording.
    >>>

    >>
    >>Yes, but I promise to not take advantage from it.

    >
    > Guess what? You cannot.


    I kept my word, did I?

    --
    SF

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

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

    On Jun 8, 1:45 am, Rainer Weikusat wrote:

    > A warning that appears 'out of the blue' with a new compiler version,


    This is the case whenever new functionality makes it possible to
    detect new problems that weren't previously detectable.

    > doesn't tell anything of interest about properties of the
    > generated machine code


    It does. It tells you that the resulting machine code may depend on
    implementation-specified behavior where it is not always obvious that
    this is the case.

    > and has no documentation regarding its likely
    > intent is about as 'unreasonable' as it can get.


    It's pretty obvious, at least to me, that the two most common problems
    would be that comparisons won't work the way you expect or that you
    may get negative values in a case where you didn't expect them.

    The warning appears sufficiently detailed to me in itself. I don't
    think bad documentation elsewhere can render compiler behavior
    reasonable or unreasonable in a context like this one.

    DS


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

    On Jun 7, 6:22 am, Rainer Weikusat wrote:

    > Not warning about correct strcmp-calls.


    Are they correct? Are you sure there aren't cases where one compiler
    could legally return '1' for a comparison and another compiler could
    also perfectly legally return '-1'? If that's not worth warning about,
    then pretty much nothing is.

    Or are you suggesting the compiler should notice that your code treats
    '1' and '-1' the same and ignore the fact that which value is returned
    is not well specified?

    DS


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

    David Schwartz writes:
    > On Jun 7, 6:22 am, Rainer Weikusat wrote:
    >> Not warning about correct strcmp-calls.

    >
    > Are they correct? Are you sure there aren't cases where one compiler
    > could legally return '1' for a comparison and another compiler could
    > also perfectly legally return '-1'?


    Are you sure that such a case exists? If so, please name it.

    > Or are you suggesting the compiler should notice that your code treats
    > '1' and '-1' the same


    Which code I have posted here treated '1' and '-1' 'the same' and what
    are you up to?

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

    David Schwartz writes:
    > On Jun 8, 1:45 am, Rainer Weikusat wrote:
    >> A warning that appears 'out of the blue' with a new compiler version,

    >
    > This is the case whenever new functionality makes it possible to
    > detect new problems that weren't previously detectable.


    There is not problem that could be 'detected' here. Except the
    possible future problem that somebody could chose to change code
    generator of gcc to no longer just translate such a call, purposely
    breaking backward compatiblity (like gcc 4.2 with default optimization
    settings pretending that signed integers as represented on a common
    CPU were actually an infinite set instead of what they actually are).

    >> doesn't tell anything of interest about properties of the
    >> generated machine code

    >
    > It does. It tells you that the resulting machine code may depend on
    > implementation-specified behavior where it is not always obvious that
    > this is the case.


    First, the likely reason for this warning is that automatic conversions
    from unsigned char * to char * are not supposed to happen, according
    to ISO-C. But this is not 'implementation specified' but simply
    undefined. Second, 'the generated machine code' is not something that
    'may' have certain properties, but something which has certain
    (observable) properties. And the 'observable property' is that the
    gcc-4.1.2 code generator continues to treat this case like it has
    always treated it in the past. No architecture supported by Linux
    cares about 'these types of distinctions' for pointer types and
    consequently, the compiler just translates them, thereby exposing (and
    utilizing) that fact that the properties of the architecture are a
    superset of the properties of the 'abstract machine' used to define
    the semantics of the C programming language. Which is IMO the right
    thing, because people are not programming this 'abstract machine' but
    certain sets of 'real machines' and should have the option to write
    code that is 'less portable' as strictly-conforming ISO-C would be,
    where this isn't a problem and there is some gain by expoiting
    properties of the actual target architectures.

    >> and has no documentation regarding its likely
    >> intent is about as 'unreasonable' as it can get.

    >
    > It's pretty obvious, at least to me, that the two most common problems
    > would be that comparisons won't work the way you expect or that you
    > may get negative values in a case where you didn't expect them.


    [...]

    > The warning appears sufficiently detailed to me in itself.


    Since your text is a nice demonstration of how completely you
    misunderstood it, it speaks for itself in this respect.

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

    David Schwartz writes:

    [...]

    > It's pretty obvious, at least to me, that the two most common problems
    > would be that comparisons won't work the way you expect or that you
    > may get negative values in a case where you didn't expect them.


    To maybe prevent someone else from falling into this trap: strcmp (and
    all other str*-routines in the standard C library) takes an argument
    of type 'char const *'. Since the signedness of char is implementation
    defined (gcc default is usually what 'the traditional choice' for a
    particular target architecture was and there's a command line switch
    to change that), one can usually not assume to get a 'numerically
    sensible' result from strcmp when the character arrays it compares
    contain originally 'unsigned' values whose representation requires the
    bit that would be the sign bit for signed chars. But that's a property
    of the data passed into the routine, not of the type of pointer used
    to do so (an unsigned char * doesn't necessarily point to a string
    containing bytes with a value >= 128 [for 8-bit-chars]).

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

    On Jun 10, 5:17 am, Rainer Weikusat wrote:

    > Second, 'the generated machine code' is not something that
    > 'may' have certain properties, but something which has certain
    > (observable) properties. And the 'observable property' is that the
    > gcc-4.1.2 code generator continues to treat this case like it has
    > always treated it in the past. No architecture supported by Linux
    > cares about 'these types of distinctions' for pointer types and
    > consequently, the compiler just translates them, thereby exposing (and
    > utilizing) that fact that the properties of the architecture are a
    > superset of the properties of the 'abstract machine' used to define
    > the semantics of the C programming language.


    I completely and totally disagree with this viewpoint and I imagine
    the GCC authors and maintainers likely would as well. They don't give
    a damn about what architectures are supposed by Linux and design their
    compilers to be architecture-agnostic when it comes to how they
    translate pure C code and what warnings they generate.

    > Which is IMO the right
    > thing, because people are not programming this 'abstract machine' but
    > certain sets of 'real machines' and should have the option to write
    > code that is 'less portable' as strictly-conforming ISO-C would be,
    > where this isn't a problem and there is some gain by expoiting
    > properties of the actual target architectures.


    How does they're generating a warning that your code is less portable
    stop you from writing it?

    > > The warning appears sufficiently detailed to me in itself.


    > Since your text is a nice demonstration of how completely you
    > misunderstood it, it speaks for itself in this respect.


    You are looking at this from the completely wrong perspective. You
    have fed pure C code into a C compiler. What platforms *you* care
    about have nothing to do with anything. The compiler has every reason
    to warn you if you're code is not as portable as it has every right to
    assume you expect it to be.

    The fact that *you* know your code is safe on the platforms *you* care
    about is not something you can reasonably expect the compiler to
    assume.

    DS


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

    On Jun 10, 6:05 am, Rainer Weikusat wrote:
    > But that's a property
    > of the data passed into the routine, not of the type of pointer used
    > to do so (an unsigned char * doesn't necessarily point to a string
    > containing bytes with a value >= 128 [for 8-bit-chars]).


    You are looking at this from a totally unreasonable perspective. I
    don't know what else to say.

    The compiler was not designed from your particular view. It was
    designed from the standpoint of being fed C code written for an
    abstract machine. The warning is 100% appropriate.

    DS


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

    David Schwartz writes:
    > On Jun 10, 6:05 am, Rainer Weikusat wrote:
    >> But that's a property
    >> of the data passed into the routine, not of the type of pointer used
    >> to do so (an unsigned char * doesn't necessarily point to a string
    >> containing bytes with a value >= 128 [for 8-bit-chars]).

    >
    > You are looking at this from a totally unreasonable perspective. I
    > don't know what else to say.


    That could maybe be caused by you being totally off into wonderland and
    purposely refusing to come back.

    > The compiler was not designed from your particular view.


    My text contained nothing that could meaningfully be described as 'my
    particular view' but an explanation of the inherent issues with using
    types of unspecified signedness for comparions. strcmp cannot
    'portably' be used to compare 'binary' strings and this was never any
    different. This issue is totally orthogonal to the question of
    'pointer signedness', because it is related to the values contained in
    the memory areas inspected by strcmp.

    > It was designed from the standpoint of being fed C code written for an
    > abstract machine.


    Please cite a reference proving this (absurd) claim. And please answer
    the question how a compiler can be 'designed to accept only strictly
    conforming C source code' and incorporate both machine-specific
    features and extensions to C.

    > The warning is 100% appropriate.


    As I have already written a couple of times: The C language does not
    allow for automatic conversion of unsigned char * to char * (or
    between any other pair of different pointers to character
    types). Doing so violates a shall-constraint (I have actually quoted
    the constraint in another posting) and is therefore undefined
    behaviour. The implies that the warning at least isn't totally
    useless, or, more correctly, if the person who added it had taken the
    time to additionally document why the warning is generated, wouldn't
    be totally useless.

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

    David Schwartz writes:
    > On Jun 10, 5:17 am, Rainer Weikusat wrote:
    >> Second, 'the generated machine code' is not something that
    >> 'may' have certain properties, but something which has certain
    >> (observable) properties. And the 'observable property' is that the
    >> gcc-4.1.2 code generator continues to treat this case like it has
    >> always treated it in the past. No architecture supported by Linux
    >> cares about 'these types of distinctions' for pointer types and
    >> consequently, the compiler just translates them, thereby exposing (and
    >> utilizing) that fact that the properties of the architecture are a
    >> superset of the properties of the 'abstract machine' used to define
    >> the semantics of the C programming language.

    >
    > I completely and totally disagree with this viewpoint and I imagine
    > the GCC authors and maintainers likely would as well.


    Instead of 'imageing' what other people may or may not think (with
    this 'imaginiation' being contrary to the way things actually are),
    why don't you provide some argument supporting your 'total
    disagreement' with the idea that C-compilers should support
    programming actually existing computers. After all, this is somewhat
    of a weird statement, especially in a newsgroup whose topic presumably
    is doing this very thing which you would prefer to be impossible for
    some unknown reason.

    [...]

    >> Which is IMO the right thing, because people are not programming
    >> this 'abstract machine' but certain sets of 'real machines' and
    >> should have the option to write code that is 'less portable' as
    >> strictly-conforming ISO-C would be, where this isn't a problem and
    >> there is some gain by expoiting properties of the actual target
    >> architectures.

    >
    > How does they're generating a warning that your code is less portable
    > stop you from writing it?


    I have never made the claim implied by your question above.

    >> > The warning appears sufficiently detailed to me in itself.

    >
    >> Since your text is a nice demonstration of how completely you
    >> misunderstood it, it speaks for itself in this respect.

    >
    > You are looking at this from the completely wrong perspective. You
    > have fed pure C code into a C compiler. What platforms *you* care
    > about have nothing to do with anything. The compiler has every reason
    > to warn you if you're code is not as portable as it has every right to
    > assume you expect it to be.
    >
    > The fact that *you* know your code is safe on the platforms *you* care
    > about is not something you can reasonably expect the compiler to
    > assume.


    The compiler knows that this code is safe on that particular platform
    and that's why it generates working machine code from it.

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

    On Jun 11, 2:53 am, Rainer Weikusat wrote:

    > Instead of 'imageing' what other people may or may not think (with
    > this 'imaginiation' being contrary to the way things actually are),
    > why don't you provide some argument supporting your 'total
    > disagreement' with the idea that C-compilers should support
    > programming actually existing computers. After all, this is somewhat
    > of a weird statement, especially in a newsgroup whose topic presumably
    > is doing this very thing which you would prefer to be impossible for
    > some unknown reason.


    > The compiler knows that this code is safe on that particular platform
    > and that's why it generates working machine code from it.


    I understand your point, I just completely disagree with it. Compilers
    implement languages to specifications. Yes, they should build valid
    code where they can, but if code violates the standards, it's entirely
    appropriate to issue a warning, even if the code will always work they
    way you happen to expect on the chosen platform.

    Even if there is only one sensible interpretation on the platform you
    are using, the compiler has no way to know whether the code was
    written *FOR* that platform. So the code may be broken on that
    platform, as it may have been written for a platform that had only one
    sensible interpretation, but one different from this platform.

    DS


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