«

Richard Tobin said:

> In article <>,
> Richard Heathfield <> wrote:
>
>>In this case, gcc is confusing "constant" with "const".
>
> ... which the user asked it to do, by means of the flag -Wwrite-strings:

Quite. Nevertheless, gcc is confusing "constant" with "const".

--
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

In article <>,
Richard Heathfield <> wrote:

>Quite. Nevertheless, gcc is confusing "constant" with "const".

Perhaps "approximating" would be a better term.

-- Richard
--
:wq

On Dec 14, 9:09 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> somenath wrote:
>
> > #include<stdio.h>
> > char *f1(void);
> > char *f1(void) {
> > char *abc ="Hello";
> > return abc;
> > }
>
> > int main(void ) {
> > char *p;
> > p = f1();
>
> > printf("%s\n", p);
> > return 0;
> > }
>
> > While compiling the above program as mentioned below I am getting
> > the meaning
> ... snip ...
> > jj.c:5: warning: initialization discards qualifiers from pointer
> > target type
>
> > I have two question
> > 1) What is the meaning of the warning ?
> > 2) is it safe to return the local pointer value (i.e return abc
> > is correct ?
>
> > My understanding is we should not return address of local
> > variable .So above code may not be working always .
>
> Change "char *abc ="Hello";" to "const char *abc ="Hello";". You
> are not returning a pointer to local storage, you are returning the
> value of that local storage.
>

Just to clarify myself I would like to explain my understanding.
In the definition char *abc ="Hello";
Say 'H' is stored in address 100 and the 'e' will be stored in 108 and
so on . Now "abc" will have the value 100. When "return abc" is
getting executed it will try to return 100 . Is it not correct? If it
is so I am trying to return a address obtained locally. So it should
be wrong. I think I am missing the knowledge about string literal . Is
it handled specially than local variable .
Suppose
int x = 5;
return &x;
According to me we should not this, as address of x will be scrapped
after the execution flow returns from particular function.

somenath said:
> On Dec 14, 9:09 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
>> somenath wrote:
>>
<snip>
>> > char *abc ="Hello";
>> > return abc;
<snip>

>> > My understanding is we should not return address of local
>> > variable .So above code may not be working always .
>>
>> [...] You are not returning a pointer to local storage, you
>> are returning the value of that local storage.
>>
>
> Just to clarify myself I would like to explain my understanding.
> In the definition char *abc ="Hello";
> Say 'H' is stored in address 100 and the 'e' will be stored in 108 and
> so on .

The byte is the smallest addressable unit of storage, and an array occupies
a contiguous block of bytes. If 'H' is in address 100, 'e' is going to be
in address 101.

> Now "abc" will have the value 100. When "return abc" is
> getting executed it will try to return 100 . Is it not correct?

Yes, that's right, although of course the 100 will have pointer type.

> If it
> is so I am trying to return a address obtained locally.

Yes, but it isn't the address of an automatic object, i.e. an object that
will automatically be destroyed on scope exit. Rather, it is the address
of a string literal, which survives throughout the lifetime of the program
and doesn't move around in memory (in the abstract machine, that is).

> So it should be wrong.

No, but I understand why you're worried, so let's deal with that next.

> I think I am missing the knowledge about string literal . Is
> it handled specially than local variable .

No, it's just that it's not a local variable - it's a completely different
animal.

> Suppose
> int x = 5;
> return &x;
> According to me we should not this, as address of x will be scrapped
> after the execution flow returns from particular function.

You are right that we shouldn't do this, but it's not because the address
will be scrapped, so much as that it will become meaningless (because the
object at that address is (conceptually) destroyed when the function
returns). The point of this (conceptual) destruction is that it makes room
for further automatic variables to be constructed during subsequent
processing.

--
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

somenath wrote:

> Just to clarify myself I would like to explain my understanding.
> In the definition char *abc ="Hello";
> Say 'H' is stored in address 100 and the 'e' will be stored in 108 and
> so on .

Well, that's mildly unlikely, `sizeof(char)` being 1, unless you
have 8-bit chars on a bit-addressed machine.

> Now "abc" will have the value 100. When "return abc" is
> getting executed it will try to return 100 . Is it not correct?

For values of `100` which are pointers.

> If it is so I am trying to return a address obtained locally.

Nothing wrong with that. It's /exporting the address of an automatic
variable/ that's the problem.

> So it should
> be wrong. I think I am missing the knowledge about string literal . Is
> it handled specially than local variable .

It's handled /differently/. It's not a local variable.

> Suppose
> int x = 5;
> return &x;
> According to me we should not this, as address of x will be scrapped
> after the execution flow returns from particular function.

Yes. But that's not the same thing at all.

--
owl:differentFrom Hedgehog
Meaning precedes definition.

CBFalconer wrote:
>
> pete wrote:

> > In C, the type of ("Hello") is (char [6]), not (const char [6]).
>
> Not when it has been told otherwise.

The C standard says that the array elements have type char.
You don't get to tell C otherwise.

Maybe there's another newsgroup
where your language extensions
that allow you to respecify parts of C
that have been already specified by the C standard,
are on topic, but this isn't it.

--
pete

"pete" <> wrote in message
news:...
> CBFalconer wrote:
>> pete wrote:
>> > In C, the type of ("Hello") is (char [6]), not (const char [6]).
>>
>> Not when it has been told otherwise.
>
> The C standard says that the array elements have type char.
> You don't get to tell C otherwise.

-Wwrite-strings tells GCC to act _as if_ string literals were of type const
char[] and warn accordingly, though programs still compile correctly. Since
compilers are allowed to emit any diagnostics they want, even incorrect
ones, it's still compliant (as far as this goes, at least). This is little
different from the canonical example of warning on "if (x=0)".

This is a pretty decent warning to have around if you're starting a project
from scratch. Literals _should_ have been const char[] in C90, but they
were left as merely char[] due to the massive existing codebase that assumed
they weren't const.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On Fri, 14 Dec 2007 12:40:46 -0600, Stephen Sprunk wrote:
> "pete" <> wrote in message
> news:...
>> CBFalconer wrote:
>>> pete wrote:
>>> > In C, the type of ("Hello") is (char [6]), not (const char [6]).
>>>
>>> Not when it has been told otherwise.
>>
>> The C standard says that the array elements have type char. You don't
>> get to tell C otherwise.
>
> -Wwrite-strings tells GCC to act _as if_ string literals were of type
> const char[] and warn accordingly, though programs still compile
> correctly. Since compilers are allowed to emit any diagnostics they
> want, even incorrect ones, it's still compliant (as far as this goes, at
> least). This is little different from the canonical example of warning
> on "if (x=0)".

-Wwrite-strings causes this strictly conforming program to be rejected by
design:

int main(void) {
if (0) *"" = 'x';
}

Because of this, -Wwrite-strings, while very useful, causes gcc to not
act as a conforming implementation.


(However, even without -Wwrite-strings, gcc has a bug in which the
equally strictly conforming

int main(void) {
if (0) ""[0] = 'x';
}

is unconditionally rejected.)

Harald van D?k wrote:
>
.... snip ...
>
> (However, even without -Wwrite-strings, gcc has a bug in which the
> equally strictly conforming
>
> int main(void) {
> if (0) ""[0] = 'x';
> }
>
> is unconditionally rejected.)

Not a bug. "" is a constant string, stored in (possibly) constant
memory, and thus is not writable. You may be complaining that gcc
hasn't bother to notice that the statment won't be executed, and
thus should suppress the message. However, compilers are allowed
to emit all the messages they wish.

--
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

somenath wrote:
> CBFalconer <cbfalco...@yahoo.com> wrote:
>> somenath wrote:
>>
>>> #include<stdio.h>
>>> char *f1(void);
>>> char *f1(void) {
>>> char *abc ="Hello";
>>> return abc;
>>> }
>>
>>> int main(void ) {
>>> char *p;
>>> p = f1();
>>
>>> printf("%s\n", p);
>>> return 0;
>>> }
>>
>>> While compiling the above program as mentioned below I am getting
>>> the meaning
>> ... snip ...
>>> jj.c:5: warning: initialization discards qualifiers from pointer
>>> target type
>>
>>> I have two question
>>> 1) What is the meaning of the warning ?
>>> 2) is it safe to return the local pointer value (i.e return abc
>>> is correct ?
>>
>>> My understanding is we should not return address of local
>>> variable .So above code may not be working always .
>>
>> Change "char *abc ="Hello";" to "const char *abc ="Hello";". You
>> are not returning a pointer to local storage, you are returning the
>> value of that local storage.
>
> Just to clarify myself I would like to explain my understanding.
> In the definition char *abc ="Hello";
> Say 'H' is stored in address 100 and the 'e' will be stored in 108 and
> so on . Now "abc" will have the value 100. When "return abc" is
> getting executed it will try to return 100 . Is it not correct? If it
> is so I am trying to return a address obtained locally. So it should
> be wrong. I think I am missing the knowledge about string literal . Is
> it handled specially than local variable .

No, because in your case above the 100 is an address in static
memory, and has nothing to do with the automatic memory of the
function. abc is in that automatic memory, and has been set to
100. The accessibility and content of 100 does not change on
exiting the function.

--
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