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 ; On Jun 11, 2:44 am, Rainer Weikusat wrote: > > 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 ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 49 of 49

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

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

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

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


    You are being an idiot. I don't know if it's intentional or
    accidental, but either way, it's very annoying.

    Even if the compiler has machine-specific features and extensions,
    it's entirely appropriate to warn when somebody might be using such
    things unintentionally. (With code that might mean somethign else on
    another platform.)

    DS



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

    David Schwartz writes:
    >
    > You are being an idiot. I don't know if it's intentional or
    > accidental, but either way, it's very annoying.


    You've got a *lot* more patience than I do.



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

    David Schwartz writes:
    > On Jun 11, 2:44 am, Rainer Weikusat wrote:
    >> > 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.

    >
    > You are being an idiot. I don't know if it's intentional or
    > accidental, but either way, it's very annoying.
    >
    > Even if the compiler has machine-specific features and extensions,
    > it's entirely appropriate to warn when somebody might be using such
    > things unintentionally. (With code that might mean somethign else on
    > another platform.)


    That's not you original claim (compiler was designed to accept only
    strictly conforming C programs), doesn't provide a reason for this
    claim and doesn't answer the question I posed above.

    To quote myself:

    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,

    Please read it this time.

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

    David Schwartz writes:
    > 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.


    I don't think so, because you keep arguing about something 'completely
    different'.

    > Compilers implement languages to specifications.


    Since the specification is ten years younger than 'the compiler',
    it cannot possibly have been this way.

    > Yes, they should build valid code where they can, but if code
    > violates the standards, it's entirely appropriate to issue a
    > warning,


    I haven't disputed that since I discovered the specific 'violation'
    here. I actually want to be informed about constructs with undefined
    semantics, as of C, even if they 'work', because I do not trust the
    people developing gcc to behave sensibly in this respect. They will
    break backwards compatibilty sooner or later because that is their
    normal mode of operation.

    > even if the code will always work they way you happen to expect on
    > the chosen platform.


    That is still not 'my expectation', but the way the code generator of
    this compiler was written to work (for this particular architecture/
    platform). I would go so far as to say that it is the only sensible
    way the code generator could work, because otherwise, it would be
    imposing artifical restrictions of a theoretical 'superset
    architecture' onto real architectures for no particular purpose.

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


    There is no issue with sensible interpretations here. char, signed
    char and unsigned char are three mutually incomaptible types,
    according to the ISO-C[99]-standard. This means that converting a
    pointer to one of them to another requires an explicit cast, insofar C
    is concerned and a program without such an explicit cast is no longer
    a strictly conforming C program. That's the specfication view.

    At the implementation level, the compiler knows how a pointer to some
    C type must 'look like' for the current target architecture. It must
    know this, because it is supposed to translate C code that doesn't
    contain the specific details into something executable on the
    processor of the current target. This means the compiler knows if the
    value of an unsigned char * (or of an long double *) can be
    substituted for the value of an char * (or an unsigned int *) such
    that it still makes sense for this processor. It can then chose to
    either just do so or to do so but emit a warning.

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

    On Jun 12, 1:21 am, Rainer Weikusat wrote:

    > That's not you original claim (compiler was designed to accept only
    > strictly conforming C programs), doesn't provide a reason for this
    > claim and doesn't answer the question I posed above.


    I never said the compiled was designed to accept only strictly
    conformin C programs. Only that it is very reasonable to emit a
    warning if a program might not be unintentionally not strictly
    conforming (even though the programmer might have thought it was).

    > To quote myself:
    >
    > 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,
    >
    > Please read it this time.


    That's not the part I disagree with.

    DS


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

    On Jun 10, 4:58 am, Rainer Weikusat wrote:

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


    You have the burden backwards. The burden is on the person who offered
    the code to demonstrate that the standards guarantee a particular
    outcome.

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


    This was your code:

    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;
    }

    It treats '-1' and '1' the same, they both fail the '== 0' test. So
    your code doesn't care whether 'strcmp' returns '1' or '-1'. However,
    it is unreasonable to expect the compiler to detect that.

    DS


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

    David Schwartz writes:
    > On Jun 10, 4:58 am, Rainer Weikusat wrote:
    >> > 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.

    >
    > You have the burden backwards. The burden is on the person who offered
    > the code to demonstrate that the standards guarantee a particular
    > outcome.


    [...]

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

    >
    > This was your code:
    >
    > 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;
    > }
    >
    > It treats '-1' and '1' the same, they both fail the '== 0' test. So
    > your code doesn't care whether 'strcmp' returns '1' or '-1'.
    > However, it is unreasonable to expect the compiler to detect that.


    This is besides the point (the issue is still 'undefined automatic
    pointer conversions') and 'the compiler' should most certainly
    'detect' the == 0 up there, because otherwise, it cannot translate
    it.

    The fact that some array was declared with the type 'unsigned char'
    still doesn't imply that objects stored in that array at some
    particular point in time would be negative numbers if interpreted as
    'char'.

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

    On Jun 13, 3:21 am, Rainer Weikusat wrote:

    > The fact that some array was declared with the type 'unsigned char'
    > still doesn't imply that objects stored in that array at some
    > particular point in time would be negative numbers if interpreted as
    > 'char'.


    Accessing data through a pointer to a type other than the one the data
    was stored under is always implementation-defined behavior. There is
    no case I can think of where a warning is not appropriate.

    In any event, all of your arguments boil down to, "there's a way this
    can be perfectly legitimate". Nobody disputes that. Warnings are for
    cases that might be perfectly legitimate but also might not be. Errors
    are for cases that cannot possibly be right.

    DS


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

    David Schwartz writes:
    > On Jun 13, 3:21 am, Rainer Weikusat wrote:
    >> The fact that some array was declared with the type 'unsigned char'
    >> still doesn't imply that objects stored in that array at some
    >> particular point in time would be negative numbers if interpreted as
    >> 'char'.

    >
    > Accessing data through a pointer to a type other than the one the data
    > was stored under is always implementation-defined behavior. There is
    > no case I can think of where a warning is not appropriate.


    A warning would not have been appropriate if its cause had been what
    you have been advocating so far, instead of the undefined pointer
    conversion.


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