Re: sizeof(const int *) > sizeof(int *)

Discussion in 'C Programming' started by Stargazer, Jun 14, 2010.

  1. Stargazer

    Stargazer Guest

    On Jun 14, 12:42 pm, "paul" <no@email> wrote:
    > I'm working on an embedded platform where there
    > is over 64kb of flash, but only a few kb of ram.
    >
    > The ram is low in the memory, so a pointer
    > to a non-const integer is 2 bytes.
    > A pointer to a const however is 3 bytes.
    >
    > Obviously casting from a pointer to const,
    > to a pointer to non-const, looses the most
    > significant byte, which makes bad things happen.
    >
    > In this case, it is obviously bad practice, but
    > does the standard say that the cast is UB?
    > (assuming it then only read, and not written to)
    >
    > Also, does the standard state that a pointer to
    > non-const cannot be larger than a pointer to const?
    > (that really would cause problems).


    The standard says that "pointers to qualified or unqualified versions
    of
    compatible types shall have the same representation and alignment
    requirements." (6.2.5.[27]). Casting from const to non-const may be a
    bad practice or not, but what you describe features the compiler as
    non-conforming. So -

    1) are you sure that 24-bit pointers are not attached to some
    implementation-defined additional qualifier?
    2) if answer to (1) is "yes", can you switch to a conforming compiler
    for your platform?

    Daniel
    Stargazer, Jun 14, 2010
    #1
    1. Advertising

  2. Stargazer

    Stargazer Guest

    On Jun 14, 3:50 pm, "paul" <no@email> wrote:
    > > 1) are you sure that 24-bit pointers are not attached to some
    > > implementation-defined additional qualifier?

    >
    > Yes, they are just declared as per usual (const int * x;).
    >
    > > 2) if answer to (1) is "yes", can you switch to a conforming compiler
    > > for your platform?

    >
    > No, but it's not a problem, I just wanted to understand the issue.


    I just re-checked, and it appears that the relevant clause did not
    exist in earlier, C89 standard. That is, if your compiler claims
    conformance to C89 (which may very well be the case for 16/24 bit
    architecture, if that appeared before 1999-2000), it is permitted the
    behavior that you describe and may be trusted with its claims.

    Daniel
    Stargazer, Jun 15, 2010
    #2
    1. Advertising

  3. On 15 Giu, 09:31, Stargazer <> wrote:

    >
    > I just re-checked, and it appears that the relevant clause did not
    > exist in earlier, C89 standard. That is, if your compiler claims
    > conformance to C89 (which may very well be the case for 16/24 bit
    > architecture, if that appeared before 1999-2000), it is permitted the
    > behavior that you describe and may be trusted with its claims.
    >


    In C90, section 6.1.2.5, it reads "... Any type so far mentioned is an
    unqualified type. Each unqualified type has three
    corresponding qualified versions of its type: ... . The qualified or
    unqualified versions of a type are distinct types that belong to the
    same type category and have the same representation and
    alignment requirements.".

    In my opinion, even according to C90 the implementation is not
    conforming.

    my 2 cents
    Luca
    Luca Forlizzi, Jun 15, 2010
    #3
  4. On Tue, 15 Jun 2010, Luca Forlizzi wrote:

    > In C90, section 6.1.2.5, it reads "... Any type so far mentioned is an
    > unqualified type. Each unqualified type has three
    > corresponding qualified versions of its type: ... . The qualified or
    > unqualified versions of a type are distinct types that belong to the
    > same type category and have the same representation and
    > alignment requirements.".


    Thanks!

    lacos
    Ersek, Laszlo, Jun 15, 2010
    #4
  5. Luca Forlizzi <> writes:

    > On 15 Giu, 09:31, Stargazer <> wrote:
    >
    >>
    >> I just re-checked, and it appears that the relevant clause did not
    >> exist in earlier, C89 standard. That is, if your compiler claims
    >> conformance to C89 (which may very well be the case for 16/24 bit
    >> architecture, if that appeared before 1999-2000), it is permitted the
    >> behavior that you describe and may be trusted with its claims.
    >>

    >
    > In C90, section 6.1.2.5, it reads "... Any type so far mentioned is an
    > unqualified type. Each unqualified type has three
    > corresponding qualified versions of its type: ... . The qualified or
    > unqualified versions of a type are distinct types that belong to the
    > same type category and have the same representation and
    > alignment requirements.".


    I don't have a proper copy of C90 (just and text file form the web) but
    I can't see that text in it. Are you sure? If so, I'll have to throw
    away the text file!

    Stargazer was asking about the text that relates to pointers to
    qualified and unqualified versions of the same type -- does that same
    text (or an equivalent) exist in C90? The text you quote is about the
    types themselves, not pointers to them. (I'd look myself but now I don't
    trust the text file I have.)

    > In my opinion, even according to C90 the implementation is not
    > conforming.


    That's probably true, but it does not follow just from the text you
    quoted.

    --
    Ben.
    Ben Bacarisse, Jun 15, 2010
    #5
  6. Ben Bacarisse <> writes:
    > Luca Forlizzi <> writes:
    >> On 15 Giu, 09:31, Stargazer <> wrote:
    >>> I just re-checked, and it appears that the relevant clause did not
    >>> exist in earlier, C89 standard. That is, if your compiler claims
    >>> conformance to C89 (which may very well be the case for 16/24 bit
    >>> architecture, if that appeared before 1999-2000), it is permitted the
    >>> behavior that you describe and may be trusted with its claims.
    >>>

    >>
    >> In C90, section 6.1.2.5, it reads "... Any type so far mentioned is an
    >> unqualified type. Each unqualified type has three
    >> corresponding qualified versions of its type: ... . The qualified or
    >> unqualified versions of a type are distinct types that belong to the
    >> same type category and have the same representation and
    >> alignment requirements.".

    >
    > I don't have a proper copy of C90 (just and text file form the web) but
    > I can't see that text in it. Are you sure? If so, I'll have to throw
    > away the text file!


    Yes, the quoted text is in the C90 standard. (It's a bit odd that
    6.1.2.5, "Types", is under 6.1.2, "Identifiers"; C99 rearranged things.)

    I also have an old file called "ansi.c.txt", which is a pre-C89 draft
    (with the ANSI section numbering, e.g., "Types" is 3.1.2.5) that doesn't
    have that paragraph. It seems to predate the ANSI standard by about a
    year; obviously that was one of the changes that was made in the last
    year before ANSI released the standard. I'm not sure where I got it,
    but it's likely to be the same text file you have.

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 15, 2010
    #6
  7. Keith Thompson <> writes:
    <snip>
    > I also have an old file called "ansi.c.txt", which is a pre-C89 draft
    > (with the ANSI section numbering, e.g., "Types" is 3.1.2.5) that doesn't
    > have that paragraph. It seems to predate the ANSI standard by about a
    > year; obviously that was one of the changes that was made in the last
    > year before ANSI released the standard. I'm not sure where I got it,
    > but it's likely to be the same text file you have.


    Yes, it's probably the same -- I think it is "the" file that has been
    doing the rounds for some time. What a shame it is not reliable.

    --
    Ben.
    Ben Bacarisse, Jun 15, 2010
    #7
  8. Ben Bacarisse <> writes:
    > Keith Thompson <> writes:
    > <snip>
    >> I also have an old file called "ansi.c.txt", which is a pre-C89 draft
    >> (with the ANSI section numbering, e.g., "Types" is 3.1.2.5) that doesn't
    >> have that paragraph. It seems to predate the ANSI standard by about a
    >> year; obviously that was one of the changes that was made in the last
    >> year before ANSI released the standard. I'm not sure where I got it,
    >> but it's likely to be the same text file you have.

    >
    > Yes, it's probably the same -- I think it is "the" file that has been
    > doing the rounds for some time. What a shame it is not reliable.


    14248 lines, 494126 bytes,
    sha1sum = a1119bb2a676f13f1b8a66859e4e35172aee022d

    http://flash-gordon.me.uk/ansi.c.txt

    It's a perfectly reliable document of the state of standardization in
    1988. Unfortunately no free copies of the actual C89 or C90 standard
    were ever released. (I paid $18 for a poor quality PDF of ISO C90; I
    don't know if it's still available at a reasonable price.)

    I'm very glad we have n1256.pdf as a freely available
    close-enough-to-definitive copy of the C99 standard. (We'll probably
    have to wait for the first Technical Corrigendum to get a free copy
    of the C201X standard.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 15, 2010
    #8
  9. Keith Thompson <> writes:
    <snip>
    > 14248 lines, 494126 bytes,
    > sha1sum = a1119bb2a676f13f1b8a66859e4e35172aee022d
    >
    > http://flash-gordon.me.uk/ansi.c.txt


    Yes, the same (sha1sum matches).

    > It's a perfectly reliable document of the state of standardization in
    > 1988. Unfortunately no free copies of the actual C89 or C90 standard
    > were ever released. (I paid $18 for a poor quality PDF of ISO C90; I
    > don't know if it's still available at a reasonable price.)


    I once tried via my national standards body, but the BSI wanted £400 for
    a paper copy. No soft copies were available.

    > I'm very glad we have n1256.pdf as a freely available
    > close-enough-to-definitive copy of the C99 standard.


    Yes, it's very useful.

    --
    Ben.
    Ben Bacarisse, Jun 15, 2010
    #9
  10. On 15 Giu, 19:12, Ben Bacarisse <> wrote:

    > I don't have a proper copy of C90 (just and text file form the web) but
    > I can't see that text in it.  Are you sure?  If so, I'll have to throw
    > away the text file!


    I have a poor quality PDF version of ISO C90. maybe it's the same one
    as Keith. I think it's a scan of an official (final) copy, but I am
    not 100% sure.

    > Stargazer was asking about the text that relates to pointers to
    > qualified and unqualified versions of the same type -- does that same
    > text (or an equivalent) exist in C90?  The text you quote is about the
    > types themselves, not pointers to them.  (I'd look myself but now I don't
    > trust the text file I have.)


    ops, sorry, you're right.
    Anyway, the right text it's in the same section of C90, 6.1.2.5, few
    lines below: "Similarly. pointers to qualified or unqualified versions
    of compatible types
    shall have the same representation and alignment requirements. ”"
    I think it is the same wording existing in C99.

    Luca
    Luca Forlizzi, Jun 16, 2010
    #10
  11. Luca Forlizzi <> writes:
    > On 15 Giu, 19:12, Ben Bacarisse <> wrote:
    >> I don't have a proper copy of C90 (just and text file form the web) but
    >> I can't see that text in it.  Are you sure?  If so, I'll have to throw
    >> away the text file!

    >
    > I have a poor quality PDF version of ISO C90. maybe it's the same one
    > as Keith. I think it's a scan of an official (final) copy, but I am
    > not 100% sure.


    My copy is 13624364 bytes, sha1sum
    8827a3a37da1349c09602e7ca9e065205a22517c. It does appear to be a
    scan of a printed copy, but some optical character recognition was
    done in converting to PDF. When I copy-and-paste text from it,
    I get errors like commas showing up as periods. (The ANSI license
    agreement doesn't permit me to share copies of it.)

    [...]

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Jun 16, 2010
    #11
  12. On 16 Giu, 17:38, Keith Thompson <> wrote:

    > My copy is 13624364 bytes, sha1sum
    > 8827a3a37da1349c09602e7ca9e065205a22517c.  It does appear to be a
    > scan of a printed copy, but some optical character recognition was
    > done in converting to PDF.  When I copy-and-paste text from it,
    > I get errors like commas showing up as periods.  (The ANSI license
    > agreement doesn't permit me to share copies of it.)


    Mine is a little different: 13.624.784 byte
    Luca Forlizzi, Jun 16, 2010
    #12
  13. Stargazer

    Richard Bos Guest

    Ben Bacarisse <> wrote:

    > Keith Thompson <> writes:


    > > It's a perfectly reliable document of the state of standardization in
    > > 1988. Unfortunately no free copies of the actual C89 or C90 standard
    > > were ever released. (I paid $18 for a poor quality PDF of ISO C90; I
    > > don't know if it's still available at a reasonable price.)

    >
    > I once tried via my national standards body, but the BSI wanted £400 for
    > a paper copy. No soft copies were available.


    I fear I lost the details, but some time ago all residents of the UK
    could order any official BSI Standard for free, in digital form, from
    the Manchester University Library. You could see if that's still valid.

    Richard
    Richard Bos, Jul 7, 2010
    #13
  14. (Richard Bos) writes:

    > Ben Bacarisse <> wrote:
    >
    >> Keith Thompson <> writes:

    >
    >> > It's a perfectly reliable document of the state of standardization in
    >> > 1988. Unfortunately no free copies of the actual C89 or C90 standard
    >> > were ever released. (I paid $18 for a poor quality PDF of ISO C90; I
    >> > don't know if it's still available at a reasonable price.)

    >>
    >> I once tried via my national standards body, but the BSI wanted £400 for
    >> a paper copy. No soft copies were available.

    >
    > I fear I lost the details, but some time ago all residents of the UK
    > could order any official BSI Standard for free, in digital form, from
    > the Manchester University Library. You could see if that's still
    > valid.


    I've heard the same thing but it sounds unlikely[1]. I certainly can't
    find any evidence that it is still the case; unless you include the
    option for members of the public to access the BSI database from
    terminals in the building. That is true of lots of UK libraries,
    many of which are closer to me than Manchester University.

    [1] I used to know quite a lot about UK University Libraries and I can't
    see why one would be permitted to undermine the BSI's long-standing
    desire to charge over the top prices for electronic copies. (The
    current C standard is £172 -- the same as the price for a printed copy.
    Delivery, you will be pleased to hear, is included in that.)

    --
    Ben.
    Ben Bacarisse, Jul 7, 2010
    #14
  15. Ben Bacarisse <> writes:
    <snip>
    > I once tried via my national standards body, but the BSI wanted £400 for
    > a paper copy. No soft copies were available.


    Just an update. Soft copies now available. PDF of C89 costs £234 from
    the BSI but the terms of use prevent transferring the document to any
    other computer, so if the laptop breaks or needs to be replaced I'd have
    to fork out another £234! I wonder how often that restriction is
    obeyed.

    <snip>
    --
    Ben.
    Ben Bacarisse, Jul 8, 2010
    #15
    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. Spiros Bousbouras
    Replies:
    40
    Views:
    1,464
    Keith Thompson
    Jan 20, 2007
  2. Replies:
    11
    Views:
    1,089
  3. Javier
    Replies:
    2
    Views:
    548
    James Kanze
    Sep 4, 2007
  4. 0m
    Replies:
    26
    Views:
    1,095
    Tim Rentsch
    Nov 10, 2008
  5. Ben Bacarisse

    Re: sizeof(const int *) > sizeof(int *)

    Ben Bacarisse, Jun 14, 2010, in forum: C Programming
    Replies:
    12
    Views:
    422
    David Thompson
    Jul 2, 2010
Loading...

Share This Page