473,322 Members | 1,403 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Type of a string literal

Hi,

I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:

char *GetString(void)
{
return "hello";
}

int main(void)
{
printf("%s\n", GetString());

return 0;
}

And it does print 'hello'. But if the pointer that GetString() returns
points to a local object, wouldn't the buffer be deallocated when the
function returns, thus making the pointer point to nothing? Or does
that mean that a string literal has type 'static char *'? Or more
precisely, 'static const char *'?

Thanks,
Sebastian

Jul 26 '08 #1
15 1843
s0****@gmail.com wrote:
Hi,

I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:
A string literal has type array of char, but it automatically is
converted to a pointer to it's first element under most contexts, as is
common for all array types in C.
char *GetString(void)
{
return "hello";
}

int main(void)
{
printf("%s\n", GetString());

return 0;
}

And it does print 'hello'. But if the pointer that GetString() returns
points to a local object, wouldn't the buffer be deallocated when the
function returns, thus making the pointer point to nothing? Or does
that mean that a string literal has type 'static char *'? Or more
precisely, 'static const char *'?

Thanks,
Sebastian
Source code string literals are placed in static arrays. Their type is
of type char or wchar_t and are not qualified with const, but modifying
them invokes undefined behaviour anyway.

Jul 26 '08 #2
On Jul 26, 9:22 am, s0s...@gmail.com wrote:
Hi,

I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:

char *GetString(void)
{
return "hello";

}
See 6.4.5 p 5 from n1256.pdf. string literals are immutable and
"replaced" in TP 7 by static storage duration arrays. Their actual
type is char [N] where N is the integer returned by sizeof, or wchar_t
[N] (for wide string literals).
When evaluated, these become char * and wchar_t *.

Notice that GetString lies to the programmer; the returned value
cannot be modified! Unless you document that, your function is
misleading.
Jul 26 '08 #3
On Jul 26, 5:03*am, vipps...@gmail.com wrote:
On Jul 26, 9:22 am, s0s...@gmail.com wrote:
Hi,
I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:
char *GetString(void)
{
* * return "hello";
}

See 6.4.5 p 5 from n1256.pdf. string literals are immutable and
"replaced" in TP 7 by static storage duration arrays. Their actual
type is char [N] where N is the integer returned by sizeof, or wchar_t
[N] (for wide string literals).
When evaluated, these become char * and wchar_t *.

Notice that GetString lies to the programmer; the returned value
cannot be modified! Unless you document that, your function is
misleading.
Thanks. As for the last part: would it be good practice to qualify the
function definition with 'const'?

Jul 26 '08 #4
s0****@gmail.com writes:
On Jul 26, 5:03Â*am, vipps...@gmail.com wrote:
>On Jul 26, 9:22 am, s0s...@gmail.com wrote:
Hi,
I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:
char *GetString(void)
{
Â* Â* return "hello";
}

See 6.4.5 p 5 from n1256.pdf. string literals are immutable and
"replaced" in TP 7 by static storage duration arrays. Their actual
type is char [N] where N is the integer returned by sizeof, or wchar_t
[N] (for wide string literals).
When evaluated, these become char * and wchar_t *.

Notice that GetString lies to the programmer; the returned value
cannot be modified! Unless you document that, your function is
misleading.

Thanks. As for the last part: would it be good practice to qualify the
function definition with 'const'?
Yes, const char *GetString(void); would be better. Technically this
is not qualifying the function type, nor is it even qualifying the
function's return type. It is, as required, saying the function
returns pointer to const qualified char.

--
Ben.
Jul 26 '08 #5
In article <1c**********************************@l64g2000hse. googlegroups.com>,
<s0****@gmail.comwrote:
>I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:

char *GetString(void)
{
return "hello";
}

int main(void)
{
printf("%s\n", GetString());

return 0;
}

And it does print 'hello'. But if the pointer that GetString() returns
points to a local object, wouldn't the buffer be deallocated when the
function returns, thus making the pointer point to nothing? Or does
that mean that a string literal has type 'static char *'? Or more
precisely, 'static const char *'?
Check out http://www.comeaucomputing.com/techtalk/#stringliteral
plus some stuff just before and just after it. Enjoy! :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #6
In article <17**********************************@m44g2000hsc. googlegroups.com>,
<vi******@gmail.comwrote:
>On Jul 26, 9:22 am, s0s...@gmail.com wrote:
>Hi,

I've heard that a string literal has type 'char *' (i.e., a pointer to
a char object). But I'm confused as to why this works:

char *GetString(void)
{
return "hello";

}

See 6.4.5 p 5 from n1256.pdf. string literals are immutable and
"replaced" in TP 7 by static storage duration arrays. Their actual
type is char [N] where N is the integer returned by sizeof, or wchar_t
[N] (for wide string literals).
When evaluated, these become char * and wchar_t *.
I forget how the standard characterized evaluated, but certainly
in not all cases does it become pointers (for instance, sizeof).
>Notice that GetString lies to the programmer; the returned value
cannot be modified! Unless you document that, your function is
misleading.
And/or return const char * too.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #7
On Sat, 26 Jul 2008 11:04:26 -0400, Greg Comeau wrote:
In article
<17**********************************@m44g2000hsc. googlegroups.com>,
<vi******@gmail.comwrote:
>>When evaluated, [string literals] become char * and wchar_t *.

I forget how the standard characterized evaluated, but certainly in not
all cases does it become pointers (for instance, sizeof).
The operand of sizeof is not usually evaluated.

It's not about whether string literals are evaluated. As part of a non-
evaluated expression, string literals and other arrays are normally still
converted to pointers in at least one sense.

if (0)
puts("Hello, world!");

Even though the literal will never be evaluated, the compiler should not
complain about an invalid function argument type. In the other direction,
as part of the & operator, string literals are evaluated, but not
converted to pointers.
Jul 26 '08 #8
In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>On Sat, 26 Jul 2008 11:04:26 -0400, Greg Comeau wrote:
>In article
<17**********************************@m44g2000hsc .googlegroups.com>,
<vi******@gmail.comwrote:
>>>When evaluated, [string literals] become char * and wchar_t *.

I forget how the standard characterized evaluated, but certainly in not
all cases does it become pointers (for instance, sizeof).

The operand of sizeof is not usually evaluated.

It's not about whether string literals are evaluated. As part of a non-
evaluated expression, string literals and other arrays are normally still
converted to pointers in at least one sense.

if (0)
puts("Hello, world!");

Even though the literal will never be evaluated, the compiler should not
complain about an invalid function argument type.
This is far from the original question, but where in the standard
does it say that the compiler should not complain? (I'm not saying
it doesn't say it, just never considered this possibility.)
In the other direction,
as part of the & operator, string literals are evaluated, but not
converted to pointers.
Which was part of my point though I mischaracterized it.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #9
In article <g6*********@panix1.panix.com>,
Greg Comeau <co****@comeaucomputing.comwrote:
>In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
> if (0)
puts("Hello, world!");

Even though the literal will never be evaluated, the compiler should not
complain about an invalid function argument type.

This is far from the original question, but where in the standard
does it say that the compiler should not complain? (I'm not saying
it doesn't say it, just never considered this possibility.)
Actually, I changed my mind and I will say it doesn't say it. :)
Either way I'm curious about whatever appropriate passage you
believe sheds light on this. Thanks.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #10
On Sat, 26 Jul 2008 11:54:11 -0400, Greg Comeau wrote:
In article <g6*********@panix1.panix.com>, Greg Comeau
<co****@comeaucomputing.comwrote:
>>In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>> if (0)
puts("Hello, world!");

Even though the literal will never be evaluated, the compiler should
not complain about an invalid function argument type.

This is far from the original question, but where in the standard does
it say that the compiler should not complain? (I'm not saying it
doesn't say it, just never considered this possibility.)

Actually, I changed my mind and I will say it doesn't say it. :) Either
way I'm curious about whatever appropriate passage you believe sheds
light on this. Thanks.
The code is valid, because even though the function is never called, the
array-to-pointer conversion ensures the constraint that a function's
arguments are assignment-compatible with its parameters is not violated.
I'm sure you're familiar with this, so I've not looked up where and how
exactly the standard specifies this. If a compiler wants to warn "function
argument of array type, expected pointer", but still continues to compile
the code, it can conform to the standard while relying on the as-if rule,
but it's a horrible idea. For that reason, I claim it should not complain,
but not that it must not complain.
Jul 26 '08 #11
In article <e9***************************@cache3.tilbu1.nb.ho me.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>On Sat, 26 Jul 2008 11:54:11 -0400, Greg Comeau wrote:
>In article <g6*********@panix1.panix.com>, Greg Comeau
<co****@comeaucomputing.comwrote:
>>>In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
if (0)
puts("Hello, world!");

Even though the literal will never be evaluated, the compiler should
not complain about an invalid function argument type.

This is far from the original question, but where in the standard does
it say that the compiler should not complain? (I'm not saying it
doesn't say it, just never considered this possibility.)

Actually, I changed my mind and I will say it doesn't say it. :) Either
way I'm curious about whatever appropriate passage you believe sheds
light on this. Thanks.

The code is valid, because even though the function is never called, the
array-to-pointer conversion ensures the constraint that a function's
arguments are assignment-compatible with its parameters is not violated.
I'm sure you're familiar with this, so I've not looked up where and how
exactly the standard specifies this. If a compiler wants to warn "function
argument of array type, expected pointer", but still continues to compile
the code, it can conform to the standard while relying on the as-if rule,
but it's a horrible idea. For that reason, I claim it should not complain,
but not that it must not complain.
Actually, for some reason I saw fputs not puts, which now makes
this a different issue. Ok, so you're saying that because of the
if (0) that the puts call is not evaluated, right? If so, I don't
see how that trumps prototypes, syntax checking, etc.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #12
Greg Comeau wrote:
In article <e9***************************@cache3.tilbu1.nb.ho me.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>>On Sat, 26 Jul 2008 11:54:11 -0400, Greg Comeau wrote:
>>In article <g6*********@panix1.panix.com>, Greg Comeau
<co****@comeaucomputing.comwrote:
In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
if (0)
puts("Hello, world!");
>
>Even though the literal will never be evaluated, the compiler
>should not complain about an invalid function argument type.

This is far from the original question, but where in the standard
does
it say that the compiler should not complain? (I'm not saying it
doesn't say it, just never considered this possibility.)

Actually, I changed my mind and I will say it doesn't say it. :)
Either way I'm curious about whatever appropriate passage you
believe sheds
light on this. Thanks.

The code is valid, because even though the function is never called,
the array-to-pointer conversion ensures the constraint that a
function's arguments are assignment-compatible with its parameters is
not violated. I'm sure you're familiar with this, so I've not looked
up where and how exactly the standard specifies this. If a compiler
wants to warn "function argument of array type, expected pointer", but
still continues to compile the code, it can conform to the standard
while relying on the as-if rule, but it's a horrible idea. For that
reason, I claim it should not complain, but not that it must not
complain.

Actually, for some reason I saw fputs not puts, which now makes
this a different issue. Ok, so you're saying that because of the
if (0) that the puts call is not evaluated, right? If so, I don't
see how that trumps prototypes, syntax checking, etc.
I suppose the translation phases that do those things never get to see
the function in question.

Jul 26 '08 #13
In article <g6**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>Greg Comeau wrote:
>In article <e9***************************@cache3.tilbu1.nb.ho me.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>>>On Sat, 26 Jul 2008 11:54:11 -0400, Greg Comeau wrote:
In article <g6*********@panix1.panix.com>, Greg Comeau
<co****@comeaucomputing.comwrote:
>In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
>Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
> if (0)
> puts("Hello, world!");
>>
>>Even though the literal will never be evaluated, the compiler
>>should not complain about an invalid function argument type.
>
>This is far from the original question, but where in the standard
>does
>it say that the compiler should not complain? (I'm not saying it
>doesn't say it, just never considered this possibility.)

Actually, I changed my mind and I will say it doesn't say it. :)
Either way I'm curious about whatever appropriate passage you
believe sheds
light on this. Thanks.

The code is valid, because even though the function is never called,
the array-to-pointer conversion ensures the constraint that a
function's arguments are assignment-compatible with its parameters is
not violated. I'm sure you're familiar with this, so I've not looked
up where and how exactly the standard specifies this. If a compiler
wants to warn "function argument of array type, expected pointer", but
still continues to compile the code, it can conform to the standard
while relying on the as-if rule, but it's a horrible idea. For that
reason, I claim it should not complain, but not that it must not
complain.

Actually, for some reason I saw fputs not puts, which now makes
this a different issue. Ok, so you're saying that because of the
if (0) that the puts call is not evaluated, right? If so, I don't
see how that trumps prototypes, syntax checking, etc.

I suppose the translation phases that do those things never get to see
the function in question.
Which returns me asking (though now for a different reason)
where that is said in the standard.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #14
On Sat, 26 Jul 2008 12:41:57 -0400, Greg Comeau wrote:
>>>>In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
if (0)
puts("Hello, world!");
>
>Even though the literal will never be evaluated, the compiler should
>not complain about an invalid function argument type.
[snip]
Ok, so you're saying that because of the if (0) that
the puts call is not evaluated, right?
Right.
If so, I don't see how that
trumps prototypes, syntax checking, etc.
It doesn't. That's my point. The original claim was "When evaluated,
[string literals] become char * and wchar_t *." I am trying to say that
they also become char * and wchar_t *, at least in one sense, when not
evaluated, because that's the only way a compiler can sanely accept the
code.
Jul 26 '08 #15
In article <83***************************@cache4.tilbu1.nb.ho me.nl>,
Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
>On Sat, 26 Jul 2008 12:41:57 -0400, Greg Comeau wrote:
>>>>>In article <34**************************@cache4.tilbu1.nb.hom e.nl>,
>Harald van =?UTF-8?b?RMSzaw==?= <tr*****@gmail.comwrote:
> if (0)
> puts("Hello, world!");
>>
>>Even though the literal will never be evaluated, the compiler should
>>not complain about an invalid function argument type.

[snip]
>Ok, so you're saying that because of the if (0) that
the puts call is not evaluated, right?

Right.
>If so, I don't see how that
trumps prototypes, syntax checking, etc.

It doesn't. That's my point. The original claim was "When evaluated,
[string literals] become char * and wchar_t *." I am trying to say that
they also become char * and wchar_t *, at least in one sense, when not
evaluated, because that's the only way a compiler can sanely accept the
code.
Coming full circle, I'd posted that I wanted to avoid "evaluated",
the reasons was because I don't recall it being the correct term that
describes this, nor do I recall everything evaluated or the correct
term describes/imples. However, I think converted describes it
because it can handle the non-evaluated situation, which if I recall,
is the superset and only situation, and does not need to occur at
runtime, although I could be recalling incorrectly. If not, it'll
not doubt jog somebody else's memory so long as both of us are not
looking it up :)
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Jul 26 '08 #16

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

21
by: Nitin Bhardwaj | last post by:
Hi all, It is said that C++ is a strongly typed language and thus a type-safe language (unlike C). So how does one explain the following behaviour : int main(void) { char *p = NULL; p = "A...
16
by: Don Starr | last post by:
When applied to a string literal, is the sizeof operator supposed to return the size of the string (including nul), or the size of a pointer? For example, assuming a char is 1 byte and a char *...
17
by: Olivier Bellemare | last post by:
I've tried to make a function that returns the middle of a string. For example: strmid("this is a text",6,4); would return "is a". Here is my code: char *strmid(char *texte, int depart,...
7
by: al | last post by:
char s = "This string literal"; or char *s= "This string literal"; Both define a string literal. Both suppose to be read-only and not to be modified according to Standard. And both have...
12
by: Charlie Zender | last post by:
Hi, I am unable to compile a large body of code with extremely pedantic compile time checks activate, so that warnings cause errors. With GCC 3.3.1, I do this with gcc -std=c99 -pedantic...
8
by: junky_fellow | last post by:
what would be the output for the following piece of code ? if ( "hello" == "hello" ) printf("True\n"); else printf("False\n"); What is the reason for that ?
6
by: Darryn Ross | last post by:
Hi... I am not sure how to test the type of an object that i define object a = "test" ; object b = 1 ; object c = true ; how do i test each of the three objects to find out what types they...
5
by: polas | last post by:
Good morning, I have a quick question to clear up some confusion in my mind. I understand that using a string literal in a declaration such as char *p = "string literal" declares a pointer to...
4
by: zaimoni | last post by:
I've already calculated that the following are valid and should not error, as both just end up with the character literal 'A' being their control expression. The unspecified value of the char*...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.