Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: sizeof(const int *) > sizeof(int *)

Reply
Thread Tools

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

 
 
Stargazer
Guest
Posts: n/a
 
      06-14-2010
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

 
Reply With Quote
 
 
 
 
Stargazer
Guest
Posts: n/a
 
      06-15-2010
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
 
Reply With Quote
 
 
 
 
Luca Forlizzi
Guest
Posts: n/a
 
      06-15-2010
On 15 Giu, 09:31, Stargazer <(E-Mail Removed)> 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

 
Reply With Quote
 
Ersek, Laszlo
Guest
Posts: n/a
 
      06-15-2010
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
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-15-2010
Luca Forlizzi <(E-Mail Removed)> writes:

> On 15 Giu, 09:31, Stargazer <(E-Mail Removed)> 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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-15-2010
Ben Bacarisse <(E-Mail Removed)> writes:
> Luca Forlizzi <(E-Mail Removed)> writes:
>> On 15 Giu, 09:31, Stargazer <(E-Mail Removed)> 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.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-15-2010
Keith Thompson <(E-Mail Removed)> 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.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-15-2010
Ben Bacarisse <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      06-15-2010
Keith Thompson <(E-Mail Removed)> 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.
 
Reply With Quote
 
Luca Forlizzi
Guest
Posts: n/a
 
      06-16-2010
On 15 Giu, 19:12, Ben Bacarisse <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
why is int a[0] not allowed, but int* a = new int[0] is? haijin.biz@gmail.com C++ 9 04-17-2007 09:01 AM
Difference between int i, j; and int i; int j; arun C Programming 8 07-31-2006 05:11 AM
int a[10]; int* p=(int*)((&a)+1); But why p isn't equal to ((&a)+1)? aling C++ 8 10-20-2005 02:42 PM
int main(int argc, char *argv[] ) vs int main(int argc, char **argv ) Hal Styli C Programming 14 01-20-2004 10:00 PM
dirty stuff: f(int,int) cast to f(struct{int,int}) Schnoffos C Programming 2 06-27-2003 03:13 AM



Advertisments