Suffix allowed on expressions?

[dspfun]

Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

I found this in a C test at http://www.embedded.com/2000/0005/0005feat2.htm
,
however, I am not able to compile when using this macro (or just the
expression "a = (60 * 60 * 365) UL;").

Where in the standard does it say that it is allowed/not allowed?

It would also be interesting to hear if there are any faults in the
other questions and answers in the test.

BRs!

[dspfun]

On 2 Jan, 19:07, dspfun <[e-mail]:

Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

It should be:
#define SECONDS_PER_YEAR (60 * 60 * 24 * 365) UL

>
I found this in a C test athttp://www.embedded.com/2000/0005/0005feat2.htm
,
however, I am not able to compile when using this macro (or just the
expression "a = (60 * 60 * 365) UL;").

It should be:
(or just the expression statement "a = (60 * 60 * 24 * 365) UL;")

[Ben Pfaff]

dspfun <ds****@hotmail.comwrites:

Are suffixes allowed on expressions?

No. The suffixes that you are talking about are allowed only on
integer and floating-point constants.

For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEAR (60UL * 60 * 365)
or
#define SECONDS_PER_YEAR (unsigned long int) (60 * 60 * 365)
--
"All code should be deliberately written for the purposes of instruction.
If your code isn't readable, it isn't finished yet."
--Richard Heathfield

[Ben Pfaff]

Ben Pfaff <bl*@cs.stanford.eduwrites:

To get the apparently intended effect, you can write
#define SECONDS_PER_YEAR (60UL * 60 * 365)
or
#define SECONDS_PER_YEAR (unsigned long int) (60 * 60 * 365)

Oh, and to get the apparently intended value, you need to
multiply by an additional factor of 24.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Ben Bacarisse]

Ben Pfaff <bl*@cs.stanford.eduwrites:

dspfun <ds****@hotmail.comwrites:

>For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEAR (60UL * 60 * 365)
or
#define SECONDS_PER_YEAR (unsigned long int) (60 * 60 * 365)

The latter can, as I am sure you know, overflow. Since the quiz was
on a site that referenced embedded systems, it would be safer to
assume a minimal max int (if you see what I mean).

To the OP: to illustrate using a cast (which *can* be used in
expressions unlike suffixes) you could write:

#define SECONDS_PER_YEAR ((unsigned long int)60 * 60 * 365)

* is left-associative so all the multiplications must produce unsigned
long int results.

--
Ben.

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:
[...]

There's a contact address in the article; I'll send him pointers to
your article and my followup.

The e-mail address in the article is obsolete (I think the article is
several years old). I found what appears to be his current address by
searching the embedded.com web site. (I won't post it here; I'm sure
he gets more than enough spam already.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Ben Pfaff wrote:

dspfun <ds****@hotmail.comwrites:

>Are suffixes allowed on expressions?

No. The suffixes that you are talking about are allowed only on
integer and floating-point constants.

>For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEAR (60UL * 60 * 365)
or
#define SECONDS_PER_YEAR (unsigned long int) (60 * 60 * 365)

The second will only work if the expression (60 * 60 * 365) is
within the range of an int. This is doubtful if running on a 16
bit system.

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[dspfun]

What about question 12, isn't it implementation specific since the
representation of the basic types are not precisely defined by the
language?

---------------
12. What does the following code output and why?

void foo(void)
{
unsigned int a = 6;
int b = -20;
(a+b 6) ? puts("6") : puts("<= 6");
}

Answer:
This question tests whether you understand the integer promotion rules
in C-an area that I find is very poorly understood by many developers.
Anyway, the answer is that this outputs "6." The reason for this is
that expressions involving signed and unsigned types have all operands
promoted to unsigned types. Thus ý20 becomes a very large positive
integer and the expression evaluates to greater than 6. This is a very
important point in embedded systems where unsigned data types should
be used frequently (see Reference 2). If you get this one wrong, you
are perilously close to not getting the job.
-------------

[Richard Heathfield]

dspfun said:

On 2 Jan, 19:07, dspfun <[e-mail]:

>Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

It should be:
#define SECONDS_PER_YEAR (60 * 60 * 24 * 365) UL

The result of the above calculation will be out by 86400 seconds this year.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[jameskuyper]

dspfun wrote:

What about question 12, isn't it implementation specific since the
representation of the basic types are not precisely defined by the
language?

This has nothing to do with the representation of the basic types, it
depends only upon the usual arithmetic conversions. While the results
of those conversions vary from implementation to implementation, the
particular values chose for a and b below are guaranteed to produce
the same final results on all conforming implementations of C.

---------------
12. What does the following code output and why?

void foo(void)
{
unsigned int a = 6;
int b = -20;
(a+b 6) ? puts("6") : puts("<= 6");
}

Answer:
This question tests whether you understand the integer promotion rules
in C-an area that I find is very poorly understood by many developers.
Anyway, the answer is that this outputs "6." The reason for this is
that expressions involving signed and unsigned types have all operands
promoted to unsigned types. ...

Note that this is not the correct rule in C99, though I think it's a
correct statement of the C90 rule. In C99, the signed operand is
converted to the type of the unsigned operand only if the rank of the
unsigned type is greater than or equal to the rank of the signed type.
In this case, that happens to be true.

... Thus �20 becomes a very large positive
integer and the expression evaluates to greater than 6. ...

Specifically, (a+b) has a value of UINT_MAX-13. The value of that sum
depends upon the implementation, since UINT_MAX depends upon the
implementation. However, since UINT_MAX must be at least 65535, that
value is guaranteed to be at least 65522, and therefore greater than
6, and the routine is guaranteed to pass "6" to puts().

[jameskuyper]

Richard Heathfield wrote:

dspfun said:

On 2 Jan, 19:07, dspfun <[e-mail]:

Hi!

Are suffixes allowed on expressions?

For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

It should be:
#define SECONDS_PER_YEAR (60 * 60 * 24 * 365) UL

The result of the above calculation will be out by 86400 seconds this year.

On the originally referenced web site, the relevant question specified
that leap years are to be ignored. The macro name should have
reflected that fact, though I'm not sure of the best way to do so.
SECONDS_PER_NON_LEAP_YEAR?

[dspfun]

On 2 Jan, 22:29, [e-mail] wrote:

dspfun wrote:

What about question 12, isn't it implementation specific since the
representation of the basic types are not precisely defined by the
language?

This has nothing to do with the representation of the basic types, it
depends only upon the usual arithmetic conversions. While the results
of those conversions vary from implementation to implementation, the
particular values chose for a and b below are guaranteed to produce
the same final results on all conforming implementations of C.

---------------
12. What does the following code output and why?

void foo(void)
{
Â* unsigned int a = 6;
Â* int b = -20;
Â* Â* (a+b 6) ? puts("6") : Â*puts("<= 6");
}

Answer:
This question tests whether you understand the integer promotion rules
in C-an area that I find is very poorly understood by many developers.
Anyway, the answer is that this outputs "6." The reason for this is
that expressions involving signed and unsigned types have all operands
promoted to unsigned types. ...

Note that this is not the correct rule in C99, though I think it's a
correct statement of the C90 rule. In C99, the signed operand is
converted to the type of the unsigned operand only if the rank of the
unsigned type is greater than or equal to the rank of the signed type.
In this case, that happens to be true.

... Thus �20 becomes a very large positive
integer and the expression evaluates to greater than 6. ...

Specifically, (a+b) has a value of UINT_MAX-13. The value of that sum
depends upon the implementation, since UINT_MAX depends upon the
implementation. However, since UINT_MAX must be at least 65535, that
value is guaranteed to be at least 65522, and therefore greater than
6, and the routine is guaranteed to pass "6" to puts().- Dölj citerad text -

- Visa citerad text -

Ok, thank you for the explanation! I believe it is the following in
C99 that specifies this (that the result of a+b will be UINT_MAX + 1
-20 + 6 = UINT_MAX-13):

2
Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or
subtracting one more than the maximum value that can be represented in
the new type
until the value is in the range of the new type.49)

[CBFalconer]

ja*********@verizon.net wrote:

>

.... snip ...

>
On the originally referenced web site, the relevant question
specified that leap years are to be ignored. The macro name
should have reflected that fact, though I'm not sure of the
best way to do so. SECONDS_PER_NON_LEAP_YEAR?

Too long. Try SECS_PER_SQUAT_YR. :-)

--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee, Frohe Weihnachten
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

ja*********@verizon.net wrote:

>>

... snip ...

>>
On the originally referenced web site, the relevant question
specified that leap years are to be ignored. The macro name
should have reflected that fact, though I'm not sure of the
best way to do so. SECONDS_PER_NON_LEAP_YEAR?

Too long. Try SECS_PER_SQUAT_YR. :-)

The term for a non-leap year is "common year".

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
[...]
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

Keith Thompson wrote:

dspfun <ds****@hotmail.comwrites:

>Are suffixes allowed on expressions?

No (unless the expression happens to be an integer constant).

The suffix is *part* of the constant. They form one token.
You can't have e.g. `12 UL`.
--
Army1987 (Replace "NOSPAM" with "email")

[Charles Richmond]

CBFalconer wrote:

Ben Pfaff wrote:

>dspfun <ds****@hotmail.comwrites:

>>Are suffixes allowed on expressions?

No. The suffixes that you are talking about are allowed only on
integer and floating-point constants.

>>For example, is the following allowed:

#define SECONDS_PER_YEAR (60 * 60 * 365) UL

No. To get the apparently intended effect, you can write
#define SECONDS_PER_YEAR (60UL * 60 * 365)
or
#define SECONDS_PER_YEAR (unsigned long int) (60 * 60 * 365)

The second will only work if the expression (60 * 60 * 365) is
within the range of an int. This is doubtful if running on a 16
bit system.

And SECONDS_PER_YEAR really is equal to (60 * 60 * 24 * 365).
^^^^

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[dspfun]

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

[jameskuyper]

dspfun wrote:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

'const' is a type-qualifier, and therefore a declaration-specifier.
'a' is parsed as a direct-declarator, and therefore as a declarator,
and therefore as an init-declarator-list. 6.7p1 requires that
declarations-specifiers preceed the init-declarator-list, so this is
an incorrect declaration.

[dspfun]

On 3 Jan, 21:18, [e-mail] wrote:

dspfun wrote:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

'const' is a type-qualifier, and therefore a declaration-specifier.
'a' is parsed as a direct-declarator, and therefore as a declarator,
and therefore as an init-declarator-list. 6.7p1 requires that
declarations-specifiers preceed the init-declarator-list, so this is
an incorrect declaration.

Thanks for a great answer!

How did you do the mapping type-qualifier -declaration-specifier and
direct-declarator -declarator -init-declarator-list ?

I found something more suspicuous in the anser to question 2:

"Knowledge of the ternary conditional operator. This operator exists
in C because it allows the compiler to produce more optimal code than
an if-then-else sequence. "

Is this really true?

[jameskuyper]

dspfun wrote:

On 3 Jan, 21:18, [e-mail] wrote:

dspfun wrote:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

The declaration above doesn't compile using gcc.

'const' is a type-qualifier, and therefore a declaration-specifier.
'a' is parsed as a direct-declarator, and therefore as a declarator,
and therefore as an init-declarator-list. 6.7p1 requires that
declarations-specifiers preceed the init-declarator-list, so this is
an incorrect declaration.

Thanks for a great answer!

How did you do the mapping type-qualifier -declaration-specifier and

This is just a matter of reading and correctly interpreting the
productions listed in section 6.7p1.

direct-declarator -declarator -init-declarator-list ?

I left out init-declarator, between the last two items there. See
sections 6.7.5p1 and 6.7p1.

I found something more suspicuous in the anser to question 2:

"Knowledge of the ternary conditional operator. This operator exists
in C because it allows the compiler to produce more optimal code than
an if-then-else sequence. "

Is this really true?

I sincerely doubt that any modern compiler produces different code
depending upon whether if-then-else or ?: is used, and I'm quite sure
that any such minor efficiencies have nothing to do with the reason
why it exists. The ?: operator is syntactic sugar, which makes certain
construct much simpler to write. It's not necessary, but it is
occasionally convenient, and convenience should not be underrated as a
feature of a computer programming language.

[Ben Pfaff]

dspfun <ds****@hotmail.comwrites:

How about question 7, is it correct (referring to the test in the link
at the top of the thread)? :

int const * a const;

This is probably a typo for:
int const *const a;
although I would write such a declaration as, equivalently:
const int *const a;
--
"If I've told you once, I've told you LLONG_MAX times not to
exaggerate."
--Jack Klein

[Walter Roberson]

In article <71**********************************@5g2000hsg.go oglegroups.com>,
dspfun <ds****@hotmail.comwrote:

>Could you give a pointer to where in the standard it says that an
integer (constant) can be typecasted to a pointer and the result is
implementation dependent?

C89 3.3.4 Cast Operators

An abitrary integer may be converted to a pointer. The result
is implementation-defined. [45]
{footnote} [45] The mapping functions for converting a pointer to
an integer or an integer to a pointer are intended to be
consistent with the addressing structure of the execution
environment.

--
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec

[dspfun]

On 4 Jan, 00:41, [e-mail] (Walter Roberson) wrote:

In article <[e-mail]>,

dspfun *<[e-mail]:

Could you give a pointer to where in the standard it says that an
integer (constant) can be typecasted to a pointer and the result is
implementation dependent?

C89 3.3.4 Cast Operators

* An abitrary integer may be converted to a pointer. The result
* is implementation-defined. [45]

* {footnote} [45] The mapping functions for converting a pointer to
* an integer or an integer to a pointer are intended to be
* consistent with the addressing structure of the execution
* environment.

--
* *"Any sufficiently advanced bug is indistinguishable from a feature."
* *-- Rich Kulawiec

Thank you, is the same valid for C99?

[Ben Pfaff]

dspfun <ds****@hotmail.comwrites:

A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

It's *extremely* obscure why one would give an rvalue a const
type.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[CBFalconer]

dspfun wrote:

>

.... snip ...

>
Could you give a pointer to where in the standard it says that an
integer (constant) can be typecasted to a pointer and the result
is implementation dependent?

You can answer this sort of question more easily yourself, with a
text version of the C standard and grep. grep is available
everywhere. For the text version I suggest N869_txt.bz2, which is
a bzip2 compressed version of N869, and is available at:

<http://cbfalconer.home.att.net/download/>

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>dspfun wrote:

>>>

... snip ...

>>>
Could you give a pointer to where in the standard it says that an
integer (constant) can be typecasted to a pointer and the result
is implementation dependent?

You can answer this sort of question more easily yourself, with a
text version of the C standard and grep. grep is available
everywhere. For the text version I suggest N869_txt.bz2, which is
a bzip2 compressed version of N869, and is available at:

<http://cbfalconer.home.att.net/download/>

n1256.pdf, available at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>,
is more current. It's PDF rather than plain text, which may or may
not be a problem.

I'm not convinced that a simple grep would be useful in this case.
For example, the word "typecast" appears nowhere in the standard.
What would you grep for?

For example, I just entered:

grep -n cast \stds\n869.txt | less

and got a set of roughly 60 lines. This took all of 2 seconds. It
shouldn't take much to hide that output and just save the line
numbers, which can then be used to illuminate all the areas of
interest.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Mark McIntyre]

CBFalconer wrote:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

I'm not convinced that a simple grep would be useful in this case.
For example, the word "typecast" appears nowhere in the standard.
What would you grep for?

For example, I just entered:

grep -n cast \stds\n869.txt | less

and got a set of roughly 60 lines.

Yeah, but the OP is under the mistaken impression that "typecasting" has
something to do with C, rather than with Hollywood. :-(

It would probably have been useful to have advised him that the word he
was searching for was 'convert'.
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Army1987]

dspfun wrote:

A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

The most obscure thing is what the `const` is for. A cast doesn't yield a
lvalue, so it's irrelevant whether it's const. Do you usually end the body
of main with `return (const int)0;`?

--
Army1987 (Replace "NOSPAM" with "email")

[dspfun]

On 4 Jan, 01:46, Ben Pfaff <[e-mail]:

dspfun <[e-mail]:

A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

It's *extremely* obscure why one would give an rvalue a const
type.

Can you explain what you mean?

Isn't 0xaa55 the rvalue, 0xaa55 is an integer constant, what is the
obscure thing about that?

[Ben Pfaff]

dspfun <ds****@hotmail.comwrites:

On 4 Jan, 01:46, Ben Pfaff <[e-mail]:

>dspfun <[e-mail]:

A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

It's *extremely* obscure why one would give an rvalue a const
type.

Can you explain what you mean?

"const" is attached to a type to make objects of that type
non-modifiable. But the result of a cast is never modifiable,
because it is not an lvalue. So the "const" keyword here is
useless.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[dspfun]

On 5 Jan, 06:25, Ben Pfaff <[e-mail]:

dspfun <[e-mail]:

On 4 Jan, 01:46, Ben Pfaff <[e-mail]:

dspfun <[e-mail]:
A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

It's *extremely* obscure why one would give an rvalue a const
type.

Can you explain what you mean?

"const" is attached to a type to make objects of that type
non-modifiable. *But the result of a cast is never modifiable,
because it is not an lvalue. *So the "const" keyword here is
useless.

If const in the above expression statement is useless, is it also
implementation specific? Does the standard specify it to be useless
(explicitly or implicitly)?

One could imagine a cast like this:

const int * p;
p = (const int *)(0x67a9);

Then the const qualifier is not useless in the cast?

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 05 Jan 2008 08:02:31 -0800, dspfun wrote:

>dspfun <[e-mail]:
A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

If const in the above expression statement is useless, is it also
implementation specific? Does the standard specify it to be useless
(explicitly or implicitly)?

Yes, the standard requires it to be useless:
"The properties associated with qualified types are meaningful only for
expressions that are lvalues."

One could imagine a cast like this:

const int * p;
p = (const int *)(0x67a9);

Then the const qualifier is not useless in the cast?

In that cast, the target type is an unqualified pointer. It happens to be
a pointer to a const-qualified int, but that is not relevant to the
discussion.

[dspfun]

On 5 Jan, 17:36, Harald van D©¦k <[e-mail]:

On Sat, 05 Jan 2008 08:02:31 -0800, dspfun wrote:

dspfun <[e-mail]:
A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

If const in the above expression statement is useless, is it also
implementation specific? Does the standard specify it to be useless
(explicitly or implicitly)?

Yes, the standard requires it to be useless:
"The properties associated with qualified types are meaningful only for
expressionsthat are lvalues."

One could imagine a cast like this:

const int * p;
p = (const int *)(0x67a9);

Then the const qualifier is not useless in the cast?

In that cast, the target type is an unqualified pointer. It happens to be
a pointer to a const-qualified int, but that is not relevant to the
discussion.

So, are the following two pointers identical? :

const int * p1;
int * p2;

p1 can be modified to any value, but whichever object p1 addresses can
not be modified (using *p1). It seems as if the const type qualifier
information "follows" p1?

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 05 Jan 2008 10:59:18 -0800, dspfun wrote:

So, are the following two pointers identical? :

const int * p1;
int * p2;

No.

p1 can be modified to any value, but whichever object p1 addresses can
not be modified (using *p1). It seems as if the const type qualifier
information "follows" p1?

Indeed. *p1 is an lvalue of type const int, and for lvalues, type
qualifiers do matter.

[dspfun]

On 5 Jan, 22:57, Harald van D©¦k <[e-mail]:

On Sat, 05 Jan 2008 10:59:18 -0800, dspfun wrote:

So, are the following two pointers identical? :

const int * p1;
int * p2;

No.

p1 can be modified to any value, but whichever object p1 addresses can
not be modified (using *p1). It seems as if the const type qualifier
information "follows" p1?

Indeed. *p1 is an lvalue of type const int, and for lvalues, type
qualifiers do matter.

So, in the above, is p1 a qualified pointer, and p2 an unqualified
pointer?

[=?UTF-8?q?Harald_van_D=C4=B3k?=]

On Sat, 05 Jan 2008 14:56:27 -0800, dspfun wrote:

>On Sat, 05 Jan 2008 10:59:18 -0800, dspfun wrote:

const int * p1;
int * p2;

So, in the above, is p1 a qualified pointer, and p2 an unqualified
pointer?

No. I already stated in my first message in this subthread that const int
* is an unqualified pointer to a const-qualified int. The const does not
apply to the pointer itself.

const int *p;
p = 0;

If that's valid, p is not const-qualified. That's valid.

[dspfun]

On 6 Jan, 00:04, Harald van D©¦k <[e-mail]:

On Sat, 05 Jan 2008 14:56:27 -0800, dspfun wrote:

On Sat, 05 Jan 2008 10:59:18 -0800, dspfun wrote:
const int * p1;
int * p2;

So, in the above, is p1 a qualified pointer, and p2 an unqualified
pointer?

No. I already stated in my first message in this subthread that const int
* is an unqualified pointer to a const-qualified int. The const does not
apply to the pointer itself.

const int *p;
p = 0;

If that's valid, p is not const-qualified. That's valid.

I guess the source of my confusion could be exemplified by the
following:

const int *p1;
int *p2;
p1 = (int *)(0x67a9);
p2 = (int *)(0x67a9);

p1 points to an int which is not modifiable while p2 points to an int
which is modifiable. But they both point to the same int.

Thanks for your time and help!!

[Mark McIntyre]

dspfun wrote:

I guess the source of my confusion could be exemplified by the
following:

const int *p1;
int *p2;
p1 = (int *)(0x67a9);
p2 = (int *)(0x67a9);

p1 points to an int which is not modifiable while p2 points to an int
which is modifiable. But they both point to the same int.

They both point to the same /memory location/, yes.

But thats not a problem - think of it as similar to file modes. The
'const' qualifier is like opening a readonly file handle. An application
can open two handles on a file, one readonly and the other read/write.
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[dspfun]

On 6 Jan, 00:57, Mark McIntyre <[e-mail]:

dspfun wrote:

I guess the source of my confusion could be exemplified by the
following:

const int *p1;
int *p2;
p1 = (int *)(0x67a9);
p2 = (int *)(0x67a9);

p1 points to an int which is not modifiable while p2 points to an int
which is modifiable. But they both point to the same int.

They both point to the same /memory location/, yes.

But thats not a problem - think of it as similar to file modes. The
'const' qualifier is like opening a readonly file handle. An application
can open two handles on a file, one readonly and the other read/write.

Since p1 is defined as a pointer to a const int, I feel the cast of
0x67a9 should have been to a pointer which points to a const int.
But the cast of 0x67a9 is to a pointer which points to an int, and not
to a const int.
So to me it seems as if the "type" of p1 is slightly different from
the "type" of "(int *) 0x6a70".

Thanks again!

[Ben Bacarisse]

dspfun <ds****@hotmail.comwrites:

On 6 Jan, 00:57, Mark McIntyre <[e-mail]:

>dspfun wrote:

I guess the source of my confusion could be exemplified by the
following:

const int *p1;
int *p2;
p1 = (int *)(0x67a9);
p2 = (int *)(0x67a9);

p1 points to an int which is not modifiable while p2 points to an int
which is modifiable. But they both point to the same int.

They both point to the same /memory location/, yes.

But thats not a problem - think of it as similar to file modes. The
'const' qualifier is like opening a readonly file handle. An application
can open two handles on a file, one readonly and the other read/write.

Since p1 is defined as a pointer to a const int, I feel the cast of
0x67a9 should have been to a pointer which points to a const int.
But the cast of 0x67a9 is to a pointer which points to an int, and not
to a const int.
So to me it seems as if the "type" of p1 is slightly different from
the "type" of "(int *) 0x6a70".

Yes, the types are different. One is 'const int *' the other is 'int
*'. They ('p1' and '(int *)(0x67a9)') are both pointers but to
differently qualified versions of the same type ('int').

Assignment (and also parameter passing) allows qualifiers to be added
to the "pointed to" type. There is a passage in the standard that
specifically states this permission. The reverse is not allowed:

p2 = p1;

after the code you quote is a constraint violation.

--
Ben.

[Mark McIntyre]

dspfun wrote:

Since p1 is defined as a pointer to a const int, I feel the cast of
0x67a9 should have been to a pointer which points to a const int.
But the cast of 0x67a9 is to a pointer which points to an int, and not
to a const int.
So to me it seems as if the "type" of p1 is slightly different from
the "type" of "(int *) 0x6a70".

Well, you lied to the compiler... if you want a const int*, tell it
thats what you have !

Also - the assignment adds the constness. RTFS to determine the precise
para that allows this.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[James Kuyper]

dspfun wrote:

On 4 Jan, 01:46, Ben Pfaff <[e-mail]:

>dspfun <[e-mail]:

>>A more obscure approach is:
*(int * const)(0x67a9) = 0xaa55;

It's *extremely* obscure why one would give an rvalue a const
type.

Can you explain what you mean?

Isn't 0xaa55 the rvalue, 0xaa55 is an integer constant, what is the
obscure thing about that?

There is no connection of any kind between the 'const' in the cast
expression and the fact that 0xaa55 is a constant expression. Whatever
connection you think exists reflects a misunderstanding on your part.

In a pointer declaration, a qualifier such as 'const' that appears
before the '*' qualifies the values that are pointed at. When the
'const' occurs after the '*', it applies to the pointer value itself,
not the pointed-at value.

when the 'const' qualifier applies to an lvalue, it disqualifies the
lvalue from being modifiable. If the operand of an increment or
decrement expression, or the left operand of an assignment is not a
modifiable lvalue, it is a constraint violation. This is the main
purpose of declaring things to be 'const'. It is already a constraint
violation for (int *)(0x67a9) to be in any of those situations, because
it isn't an lvalue, so making it (int * const)(0x67a9) doesn't change
anything. The 'const' is completely pointless in that position.

Using (int const*)(0x67a9) would change things, because in that case
'const' would apply to the pointed-at value, rather than the pointer
value. The effect of using that declaration would be to make the
assignment above a constraint violation.