typedef trouble

[copx]

For some reason I cannot add a const qualifier to a typedefed pointer type
if said type is used for a return value. It does work if the type is used
for a parameter.
I do not see the logic behind this, but I assume it is standard conforming
behaviour. I use GCC and I guess such an obvious "bug" (if it were one)
would have been reported and fixed long ago.

Example:

typedef char MY_CHAR;
typedef MY_CHAR * MY_STRING;

void foo(const MY_STRING str) // does work

const MY_STRING bar(void) // does not work
(GCC says the const qualifier is ignored)

[Keith Thompson]

"copx" <co**@gazeta.plwrites:

For some reason I cannot add a const qualifier to a typedefed pointer type
if said type is used for a return value. It does work if the type is used
for a parameter.
I do not see the logic behind this, but I assume it is standard conforming
behaviour. I use GCC and I guess such an obvious "bug" (if it were one)
would have been reported and fixed long ago.

Example:

typedef char MY_CHAR;
typedef MY_CHAR * MY_STRING;

void foo(const MY_STRING str) // does work

const MY_STRING bar(void) // does not work
(GCC says the const qualifier is ignored)

But it does work. The warning merely tells you that it's useless.

Given the declarations above, the type "const MY_STRING" doesn't mean
"pointer to const char", it means "const pointer to char". Saying
that the value returned by a function is const doesn't mean anything;
it's a value, not an object, so there's no way to modify it anyway.

In the parameter declaration, it's meaningful, but it may not mean
what you think it means. It means that code in the body of foo can't
modify the str (which is meaningless to the caller); it can still
modify what str points to.

Incidentally, hiding pointer types behind typedefs is usually not a
good idea, and referring to a char* as a string (or MY_STRING) is
potentially misleading. A char* is not a string; it may or may not
point to a string.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[Kiran Kumar Mukkamala]

Yes copx is correct.

The following statement is straight forward.
"ANSI allows the type-qualifier to be const or volatile , but either
qualifier applied to a function return type is meaningless, because
functions can only return rvalues and the type qualifiers apply only
to lvalues."

The above statement clarifies the your doubt. Whatever GCC is
complaining is only a 'Warning', that 'const' specifier is ignored,
it's not an error.

But still I am puzzled:

why GCC doesn't raise the warning for following definition:

const char * bar(void)
{
}

but it does for

typedef char * MY_STRING
const MY_STRING bar(void)
{
}

Some one can clarify ?

-Kiran

On May 22, 11:47 am, Keith Thompson <[e-mail]:

"copx" <[e-mail]:

For some reason I cannot add a const qualifier to a typedefed pointer type
if said type is used for a return value. It does work if the type is used
for a parameter.
I do not see the logic behind this, but I assume it is standard conforming
behaviour. I use GCC and I guess such an obvious "bug" (if it were one)
would have been reported and fixed long ago.

Example:

typedef char MY_CHAR;
typedef MY_CHAR * MY_STRING;

void foo(const MY_STRING str) // does work

const MY_STRING bar(void) // does not work
(GCC says the const qualifier is ignored)

But it does work. The warning merely tells you that it's useless.

Given the declarations above, the type "const MY_STRING" doesn't mean
"pointer to const char", it means "const pointer to char". Saying
that the value returned by a function is const doesn't mean anything;
it's a value, not an object, so there's no way to modify it anyway.

In the parameter declaration, it's meaningful, but it may not mean
what you think it means. It means that code in the body of foo can't
modify the str (which is meaningless to the caller); it can still
modify what str points to.

Incidentally, hiding pointer types behind typedefs is usually not a
good idea, and referring to a char* as a string (or MY_STRING) is
potentially misleading. A char* is not a string; it may or may not
point to a string.

--
Keith Thompson (The_Other_Keith) [e-mail] <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"

[Kiran Kumar Mukkamala]

Sorry to refer 'Tompson' as 'Copx'in my 1st statement.

Kiran
On May 22, 11:54 am, Kiran Kumar Mukkamala <[e-mail]>
wrote:

Yes copx is correct.

The following statement is straight forward.
"ANSI allows the type-qualifier to be const or volatile , but either
qualifier applied to a function return type is meaningless, because
functions can only return rvalues and the type qualifiers apply only
to lvalues."

The above statement clarifies the your doubt. Whatever GCC is
complaining is only a 'Warning', that 'const' specifier is ignored,
it's not an error.

But still I am puzzled:

why GCC doesn't raise the warning for following definition:

const char * bar(void)
{

}

but it does for

typedef char * MY_STRING
const MY_STRING bar(void)
{

}

Some one can clarify ?

-Kiran

On May 22, 11:47 am, Keith Thompson <[e-mail]:

"copx" <[e-mail]:

For some reason I cannot add a const qualifier to a typedefed pointer type
if said type is used for a return value. It does work if the type is used
for a parameter.
I do not see the logic behind this, but I assume it is standard conforming
behaviour. I use GCC and I guess such an obvious "bug" (if it were one)
would have been reported and fixed long ago.

Example:

typedef char MY_CHAR;
typedef MY_CHAR * MY_STRING;

void foo(const MY_STRING str) // does work

const MY_STRING bar(void) // does not work
(GCC says the const qualifier is ignored)

But it does work. The warning merely tells you that it's useless.

Given the declarations above, the type "const MY_STRING" doesn't mean
"pointer to const char", it means "const pointer to char". Saying
that the value returned by a function is const doesn't mean anything;
it's a value, not an object, so there's no way to modify it anyway.

In the parameter declaration, it's meaningful, but it may not mean
what you think it means. It means that code in the body of foo can't
modify the str (which is meaningless to the caller); it can still
modify what str points to.

Incidentally, hiding pointer types behind typedefs is usually not a
good idea, and referring to a char* as a string (or MY_STRING) is
potentially misleading. A char* is not a string; it may or may not
point to a string.

--
Keith Thompson (The_Other_Keith) [e-mail] <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]

Kiran Kumar Mukkamala <k.*********@gmail.comwrites:

Yes copx is correct.

The following statement is straight forward.
"ANSI allows the type-qualifier to be const or volatile , but either
qualifier applied to a function return type is meaningless, because
functions can only return rvalues and the type qualifiers apply only
to lvalues."

The above statement clarifies the your doubt. Whatever GCC is
complaining is only a 'Warning', that 'const' specifier is ignored,
it's not an error.

But still I am puzzled:

why GCC doesn't raise the warning for following definition:

const char * bar(void)
{
}

but it does for

typedef char * MY_STRING
const MY_STRING bar(void)
{
}

Some one can clarify ?

Please don't top-post. See:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

"const char *bar(void)" declares bar as a function returning a pointer
to const char, not a pointer to const char. It says you can't modify
what the result points to, not that you can't modify the result
itself.

"const MY_STRING bar(void)" declares bar as a function returning const
MY_STRING. Typedefs are not macros. In "const MY_STRING", the const
applies to MY_STRING; it's not equivalent to "const char*".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[Pietro Cerutti]

Keith Thompson wrote:

Kiran Kumar Mukkamala <k.*********@gmail.comwrites:

>Yes copx is correct.

The following statement is straight forward.
"ANSI allows the type-qualifier to be const or volatile , but either
qualifier applied to a function return type is meaningless, because
functions can only return rvalues and the type qualifiers apply only
to lvalues."

The above statement clarifies the your doubt. Whatever GCC is
complaining is only a 'Warning', that 'const' specifier is ignored,
it's not an error.

But still I am puzzled:

why GCC doesn't raise the warning for following definition:

const char * bar(void)
{
}

but it does for

typedef char * MY_STRING
const MY_STRING bar(void)
{
}

Some one can clarify ?

Please don't top-post. See:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

"const char *bar(void)" declares bar as a function returning a pointer
to const char, not a pointer to const char.

You mean "a pointer to const char, not a const pointer to a char".

>
"const MY_STRING bar(void)" declares bar as a function returning const
MY_STRING. Typedefs are not macros. In "const MY_STRING", the const
applies to MY_STRING; it's not equivalent to "const char*".

--
Pietro Cerutti

[Flash Gordon]

copx wrote, On 22/05/08 06:17:

For some reason I cannot add a const qualifier to a typedefed pointer type
if said type is used for a return value. It does work if the type is used
for a parameter.

It works perfectly, it just does not do what you think ;-)

Actually, this applies to both.

I do not see the logic behind this, but I assume it is standard conforming
behaviour. I use GCC and I guess such an obvious "bug" (if it were one)
would have been reported and fixed long ago.

It's not a bug.

Example:

typedef char MY_CHAR;
typedef MY_CHAR * MY_STRING;

void foo(const MY_STRING str) // does work

It works, but does not do what you probably think. It means you cannot
modify str, but you *can* modify what it points to! I.e. it is
equivalent to "char * const str" which I don't think is what you wanted.

const MY_STRING bar(void) // does not work
(GCC says the const qualifier is ignored)

A warning is not an error, so it has "worked", it is just that gcc is
being helpful. The reason is the same as why the parameter example is
not what you think.
--
Flash Gordon

[copx]

"copx" <co**@gazeta.plschrieb im Newsbeitrag
news:g1**********@inews.gazeta.pl...
[snip]

Thanks everyone!

[Keith Thompson]

Pietro Cerutti <gahr_SPAM_gahr_ME_chwrites:

Keith Thompson wrote:

[...]

>"const char *bar(void)" declares bar as a function returning a
pointer
to const char, not a pointer to const char.

You mean "a pointer to const char, not a const pointer to a char".

Yes, thanks.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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"

[CBFalconer]

Kiran Kumar Mukkamala wrote:

>
Sorry to refer 'Tompson' as 'Copx'in my 1st statement.

This is top-posted, and thus virtually unreadable. Please do not
top-post. Your answer belongs after (or intermixed with) the
quoted material to which you reply, after snipping all irrelevant
material. See the following links:

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>
<http://cfaj.freeshell.org/google/ (taming google)

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

** Posted from http://www.teranews.com **

[Richard Tobin]

In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>This is top-posted, and thus virtually unreadable.

On the contrary, correcting a minor error in this way is very clear.
If you'd sent someone a paper with a typo in it, it would make more
sense to send them a corrected copy with a post-it on the front
explaining the error, rather than just a note somewhere inside it.

-- Richard

--
:wq

[Chris Torek]

In article <g1**********@inews.gazeta.plcopx <co**@gazeta.plwrote:

>typedef char MY_CHAR;
typedef MY_CHAR * MY_STRING;

void foo(const MY_STRING str) // does work

const MY_STRING bar(void) // does not work
(GCC says the const qualifier is ignored)

Others have explained this somewhat, but here is how I like
to think of this: qualifiers (const and volatile) *never*
"penetrate" a typedef.

Note that one can write, e.g.:

int const foo = 42;

(instead of "const int foo = ..."), and for pointers, one can
const-qualify the pointer itself, rather than, or in addition
to, its target:

int const *const bar = &foo;

which here means that "bar" cannot be changed to point to any other
"int const" (or "const int"), so it will always point to the "int
const" named "foo".

Putting the qualifier after the type-name-keyword is in a sense
more consistent, since you *have* to put it after the asterisk in
a pointer-declaration: if bar itself is to be "const" (so that it
can only point to foo), the "const" keyword must follow the "*".

If you put the qualifiers after the typedef-name that substitutes
for the keyword in your two declarations, you can see that they
"mean" the same as:

void foo(MY_STRING const str);
MY_STRING const bar(void);

so it is the formal parameter named "str" that is const-qualified
here, and the return value from bar() that is const-qualified.

Since "const" never penetrates a typedef, you are free to move it
to either side of the typedef, in the same way that you are free
to move it to either side of a type-name keyword:

const int a_zero = 0;
int const another_zero = 0;

The qualifier does not "look inside" the typedef to see if there
is an embedded pointer it could sneak behind ("penetrate").
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html