Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Returning a struct from a function - strange behavior

Reply
Thread Tools

Returning a struct from a function - strange behavior

 
 
DiAvOl
Guest
Posts: n/a
 
      10-07-2008
Hello everyone,

Please take a look at the following code:

#include <stdio.h>

typedef struct person {
char name[40];
int age;
} Person;

static Person make_person(void);

int main(void) {
printf("%s\n", make_person().name);

return 0;
}

static Person make_person(void) {
static Person p = { "alexander", 18 };

return p;
}

The above small program when compiled without the -std=c99 option
(using gcc 4.2.3) gives me a warning:
"warning: format ‘%s’ expects type ‘char *’, but argument 2 has type
‘char[40]’"
and also fails with a segmentation fault when executed.

If I replace the line printf("%s\n", make_person().name); with
printf("%s\n", &make_person().name[0]); everything works as expected.

Why does this happen? Isn't make_person().name a pointer to the
array's first element?

Someone replied to this (in the gcc bugzilla), I am quoting the
answer:

"make_person().name is a non-lvalue array, so it only decays to a
pointer
for C99, not for C90. If you use -std=c99/-std=gnu99 then the
program
works.

The program does not, however, have defined behavior for C99, only
for
C1x. In C99 the lifetime of the array ends at the next sequence
point,
before the call to printf. In C1x it instead ends at the end of the
evaluation of the containing full expression, which is the call to
printf.

I do not believe any changes to GCC are needed to implement this
particular C1x requirement, since GCC discards information about
variables
lifetimes smaller than a function for gimplification and tree
optimizations that may change those lifetimes, so it will in practice
treat the lifetime as being anywhere it cannot show the temporary not
to
be live."

I can't understand why make_person().name is not an lvalue array and
only decays to a pointer for C99. Can someone please explain this?

Also what does this guy mean with the line "In C99 the lifetime of the
array ends at the next sequence point,
before the call to printf"? A function call is a sequence point?

I am having a hard time understanding this one, any help appreciated
Thanks for your time

PS. I tried the lcc compiler which compiled the code without warnings/
errors
 
Reply With Quote
 
 
 
 
DiAvOl
Guest
Posts: n/a
 
      10-07-2008
One more question:

Is there any (Person) variable created in main to hold the
make_person() return value?
If this is the case, does all the values from the returned struct be
copied to the variable mentioned above?
 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      10-07-2008
DiAvOl <(E-Mail Removed)> wrote:
> Hello everyone,
>
> Please take a look at the following code:
>
> #include <stdio.h>
>
> typedef struct person {
> * char name[40];
> * int age;
>
> } Person;
>
> static Person make_person(void);
>
> int main(void) {
> * printf("%s\n", make_person().name);
> * return 0;
> }
>
> static Person make_person(void) {
> * static Person p = { "alexander", 18 };
> * return p;
> }
>
> The above small program when compiled without the
> -std=c99 option (using gcc 4.2.3) gives me a warning:
> "warning: format ‘%s’ expects type ‘char *’, but
> argument 2 has type ‘char[40]’"
> and also fails with a segmentation fault when executed.


That's a bug in gcc 4.2.3 then. [The same segfault
happens with -ansi.]

> If I replace the line printf("%s\n", make_person().name);
> with printf("%s\n", &make_person().name[0]); everything
> works as expected.
>
> Why does this happen?


Because there's a bug in gcc 4.2.3.

> Isn't make_person().name a pointer to the array's first
> element?


Since it's not the operand to an unary & or sizeof operator,
yes.

> Someone replied to this (in the gcc bugzilla), I am
> quoting the answer:
>
> "make_person().name is a non-lvalue array, so it only
> decays to a pointer for C99, not for C90.


Ask them for chapter and verse. And ask them why
printf("%s\n", "hello") isn't ill formed for the same
reason.

C89 (draft):

"An lvalue is an expression (with an object
type or an incomplete type other than void) that
designates an object."

"Except when it is the operand of the sizeof
operator or the unary & operator, or is a character string
literal used to initialize an array of character type, or
is a wide string literal used to initialize an array with
element type compatible with wchar_t, an lvalue that has
type ``array of type '' is converted to an expression that
has type ``pointer to type '' that points to the initial
member of the array object and is not an lvalue.

C99:

6.3.2.1p1 "An lvalue is an expression (with an object
type or an incomplete type other than void) that designates
an object."

6.3.2.1p3 "Except when it is the operand of the sizeof
operator or the unary & operator, or is a string literal
used to initialize an array, an expression that has type
‘‘array of type’’ is converted to an expression with type
‘‘pointer to type’’ that points to the initial element of
the array object and is not an lvalue."

An lvalue is only explicitly required in C90. But in either
case, make_person().name is an lvalue.

--
Peter
 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      10-07-2008
On Mon, 6 Oct 2008 18:34:34 -0700 (PDT), DiAvOl <(E-Mail Removed)>
wrote:

>One more question:
>
>Is there any (Person) variable created in main to hold the
>make_person() return value?


Officially, it is an implementation detail about which the standard
imposes no requirement.

Practically, if you had ignored the return value, the answer might be
no. Since you use the return value, the answer is almost definitely
yes. But the variable in question is one of those temporary
constructs known only to the compiler. There is no way for you to
access it. Since it has no name, one could argue that it is not a
variable or object.

>If this is the case, does all the values from the returned struct be
>copied to the variable mentioned above?


Possibly. Maybe even probably. Under the "how would you tell the
difference" concept, the compiler could probably determine you only
need the member name and not copy the member age.

By the way, since the structure is returned by value, there is no need
for it to be static in your function.

--
Remove del for email
 
Reply With Quote
 
lovecreatesbeauty@gmail.com
Guest
Posts: n/a
 
      10-07-2008
On Oct 7, 9:23*am, DiAvOl <(E-Mail Removed)> wrote:
> int main(void) {
> * printf("%s\n", make_person().name);
>
> * return 0;
>
> }
>


why don't you code it in this way.

int main(void){
Person p;

p = make_person();
printf("%s\n", p.name);

/*printf("%s\n", make_person().name);*/
return 0;
}
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-07-2008
Peter Nilsson <(E-Mail Removed)> writes:
> DiAvOl <(E-Mail Removed)> wrote:
>> Hello everyone,
>>
>> Please take a look at the following code:
>>
>> #include <stdio.h>
>>
>> typedef struct person {
>> Â* char name[40];
>> Â* int age;
>>
>> } Person;
>>
>> static Person make_person(void);
>>
>> int main(void) {
>> Â* printf("%s\n", make_person().name);
>> Â* return 0;
>> }
>>
>> static Person make_person(void) {
>> Â* static Person p = { "alexander", 18 };
>> Â* return p;
>> }
>>
>> The above small program when compiled without the
>> -std=c99 option (using gcc 4.2.3) gives me a warning:
>> "warning: format ‘%s’ expects type ‘char *’, but
>> argument 2 has type ‘char[40]’"
>> and also fails with a segmentation fault when executed.

>
> That's a bug in gcc 4.2.3 then. [The same segfault
> happens with -ansi.]


No, I don't think it's a bug.

[...]
>> Someone replied to this (in the gcc bugzilla), I am
>> quoting the answer:
>>
>> "make_person().name is a non-lvalue array, so it only
>> decays to a pointer for C99, not for C90.

>
> Ask them for chapter and verse. And ask them why
> printf("%s\n", "hello") isn't ill formed for the same
> reason.


Because "hello" refers to an object of type char[6]; see the
definition of a string literal. There's no object of type Person.

A function returns a value. There isn't necessarily an object
associated with that value. Given:

int func(void) { return 42; }

func returns the value 42; there's no object whose address you could
take, such that dereferencing that address would give you the value
42.

[...]

> An lvalue is only explicitly required in C90. But in either
> case, make_person().name is an lvalue.


I don't believe it is. make_person() yields a value of type Person.
make_person().age yields a value of type int. make_person().name
reveals an anomaly in the C type system; it should be a value of type
char[40], which should decay to a pointer to the first element of the
corresponding array object, but there is no array object, just a
value.

And this specific case is why the following was added in n1336, the
first C201X draft (6.2.4p7):

A non-lvalue expression with structure or union type, where the
structure or union contains a member with array type (including,
recursively, members of all contained structures and unions)
refers to an object with automatic storage duration and _temporary
lifetime_ 29). Its lifetime begins when the expression is
evaluated and its initial value is the value of the
expression. Its lifetime ends when the evaluation of the
containing full expression or full declarator ends. Any attempt to
modify an object with temporary lifetime results in undefined
behavior.

Footnote 29 says:

The address of such an object is taken implicitly when an array
member is accessed.

This new rule means that there is an object of type Person, causing
make_person.name() to be an lvalue. In C90 or C99, it's not an
lvalue.

--
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
 
Keith Thompson
Guest
Posts: n/a
 
      10-07-2008
"(E-Mail Removed)" <(E-Mail Removed)> writes:
> On Oct 7, 9:23*am, DiAvOl <(E-Mail Removed)> wrote:
>> int main(void) {
>> * printf("%s\n", make_person().name);
>>
>> * return 0;
>>
>> }
>>

>
> why don't you code it in this way.
>
> int main(void){
> Person p;
>
> p = make_person();
> printf("%s\n", p.name);
>
> /*printf("%s\n", make_person().name);*/
> return 0;
> }


Because that doesn't illustrate the point.

--
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
 
jacob navia
Guest
Posts: n/a
 
      10-07-2008
DiAvOl wrote:
> Hello everyone,
>
> Please take a look at the following code:
>
> #include <stdio.h>
>
> typedef struct person {
> char name[40];
> int age;
> } Person;
>
> static Person make_person(void);
>
> int main(void) {
> printf("%s\n", make_person().name);
>
> return 0;
> }
>
> static Person make_person(void) {
> static Person p = { "alexander", 18 };
>
> return p;
> }
>
> The above small program when compiled without the -std=c99 option
> (using gcc 4.2.3) gives me a warning:
> "warning: format ‘%s’ expects type ‘char *’, but argument 2 has type
> ‘char[40]’"
> and also fails with a segmentation fault when executed.
>
> If I replace the line printf("%s\n", make_person().name); with
> printf("%s\n", &make_person().name[0]); everything works as expected.
>
> Why does this happen? Isn't make_person().name a pointer to the
> array's first element?
>
> Someone replied to this (in the gcc bugzilla), I am quoting the
> answer:
>
> "make_person().name is a non-lvalue array, so it only decays to a
> pointer
> for C99, not for C90. If you use -std=c99/-std=gnu99 then the
> program
> works.
>
> The program does not, however, have defined behavior for C99, only
> for
> C1x. In C99 the lifetime of the array ends at the next sequence
> point,
> before the call to printf. In C1x it instead ends at the end of the
> evaluation of the containing full expression, which is the call to
> printf.
>
> I do not believe any changes to GCC are needed to implement this
> particular C1x requirement, since GCC discards information about
> variables
> lifetimes smaller than a function for gimplification and tree
> optimizations that may change those lifetimes, so it will in practice
> treat the lifetime as being anywhere it cannot show the temporary not
> to
> be live."
>
> I can't understand why make_person().name is not an lvalue array and
> only decays to a pointer for C99. Can someone please explain this?
>
> Also what does this guy mean with the line "In C99 the lifetime of the
> array ends at the next sequence point,
> before the call to printf"? A function call is a sequence point?
>
> I am having a hard time understanding this one, any help appreciated
> Thanks for your time
>
> PS. I tried the lcc compiler which compiled the code without warnings/
> errors



Yes, lcc-win compiles and executes correctly your code. As does
MSVC, that correctly executes it.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
lovecreatesbeauty@gmail.com
Guest
Posts: n/a
 
      10-07-2008
On Oct 7, 2:57*pm, Keith Thompson <(E-Mail Removed)> wrote:
> "(E-Mail Removed)" <(E-Mail Removed)> writes:
> > On Oct 7, 9:23*am, DiAvOl <(E-Mail Removed)> wrote:
> >> int main(void) {
> >> * printf("%s\n", make_person().name);

>
> >> * return 0;

>
> >> }

>
> > why don't you code it in this way.

>
> > int main(void){
> > * * * * Person p;

>
> > * * * * p = make_person();
> > * * * * printf("%s\n", p.name);

>
> > * * * * /*printf("%s\n", make_person().name);*/
> > * * * * return 0;
> > }

>
> Because that doesn't illustrate the point.
>


The op's code is wrong and my revision is right, isn't it?
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      10-07-2008
On 7 Oct, 09:28, "(E-Mail Removed)"
<(E-Mail Removed)> wrote:
> On Oct 7, 2:57*pm, Keith Thompson <(E-Mail Removed)> wrote:
>
>
>
>
>
> > "(E-Mail Removed)" <(E-Mail Removed)> writes:
> > > On Oct 7, 9:23*am, DiAvOl <(E-Mail Removed)> wrote:
> > >> int main(void) {
> > >> * printf("%s\n", make_person().name);

>
> > >> * return 0;

>
> > >> }

>
> > > why don't you code it in this way.

>
> > > int main(void){
> > > * * * * Person p;

>
> > > * * * * p = make_person();
> > > * * * * printf("%s\n", p.name);

>
> > > * * * * /*printf("%s\n", make_person().name);*/
> > > * * * * return 0;
> > > }

>
> > Because that doesn't illustrate the point.

>
> The op's code is wrong and my revision is right, isn't it


the point is that it is not obvious why the OPs code is
wrong. It surprised me.

--
Nick Keighley

 
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
Can *common* struct-members of 2 different struct-types, that are thesame for the first common members, be accessed via pointer cast to either struct-type? John Reye C Programming 28 05-08-2012 12:24 AM
Returning a Struct from a Function alex.j.k2@gmail.com C++ 12 05-20-2008 08:55 AM
portability problem with a function returning a struct Army1987 C Programming 19 05-19-2007 10:07 PM
Access from function in struct (pointer to function) to other items in the struct (advanced) Ole C Programming 4 10-26-2004 09:43 PM
struct my_struct *p = (struct my_struct *)malloc(sizeof(struct my_struct)); Chris Fogelklou C Programming 36 04-20-2004 08:27 AM



Advertisments