conversion from const type* to type* allowed?

Discussion in 'C Programming' started by Michal Nazarewicz, Jan 4, 2007.

  1. The following code compiles fine (with warnings though) under GCC with
    -pedantic and -ansi arguments:

    #v+
    int main(void) {
    const int a = 0;
    int *p = &a;
    return 0;
    }
    #v-

    so am I missing something, GCC is buggy or it is really allowed to
    convert a pointer to const type to pointer to type?

    --
    Best regards, _ _
    .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
    ..o | Computer Science, Michal "mina86" Nazarewicz (o o)
    ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
     
    Michal Nazarewicz, Jan 4, 2007
    #1
    1. Advertising

  2. Michal Nazarewicz

    Ian Collins Guest

    Michal Nazarewicz wrote:
    > The following code compiles fine (with warnings though) under GCC with
    > -pedantic and -ansi arguments:
    >
    > #v+
    > int main(void) {
    > const int a = 0;
    > int *p = &a;
    > return 0;
    > }
    > #v-
    >
    > so am I missing something, GCC is buggy or it is really allowed to
    > convert a pointer to const type to pointer to type?
    >

    Const is broken in C, that's why one shouldn't ignore compiler warnings!

    --
    Ian Collins.
     
    Ian Collins, Jan 4, 2007
    #2
    1. Advertising

  3. Michal Nazarewicz

    Eric Sosman Guest

    Michal Nazarewicz wrote On 01/04/07 15:55,:
    > The following code compiles fine (with warnings though) under GCC with
    > -pedantic and -ansi arguments:
    >
    > #v+
    > int main(void) {
    > const int a = 0;
    > int *p = &a;
    > return 0;
    > }
    > #v-
    >
    > so am I missing something, GCC is buggy or it is really allowed to
    > convert a pointer to const type to pointer to type?


    From back to front: It is not allowed, GCC is not buggy
    (not in this regard, anyway), and you are in fact missing
    something. What you're missing is that the C Standard makes
    no distinction between error messages, warning messages,
    informative messages, and spirit messages from the Great
    Beyond: They are all merely "diagnostics." Once the compiler
    has emitted a "diagnostic" for the erroneous construct, it
    is under no obligation to halt compilation or reject the
    program[*], it may (if it feels like it) emit the diagnostic
    and translate the program anyhow.

    There's a GCC option ("-Werror"?) that turns "warnings"
    into "fatal errors" if you prefer.

    [*] Exception: The compiler is required to reject a
    module containing a non-suppressed #error directive.


    --
     
    Eric Sosman, Jan 4, 2007
    #3
  4. Michal Nazarewicz <> writes:
    > The following code compiles fine (with warnings though) under GCC with
    > -pedantic and -ansi arguments:
    >
    > #v+
    > int main(void) {
    > const int a = 0;
    > int *p = &a;
    > return 0;
    > }
    > #v-
    >
    > so am I missing something, GCC is buggy or it is really allowed to
    > convert a pointer to const type to pointer to type?


    The implicit conversion is a constraint violation. A conforming
    compiler's only obligation in the presence of a constraint violation
    is to issue a diagnostic. gcc meets this requirement by printing a
    warning.

    The only case where a compiler is actually required to reject a
    translation unit is when it contains a "#error" directive.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 4, 2007
    #4
  5. Michal Nazarewicz

    Al Balmer Guest

    On Thu, 04 Jan 2007 21:55:28 +0100, Michal Nazarewicz <>
    wrote:

    >The following code compiles fine (with warnings though)


    If it had warnings, it did not compile fine. Just remember that the
    compiler is actually too dumb to know the difference between a serious
    error and a trivial one, though it like to pretend it does.

    Strive to have all your programs compile cleanly without errors or
    warnings. There are cases where warnings can be ignored*, but only if
    you understand exactly what caused them and know for a fact that it
    won't be a problem.

    *One which comes to mind is an HP-UX warning that is issued whenever
    you use "const". It just tells you that using const improperly is bad,
    without knowing whether your usage was bad or not <g>.

    > under GCC with
    >-pedantic and -ansi arguments:
    >
    >#v+
    >int main(void) {
    > const int a = 0;
    > int *p = &a;
    > return 0;
    >}
    >#v-
    >
    >so am I missing something, GCC is buggy or it is really allowed to
    >convert a pointer to const type to pointer to type?


    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, Jan 4, 2007
    #5
  6. Al Balmer said:

    <snip>

    > Strive to have all your programs compile cleanly without errors or
    > warnings. There are cases where warnings can be ignored*, but only if
    > you understand exactly what caused them and know for a fact that it
    > won't be a problem.


    Perhaps "overruled" would be a better word than "ignored". When gcc tells me
    that I've only partly initialised an aggregate object - e.g. mystruct s =
    {0}; - I take due note of the warning, and check that the initialisation is
    correct. Actually, this is such a frequent occurrence that I suppose
    "ignored" is pretty accurate in that case, so let me find a different
    example (taken from real code this time):

    Dest->n = in & 0xff;

    Dest->n has type unsigned char. in is a long int (which, incidentally, is
    known to be non-negative by this stage in the proceedings). By the rules of
    C, in & 0xff must must must must must be in the range of unsigned char, so
    I know for sure that it will fit into Dest->n - and yet one of my
    compilers issues a diagnostic message saying that information might be lost
    in this assignment. It can't possibly be - but the compiler isn't quite
    bright enough to work this out, so it warns me.

    And it's a reasonable warning, on the whole. So I let the compiler warn me,
    and I look at the warning, and I check that it really is okay. If it is, I
    may add a comment to the code to save me a little time next time through,
    but by paying attention to the warning at least the first time it appears,
    I have given myself the opportunity to check out a potential bug.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Jan 4, 2007
    #6
  7. Michal Nazarewicz

    Al Balmer Guest

    On Thu, 04 Jan 2007 21:57:24 +0000, Richard Heathfield
    <> wrote:

    >Al Balmer said:
    >
    ><snip>
    >
    >> Strive to have all your programs compile cleanly without errors or
    >> warnings. There are cases where warnings can be ignored*, but only if
    >> you understand exactly what caused them and know for a fact that it
    >> won't be a problem.

    >
    >Perhaps "overruled" would be a better word than "ignored".


    I agree. I'll remember that the next time I give that speech :)

    --
    Al Balmer
    Sun City, AZ
     
    Al Balmer, Jan 4, 2007
    #7
  8. Eric Sosman wrote:
    > Michal Nazarewicz wrote On 01/04/07 15:55,:
    > > The following code compiles fine (with warnings though) under GCC with
    > > -pedantic and -ansi arguments:

    <snip>
    > ... The compiler is required to reject a
    > module containing a non-suppressed #error directive.


    That is true of C99, but rejection under #error is not a requirement of
    C90
    implementations. However, the C90 implementation the OP is using will.

    --
    Peter
     
    Peter Nilsson, Jan 5, 2007
    #8
  9. Al Balmer <> writes:

    > On Thu, 04 Jan 2007 21:55:28 +0100, Michal Nazarewicz <>
    > wrote:
    >
    >>The following code compiles fine (with warnings though)

    >
    > If it had warnings, it did not compile fine.


    True and I always check all the warnings compiler gives me but at this
    point I was shocked that compiler generated an executable where
    implicit conversion from pointer to const type to pointer to type was
    done.

    --
    Best regards, _ _
    .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
    ..o | Computer Science, Michal "mina86" Nazarewicz (o o)
    ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
     
    Michal Nazarewicz, Jan 5, 2007
    #9
  10. Eric Sosman <> writes:

    > Michal Nazarewicz wrote On 01/04/07 15:55,:
    >> The following code compiles fine (with warnings though) under GCC with
    >> -pedantic and -ansi arguments:
    >>
    >> #v+
    >> int main(void) {
    >> const int a = 0;
    >> int *p = &a;
    >> return 0;
    >> }
    >> #v-
    >>
    >> so am I missing something, GCC is buggy or it is really allowed to
    >> convert a pointer to const type to pointer to type?

    >
    > From back to front: It is not allowed, GCC is not buggy
    > (not in this regard, anyway), and you are in fact missing
    > something. What you're missing is that the C Standard makes
    > no distinction between error messages, warning messages,
    > informative messages, and spirit messages from the Great
    > Beyond: They are all merely "diagnostics." Once the compiler
    > has emitted a "diagnostic" for the erroneous construct, it
    > is under no obligation to halt compilation or reject the
    > program[*], it may (if it feels like it) emit the diagnostic
    > and translate the program anyhow.


    Thanks for explanation, I wasn't aware of such behaviour even though
    it sounds rather strange to me.

    > There's a GCC option ("-Werror"?) that turns "warnings"
    > into "fatal errors" if you prefer.


    That'd be too much. I use a -Wpadded switch which produces warnings
    that some of them are to be ignored.

    --
    Best regards, _ _
    .o. | Liege of Serenly Enlightened Majesty of o' \,=./ `o
    ..o | Computer Science, Michal "mina86" Nazarewicz (o o)
    ooo +--<mina86*tlen.pl>---<jid:mina86*chrome.pl>--ooO--(_)--Ooo--
     
    Michal Nazarewicz, Jan 5, 2007
    #10
  11. Michal Nazarewicz

    jaysome Guest

    On Thu, 04 Jan 2007 21:57:24 +0000, Richard Heathfield
    <> wrote:

    >Al Balmer said:
    >
    ><snip>
    >
    >> Strive to have all your programs compile cleanly without errors or
    >> warnings. There are cases where warnings can be ignored*, but only if
    >> you understand exactly what caused them and know for a fact that it
    >> won't be a problem.

    >
    >Perhaps "overruled" would be a better word than "ignored". When gcc tells me
    >that I've only partly initialised an aggregate object - e.g. mystruct s =
    >{0}; - I take due note of the warning, and check that the initialisation is
    >correct. Actually, this is such a frequent occurrence that I suppose
    >"ignored" is pretty accurate in that case, so let me find a different
    >example (taken from real code this time):
    >
    > Dest->n = in & 0xff;
    >
    >Dest->n has type unsigned char. in is a long int (which, incidentally, is
    >known to be non-negative by this stage in the proceedings). By the rules of
    >C, in & 0xff must must must must must be in the range of unsigned char, so
    >I know for sure that it will fit into Dest->n - and yet one of my
    >compilers issues a diagnostic message saying that information might be lost
    >in this assignment. It can't possibly be - but the compiler isn't quite
    >bright enough to work this out, so it warns me.
    >
    >And it's a reasonable warning, on the whole. So I let the compiler warn me,
    >and I look at the warning, and I check that it really is okay. If it is, I
    >may add a comment to the code to save me a little time next time through,
    >but by paying attention to the warning at least the first time it appears,
    >I have given myself the opportunity to check out a potential bug.


    I'd take charge of the matter and get rid of the compiler warning
    altogether. You could get rid of it this way:

    Dest->n = (unsigned char)(in & 0xff);

    You could also get rid of it using compiler-specific pragmas, for
    example:

    #ifdef _MSC_VER
    #pragma warning(disable:4244)
    #endif
    Dest->n = in & 0xff;
    #ifdef _MSC_VER
    #pragma warning(default:4244)
    #endif

    I'd choose the former, since it is much easier to implement, and I
    know what I'm doing, and a cast in this case is worth getting rid of
    the bogus compiler warning.

    --
    jay
     
    jaysome, Jan 5, 2007
    #11
  12. Richard Heathfield <> wrote:

    > Perhaps "overruled" would be a better word than "ignored".


    int *foo=42;

    "Objection, your honor! This construct makes a pointer from an
    integer without a cast!"

    Sometimes overruling the objections of the General Compiler Council
    can be cause for disbarment :)

    --
    C. Benson Manica | I *should* know what I'm talking about - if I
    cbmanica(at)gmail.com | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Jan 5, 2007
    #12
  13. jaysome said:

    <snip>

    > I'd take charge of the matter and get rid of the compiler warning
    > altogether. You could get rid of it this way:
    >
    > Dest->n = (unsigned char)(in & 0xff);


    True, but adding spurious casts to code to silence diagnostic messages does
    not add value to the code. It doesn't do anything good, and it doesn't stop
    anything bad happening. All it does is turn your eyes off.

    > You could also get rid of it using compiler-specific pragmas,


    ....and have gcc play nethack with you. Yeah, right. :)

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Jan 5, 2007
    #13
  14. Michal Nazarewicz

    Eric Sosman Guest

    Peter Nilsson wrote:
    > Eric Sosman wrote:
    >> Michal Nazarewicz wrote On 01/04/07 15:55,:
    >>> The following code compiles fine (with warnings though) under GCC with
    >>> -pedantic and -ansi arguments:

    > <snip>
    >> ... The compiler is required to reject a
    >> module containing a non-suppressed #error directive.

    >
    > That is true of C99, but rejection under #error is not a requirement of
    > C90
    > implementations. However, the C90 implementation the OP is using will.


    If C99 were a human child she would be almost eight years
    old and partway through the second grade. She would know how
    to add and subtract, and would be on the verge of learning
    multiplication. She would be able to read. She might be
    taking violin lessons (with wide strings, no doubt). She would
    be computer-literate. She would be an accepted, albeit junior,
    member of society.

    Alas! that over this bright beginning should hang the grim
    shadow of noxious doom! For though she seems healthy and happy
    today, her family is congenitally short-lived: her elder brother
    ANSI succumbed before he reached his teens, and a similar fate
    awaits poor C99. Another year or two, say the grave and sorrowful
    doctors, or three at the most, and >sob< she will be gone.

    When the grim day arrives, will it be said that she was never
    a "real" child? Will she go to her grave unmourned, unloved,
    always passed over in favor of her long-gone brother's ghost?
    Don't be so heartless: it is in your power to give her a brief
    moment of acknowledgment before she's gone. Make a child happy.

    "Be not the first by whom the new is tried,
    Nor yet the last to lay the old aside."
    -- Alexander Pope

    --
    Eric Sosman
    lid
     
    Eric Sosman, Jan 5, 2007
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    11
    Views:
    1,113
  2. Javier
    Replies:
    2
    Views:
    574
    James Kanze
    Sep 4, 2007
  3. 0m
    Replies:
    26
    Views:
    1,126
    Tim Rentsch
    Nov 10, 2008
  4. fungus
    Replies:
    13
    Views:
    893
    fungus
    Oct 31, 2008
  5. Iñaki Baz Castillo
    Replies:
    13
    Views:
    509
    Iñaki Baz Castillo
    May 1, 2011
Loading...

Share This Page