Returning a struct from a function - strange behavior

[DiAvOl]

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

[jacob navia]

James Kuyper wrote:

Nick Keighley wrote:

>On 8 Oct, 00:41, CBFalconer <[e-mail]:

>>jacob navia wrote:
DiAvOl wrote:

If I've understood the rest of the thread. This is Undefined
Behaviour.

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

how can it be "correct" if its Undefined Behaviour?

All behavior is correct when the behavior is not defined by the
standard. However, what jacob means by "correct" is somewhat more
restrictive: it behaves in the manner that a reasonable person (as
judged from jacob's perspective) would expect it to work.

Well, if I passed an array of characters finished by a zero
byte to printf("%s") the normal behavior is to print a character
string. What else?

>Is lcc operating in C89 or C99 mode?

He's talking about lcc-win, not lcc. lcc-win has no mode in which it
fully conforms to either standard.

My compiler conforms to C99. It will compile C89 code without any
problems and nit conforms fully to the C89 standard also. The only
"problem" is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

Pedans in this group like to say then that "it doesn't conform to any
standard" since they are just that

PEDANTS

Incidentally, the behavior produced
by lcc-win is the same as that specified by the proposed draft for the
next version of the standard, and arguably the same behavior that was
intended to be correct in C99. That gives the term "correct" a little
more appropriateness.

Correct. :-)

However, I suspect that this is just a coincidence.

Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

Quite a clear logic isn't it?

These people are unable to think clearly beyond their pedantics ramblings

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[vippstar]

On Oct 8, 2:43 pm, jacob navia <[e-mail]:

>
Pedans in this group like to say then that "it doesn't conform to any
standard" since they are just that

PEDANTS

IDIOT.

[Richard Heathfield]

jacob navia said:

James Kuyper wrote:

<snip>

>lcc-win has no mode in which it fully conforms to either standard.

My compiler conforms to C99.

That's a significant claim.

It will compile C89 code without any
problems and nit conforms fully to the C89 standard also.

That's a significant claim, too.

The only
"problem" is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

This would appear to mean that your claim about C89 conformance is not only
significant but also false - and this leads me to wonder out loud about
your C99 conformance claim, too.

Pedans in this group like to say then that "it doesn't conform to any
standard" since they are just that

PEDANTS

The word "pedant" is used by people who don't care about correctness to
describe people who do.

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

[James Kuyper]

jacob navia wrote:

James Kuyper wrote:

....

>He's talking about lcc-win, not lcc. lcc-win has no mode in which it
fully conforms to either standard.

My compiler conforms to C99.

I was very careful to use the phrase "fully conforms", because I knew
that you misunderstand the unmodified term "conform" as allowing less
than full conformance. Or is this an assertion that you've finally
finished implementing even those C99 features that you had previously
dismissed as "unimportant"? If so, you should have announced that fact.

... It will compile C89 code without any
problems and nit conforms fully to the C89 standard also. The only
"problem" is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

Since those diagnostics are mandatory for C89, that makes it
non-conforming, and in a way that's pretty important to me.

I currently work under a requirement that my code "conform" to C90 (more
precisely, C90 + the applicable TCs). The idiots who wrote that
requirement were unaware of the definition used by the C standard for
conforming code, so it's trivial to meet the letter of that requirement.
However, to satisfy the spirit of that requirement, I need a compiler
that actually produces the diagnostics that C90 mandates. lcc-win32 doesn't.

Pedans in this group like to say then that "it doesn't conform to any
standard" since they are just that

PEDANTS

I'm glad you noticed. Pedants hate to be mis-identified. Coming from
you, the term is a compliment, precisely because you do not intend it to
be one.

>Incidentally, the behavior produced by lcc-win is the same as that
specified by the proposed draft for the next version of the standard,
and arguably the same behavior that was intended to be correct in C99.
That gives the term "correct" a little more appropriateness.

Correct. :-)

>However, I suspect that this is just a coincidence.

Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

Quite a clear logic isn't it?

That's not my logic. My logic was that the low priority you've attached
to standard conformance in the past suggests that you implemented this
feature this way because it made sense to you, and not because you were
aware of the intention to add wording to the next version of the C
standard to make it mandatory. I would have guessed that you implemented
this feature long before it was even proposed for the next version of
the standard. Am I wrong about that?

[lawrence.jones]

la************@siemens.com wrote:

Keith Thompson <ks***@mib.orgwrote:

I *think* that the behavior is undefined in both C90 and C99 (but
becomes well defined in C201X).

No, support for non-lvalue arrays was added in C99.

It's been pointed out to me in e-mail that the original code passes the
array to printf which then attempts to access it after the next sequence
point (which would be the one right before the call), so it actually
*is* undefined behavior in C99, despite the support for non-lvalue
arrays. The current rules in C1X say the temporary object exists until
the end of the full expression that creates it, which does make it well
defined. As has been pointed out elsethread, there's no guarantee that
those rules won't change, although I sincerely doubt that they're going
to go away completely.
--
Larry Jones

I don't want to be THIS good! -- Calvin

[lawrence.jones]

Keith Thompson <ks***@mib.orgwrote:

>
Arrays in C are almost always treated as second-class objects. It's
almost impossible to obtain an expression of array type that doesn't
refer to an array object. I believe this can *only* occur when the
array is a member of a struct or union, and that struct or union is
returned from a function -- which is itself the only way (I think) to
obtain an expression of struct or union type that doesn't refer to an
object of struct or union type.

Non-lvalue structs/unions can also occur as the result of an assignment,
comma, or conditional operator.
--
Larry Jones

But Mom, frogs are our FRIENDS! -- Calvin

[lawrence.jones]

jacob navia <ja***@nospam.comwrote:

>
My compiler conforms to C99.

No, it doesn't. It *mostly* conforms, if you like, but until you
implement *all* of the requirements, not just the "important" ones, it
does not (fully) conform.

It will compile C89 code without any
problems and nit conforms fully to the C89 standard also.

That is blatantly untrue. There are obscure C89 constructs that it
miscompiles because it interprets them as containing C99 constructs.
Also...

The only "problem"
is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

That's not a "problem", it's a *problem*. C89 *requires* diagnostics in
certain circumstances. If your compiler doesn't emit those diagnostics,
then it does *not* fully conform. You can say it *mostly* conforms if
you like, but please stop lying to people.

However, I suspect that this is just a coincidence.

Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

No, you seem uninterested in the details of what the standards require
and you haven't given any indication that you've even looked at the C1X
draft, so conforming to something new in it is more likely coincidental
than intentional.
--
Larry Jones

What's Santa's definition? How good do you have to be to qualify as good?
-- Calvin

[Nick Keighley]

On 8 Oct, 12:09, James Kuyper <[e-mail]:

Nick Keighley wrote:

On 8 Oct, 00:39, CBFalconer <[e-mail]:

Nick Keighleywrote:

>so is the program incorrect? Or did a particular version of gcc
have a bug? If the program is exhibiting UB then translating it and
running it to produce the "expected" behaviour is perfectly ok!

The program is incorrect. *There is no requirement for UB to cause
an error message.

sorry? If its UB it can anything it likes. There may be no
requirement
to produce an error message (a diagnostic) but there can't be
anything
wrong with producing a diagnostic. So why is (this version) of gcc
buggy?

He said "the program is incorrect". How did you manage to misinterpret
that as a statement that gcc is buggy

having re-read this part of the thread. I have no idea how I managed
to read that gcc was buggy. I was quite confused at the time. I
understood
Chuck to be saying that it *should* produce a diagnostic.

Also, Lawrence said that gcc was incorrect.

--
Nick Keighley

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

James Kuyper wrote:

>Nick Keighley wrote:

>>On 8 Oct, 00:41, CBFalconer <[e-mail]:
jacob navia wrote:
DiAvOl wrote:

If I've understood the rest of the thread. This is Undefined
Behaviour.

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

how can it be "correct" if its Undefined Behaviour?

All behavior is correct when the behavior is not defined by the
standard. However, what jacob means by "correct" is somewhat more
restrictive: it behaves in the manner that a reasonable person (as
judged from jacob's perspective) would expect it to work.

Well, if I passed an array of characters finished by a zero
byte to printf("%s") the normal behavior is to print a character
string. What else?

If you actually manage to pass an *array* to printf, presumably the
behavior is undefined. If you pass a pointer to the first element of
such an array, then of course it will behave as expected.

No doubt you'll think I'm playing "word games", but the specific
possibility of passing an actual array value rather than a pointer
value to printf has been discussed in this thread.

>>Is lcc operating in C89 or C99 mode?

He's talking about lcc-win, not lcc. lcc-win has no mode in which it
fully conforms to either standard.

My compiler conforms to C99. It will compile C89 code without any
problems and nit conforms fully to the C89 standard also. The only
"problem" is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

You've said that there are some "unimportant" features of C99 that
lcc-win does not yet implement. Are you saying that's no longer the
case? Does lcc-win FULLY CONFORM to C99? For example, do variadic
macros work? If so, that's great news.

As for C89 conformance, are the diagnostics required by the standard
also "unimportant"? They're quite important to some of us.

How does lcc-win handle this program?

#include <stdio.h>
int main(void)
{
int restrict = 6;
int inline = 7;
printf("%d\n", restrict * inline);
return 0;
}

Pedans in this group like to say then that "it doesn't conform to any
standard" since they are just that

PEDANTS

Yes, because we are pedants and because it's a true statement.

>Incidentally, the behavior produced by lcc-win is the same as that
specified by the proposed draft for the next version of the
standard, and arguably the same behavior that was intended to be
correct in C99. That gives the term "correct" a little more
appropriateness.

Correct. :-)

>However, I suspect that this is just a coincidence.

Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

Quite a clear logic isn't it?

These people are unable to think clearly beyond their pedantics ramblings

Did you notice the word "suspect"? I notice that you don't attempt to
refute his statement, just ridicule him personally.

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

[Keith Thompson]

la************@siemens.com writes:

la************@siemens.com wrote:

>Keith Thompson <ks***@mib.orgwrote:

>
I *think* that the behavior is undefined in both C90 and C99 (but
becomes well defined in C201X).

No, support for non-lvalue arrays was added in C99.

It's been pointed out to me in e-mail that the original code passes the
array to printf which then attempts to access it after the next sequence
point (which would be the one right before the call), so it actually
*is* undefined behavior in C99, despite the support for non-lvalue
arrays. The current rules in C1X say the temporary object exists until
the end of the full expression that creates it, which does make it well
defined. As has been pointed out elsethread, there's no guarantee that
those rules won't change, although I sincerely doubt that they're going
to go away completely.

Where does C99 say that the array may be accessed *before* the next
sequence point?

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

[Antoninus Twink]

On 8 Oct 2008 at 12:08, vi******@gmail.com wrote:

IDIOT.

Ah, it's good to know that reasoned debate isn't dead.

[lovecreatesbeauty]

On Oct 8, 9:41 am, Keith Thompson <[e-mail]:

>
the behavior is undefined. But when you assign the result of
make_person() to the object p, the expression p.name *is* an lvalue,
the conversion does occur, and everything works.

It's me but not the op, remember :)

>
Your best bet, if you're actually
trying to get some work done, is to avoid the issue and use an
explicit temporary.

This piece of code of mine already applied your suggestion, didn't it?

int main(void)
{
Person p;

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

/* printf("%s\n", make_person().name); */

return 0;
}

[jacob navia]

James Kuyper wrote:

jacob navia wrote:

>Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

Quite a clear logic isn't it?

That's not my logic. My logic was that the low priority you've attached
to standard conformance in the past

[snip]

"the low priority I have attached to standard conformance"
has led me to work something like 5 years to implement C99.

A continuous work that led me to implement the whole C library,
all the syntax changes necessary, all the tests, correct all the
bug reports, and work year after year to implement standard
C.

And after all this effort I have to hear from somebody

"... the low priority you attach to standard conformance"

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

>My compiler conforms to C99.

No, it doesn't. It *mostly* conforms, if you like, but until you
implement *all* of the requirements, not just the "important" ones, it
does not (fully) conform.

I do not care about your opinion.

>It will compile C89 code without any
problems and nit conforms fully to the C89 standard also.

That is blatantly untrue. There are obscure C89 constructs that it
miscompiles because it interprets them as containing C99 constructs.
Also...

Ditto. If you use C99 constructs in your code it will accept
them. Pedants notwithstanding.

>The only "problem"
is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

That's not a "problem", it's a *problem*. C89 *requires* diagnostics in
certain circumstances. If your compiler doesn't emit those diagnostics,
then it does *not* fully conform. You can say it *mostly* conforms if
you like, but please stop lying to people.

Sure, I am lying etc...

Ditto: I do not care about your opinion.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jameskuyper]

jacob navia wrote:

James Kuyper wrote:

jacob navia wrote:

Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

Quite a clear logic isn't it?

That's not my logic. My logic was that the low priority you've attached
to standard conformance in the past

[snip]

"the low priority I have attached to standard conformance"
has led me to work something like 5 years to implement C99.

A continuous work that led me to implement the whole C library,
all the syntax changes necessary, all the tests, correct all the
bug reports, and work year after year to implement standard
C.

And after all this effort I have to hear from somebody

"... the low priority you attach to standard conformance"

You haven't finished the work yet. You've finished work on numerous
extensions before finishing work on the base language. That implies
that you gave ALL of those extensions a higher priority than full
conformance; by my standards, that counts as a low priority. I'm not
criticizing your priorities; they're not my priorities, so I would
have no use for your compiler, but it's presumably considered a useful
compiler by those who share your priorities. If that market's as big
as you think, you should have a profitable product, and I see nothing
wrong with you collecting those profits. However, please don't deny
that you have prioritized your extensions over full conformance.

I notice that you did not address the truth (or lack thereof) of my
guesses as to why you implemented this particular feature.

[jameskuyper]

jacob navia wrote:

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

My compiler conforms to C99.

No, it doesn't. It *mostly* conforms, if you like, but until you
implement *all* of the requirements, not just the "important" ones, it
does not (fully) conform.

I do not care about your opinion.

That it doesn't conform isn't a matter of opinion, it's a matter of
fact. It's an opinion whether or not that lack of conformance is
important, and you're entitled to the opinion that it's unimportant.
That opinion will make it impossible for you to sell or even give away
your product to anyone like me who actively relies upon that
particular aspect of conformance, but then I'm obviously not an
example of the target audience for your product.

....

That's not a "problem", it's a *problem*. C89 *requires* diagnostics in
certain circumstances. If your compiler doesn't emit those diagnostics,
then it does *not* fully conform. You can say it *mostly* conforms if
you like, but please stop lying to people.

Sure, I am lying etc...

Ditto: I do not care about your opinion.

Nonetheless, a paying customer who actually needs C90 conformance
could sue you for misrepresentation if you claimed it, and because of
the absence of these mandatory diagnostics, such a customer would have
a valid case.
I'm thinking in terms of American law; I'm not sure if this would be
case in France. The complaint would still be valid, but I don't know
how easy it would be to file a lawsuit based upon it.

[vippstar]

On Oct 8, 8:53 pm, [e-mail] wrote:

jacob navia wrote:

[ about jacob claiming conformance ]

Nonetheless, a paying customer who actually needs C90 conformance
could sue you for misrepresentation if you claimed it, and because of
the absence of these mandatory diagnostics, such a customer would have
a valid case.
I'm thinking in terms of American law; I'm not sure if this would be
case in France. The complaint would still be valid, but I don't know
how easy it would be to file a lawsuit based upon it.

I don't think such case would have any luck. Jacob could just claim
it's a bug he wasn't aware of. Else everyone would be able to sue any
buggy software and get money.

[Antoninus Twink]

On 8 Oct 2008 at 18:21, vi******@gmail.com wrote:

On Oct 8, 8:53 pm, [e-mail] wrote:

>Nonetheless, a paying customer who actually needs C90 conformance
could sue you for misrepresentation if you claimed it, and because of
the absence of these mandatory diagnostics, such a customer would have
a valid case.

I don't think such case would have any luck. Jacob could just claim
it's a bug he wasn't aware of.

Hardly necessary - the courts would probably be a lot less legalistic
then the average clc Heathfield-wannabe. The law has the notion of a
"reasonable person", which is a foreign concept to most clc'ers.

[Keith Thompson]

vi******@gmail.com writes:

On Oct 8, 8:53 pm, [e-mail] wrote:

>jacob navia wrote:

[ about jacob claiming conformance ]

>Nonetheless, a paying customer who actually needs C90 conformance
could sue you for misrepresentation if you claimed it, and because of
the absence of these mandatory diagnostics, such a customer would have
a valid case.
I'm thinking in terms of American law; I'm not sure if this would be
case in France. The complaint would still be valid, but I don't know
how easy it would be to file a lawsuit based upon it.

I don't think such case would have any luck. Jacob could just claim
it's a bug he wasn't aware of. Else everyone would be able to sue any
buggy software and get money.

He'd have to claim that somebody else has been posting to Usenet under
his name. He's publicly acknowledged here that lcc-win doesn't
produce diagnostics that are required for C90 conformance. I don't
think he's actually acknowledged that those diagnostics are required,
but that's a matter of fact that can be inferred by reading the
standard.

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

[Harald van =?UTF-8?b?RMSzaw==?=]

On Wed, 08 Oct 2008 08:45:02 -0700, Keith Thompson wrote:

la************@siemens.com writes:

>la************@siemens.com wrote:

>>Keith Thompson <ks***@mib.orgwrote:

I *think* that the behavior is undefined in both C90 and C99 (but
becomes well defined in C201X).

No, support for non-lvalue arrays was added in C99.

It's been pointed out to me in e-mail that the original code passes the
array to printf which then attempts to access it after the next
sequence point (which would be the one right before the call), so it
actually *is* undefined behavior in C99, despite the support for
non-lvalue arrays. [...]

Where does C99 say that the array may be accessed *before* the next
sequence point?

6.2.4p1:
"An object has a storage duration that determines its lifetime. There are
three storage durations: static, automatic, and allocated. [...]"

There are specific exceptions for accessing temporary objects after the
next sequence point. There is no such exception for accessing them before,
so you are allowed to access them until the end of their lifetime, which
is later for all three possible storage durations.

[Keith Thompson]

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

la************@siemens.com writes:

>la************@siemens.com wrote:

>>Keith Thompson <ks***@mib.orgwrote:

I *think* that the behavior is undefined in both C90 and C99 (but
becomes well defined in C201X).

No, support for non-lvalue arrays was added in C99.

It's been pointed out to me in e-mail that the original code passes the
array to printf which then attempts to access it after the next sequence
point (which would be the one right before the call), so it actually
*is* undefined behavior in C99, despite the support for non-lvalue
arrays. The current rules in C1X say the temporary object exists until
the end of the full expression that creates it, which does make it well
defined. As has been pointed out elsethread, there's no guarantee that
those rules won't change, although I sincerely doubt that they're going
to go away completely.

Where does C99 say that the array may be accessed *before* the next
sequence point?

I got an e-mail response to this:

| 6.5.2.2 P5: "If an attempt is made to modify the result of a function
| call or to access it after the next sequence point, the behavior
| is undefined."
|
| Presumably, this sentence was added to C99 specifically to address
| the case of an function returning a struct/union containing an
| array. Unfortunately, the lifetime isn't quite long enough to
| cover the case in question in this thread, and the existence of
| the necessary temporary object is implied but not stated; hence
| the clarification in C1x.
|
| [Unfortunately, I am currently unable to post to Usenet; hence
| the email.]
|
| Philip Lantz

As Philip says, the real problem in C99 is that it assumes the
existence of this object, but doesn't actually say that it exists.

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

[jacob navia]

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

jacob navia wrote:

>James Kuyper wrote:

>>jacob navia wrote:
Obviously if I have something correct it can ONLY be a coincidence,
since I am unable to produce anything correct since I am a jerk
by definition.

Quite a clear logic isn't it?
That's not my logic. My logic was that the low priority you've attached
to standard conformance in the past

[snip]

"the low priority I have attached to standard conformance"
has led me to work something like 5 years to implement C99.

A continuous work that led me to implement the whole C library,
all the syntax changes necessary, all the tests, correct all the
bug reports, and work year after year to implement standard
C.

And after all this effort I have to hear from somebody

"... the low priority you attach to standard conformance"

You haven't finished the work yet.

Lcc-win is the work of just two people, Friedrich and me.
Compared to the huge teams of gcc, not to speak about the
commercial compilers, it is the smallest team that has
ever undertaken such a huge project.

We have finished implementing the full set of core features,
and the ones that are missing are changes in the preprocessor
that I started some years ago but I haven'et got the time to
finish yet.

You've finished work on numerous
extensions before finishing work on the base language. That implies
that you gave ALL of those extensions a higher priority than full
conformance; by my standards, that counts as a low priority.

You do not give a dam about my work if it is not to denigrate it,
together with your friends in this group. Now you are telling me what I
should and should not do in my free time. You have never helped
the project with a single contribution besides your eternal
complaing about "full conformance" etc.

The fact that I do not reject // comments is taken as a serious bug,
obviously other features like 105 digits precision in the 32 bit edition
are just "extensions that are worth nothing", since for you things like
usability, the existence of a debugger, speed of compilation, etc etc
are just nothing.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[DiAvOl]

I think that the last 20-30 posts (or more) has nothing to do with the
subject of this thread, maybe creating a new subject for lcc-win32 and
post there would be a better idea

Just a thought

[vippstar]

On Oct 8, 10:45 pm, DiAvOl <[e-mail]:

I think that the last 20-30 posts (or more) has nothing to do with the
subject of this thread, maybe creating a new subject for lcc-win32 and
post there would be a better idea

Just a thought

Actually that's just how usenet works, it's not a web forum.
Many of the interesting discussions here in comp.lang.c don't have
anything to do with the subject line, or the OP question.

[jacob navia]

DiAvOl wrote:

I think that the last 20-30 posts (or more) has nothing to do with the
subject of this thread, maybe creating a new subject for lcc-win32 and
post there would be a better idea

Just a thought

When I said that lcc-win compiles and executes that
code correctly they could not stand that.

Denigrating lcc-win is the only thing they all agree with.

Why?

It is the only compiler that is not a C++ compiler that
happens to compile C.

It has several enhancements and innovations that make
this people scream like mad dogs:
o Operator overloading
o generic functions
o default arguments
The prototype figure for them is CB Falconer.

I agree with you. It would be better if I just ignore
those. Normally I stopped posting here.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[DiAvOl]

On Oct 8, 11:07*pm, [e-mail] wrote:

On Oct 8, 10:45 pm, DiAvOl <[e-mail]:

I think that the last 20-30 posts (or more) has nothing to do with the
subject of this thread, maybe creating a new subject for lcc-win32 and
post there would be a better idea

Just a thought

Actually that's just how usenet works, it's not a web forum.
Many of the interesting discussions here in comp.lang.c don't have
anything to do with the subject line, or the OP question.

so you find this discussion interesting? what exactly is interesting
about it?

I am relatively new here and all I see is some people shooting another
(jacob navia in this case)
(Also I saw many interesting replies from some interesting programmers
of course)

For me lcc-win32 is another tool I can use if I want to (to test some
code probably), if I don't like it I won't use it

Anyway thanks for (the few) interesting replies, this is my last post
for this subject I guess

[DiAvOl]

(Also I saw many interesting replies from some interesting programmers

of course)

s/many/few

[CBFalconer]

Nate Eldredge wrote:

>

.... snip ...

>
You are correct in that it needs to allocate this space even if
the return value is going to be ignored. But again, this is
already the case. As I understand it, the only difference
between the current state of affairs and what's proposed for C1x
is how long the compiler has to keep the return value intact
before it can write over it.

Are you proposing to do away entirely with the ability to return
structs from C functions? Given the problems that arise, one
might argue that adding them to C was ill-considered, but I think
it's too late to take them back now.

Don't think about the complex returned values. They already need
special handling (after all, they were even forbidden to be
returned in early C). Consider the return value from, say,
strlen. This is of type size_t, which will be some form of
integer. It is normally returned in a register, and is a value.
What if you write:

&strlen(thing);

in your code somewhere. What are you taking the address of? Why?
Why did you want to force saving all such returns in a memory
location (and possibly letting the optimizer take them all out
again)? If you really want this you can write:

thinglen = strlen(thing);
use(&thinglen);

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

[CBFalconer]

Harald van D?k wrote:

Keith Thompson wrote:

.... snip ...

>

>Where does C99 say that the array may be accessed *before* the
next sequence point?

6.2.4p1:
"An object has a storage duration that determines its lifetime.
There are three storage durations: static, automatic, and
allocated. [...]"

There are specific exceptions for accessing temporary objects
after the next sequence point. There is no such exception for
accessing them before, so you are allowed to access them until
the end of their lifetime, which is later for all three possible
storage durations.

And why do you think that a functions returned value is a C object,
if you haven't stored it in such an object?

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

[CBFalconer]

Nick Keighley wrote:

CBFalconer <[e-mail]:

>Nick Keighleywrote:

>>Martin Ambuhl <[e-mail]:

It still surprises me, since _my_ copy of gcc 4.2.3 with -W -Wall
0std=c99 -pedantic neither reports the diagnostic nor eegfaults

so is the program incorrect? Or did a particular version of gcc
have a bug? If the program is exhibiting UB then translating it and
running it to produce the "expected" behaviour is perfectly ok!

The program is incorrect. There is no requirement for UB to
cause an error message.

sorry? If its UB it can anything it likes. There may be no
requirement to produce an error message (a diagnostic) but
there can't be anything wrong with producing a diagnostic. So
why is (this version) of gcc buggy?

What bug? Failure to emit a diagnostic when no diagnostic is
required cannot be considered a bug.

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

[CBFalconer]

jacob navia wrote:

James Kuyper wrote:

>Nick Keighley wrote:

.... snip ...

>>

>>how can it be "correct" if its Undefined Behaviour?

All behavior is correct when the behavior is not defined by the
standard. However, what jacob means by "correct" is somewhat more
restrictive: it behaves in the manner that a reasonable person (as
judged from jacob's perspective) would expect it to work.

Well, if I passed an array of characters finished by a zero
byte to printf("%s") the normal behavior is to print a character
string. What else?

I doubt it will always work. For example:

typedef struct foo {char a[20]}; foo;
char ca, cb;
foo getfoo(void);
...
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);

Think about why I picked this test.

>

>>Is lcc operating in C89 or C99 mode?

He's talking about lcc-win, not lcc. lcc-win has no mode in which
it fully conforms to either standard.

My compiler conforms to C99. It will compile C89 code without any
problems and nit conforms fully to the C89 standard also. The only
"problem" is that it does NOT emit diagnostics when it sees a C99
syntax. It will correctly compile C99 constructs without emitting
any diagnostic.

You have mentioned various C99 things at which it fails.
Non-emission of non-required diagnostics is not a fault. If it was
correct, or even if it was documented properly, you wouldn't hear
the muttering.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

James Kuyper wrote:

>

.... snip ...

>
That's not my logic. My logic was that the low priority you've
attached to standard conformance in the past suggests that you
implemented this feature this way because it made sense to you,
and not because you were aware of the intention to add wording
to the next version of the C standard to make it mandatory. I
would have guessed that you implemented this feature long before
it was even proposed for the next version of the standard. Am I
wrong about that?

This discussion started a few days ago when I mentioned that I
didn't think that provision would make it into the next C standard
(so far it only exists in a discussion draft) because it would
force too many inefficiencies. I have been defending that opinion
since then. Successfully, IMO.

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

[Keith Thompson]

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

Nate Eldredge wrote:

>>

... snip ...

>>
You are correct in that it needs to allocate this space even if
the return value is going to be ignored. But again, this is
already the case. As I understand it, the only difference
between the current state of affairs and what's proposed for C1x
is how long the compiler has to keep the return value intact
before it can write over it.

Are you proposing to do away entirely with the ability to return
structs from C functions? Given the problems that arise, one
might argue that adding them to C was ill-considered, but I think
it's too late to take them back now.

Don't think about the complex returned values. They already need
special handling (after all, they were even forbidden to be
returned in early C). Consider the return value from, say,
strlen. This is of type size_t, which will be some form of
integer. It is normally returned in a register, and is a value.
What if you write:

&strlen(thing);

in your code somewhere. What are you taking the address of? Why?
Why did you want to force saving all such returns in a memory
location (and possibly letting the optimizer take them all out
again)? If you really want this you can write:

thinglen = strlen(thing);
use(&thinglen);

Here's what n1336 6.2.4p7 says (I think it's already been quoted in
this thread):

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.

And footnote 29:

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

The proposed change in n1336 applies *only* to a structure or union
that contains (directly or indirectly) an array member. In the
majority of such cases, the struct or union is already too big to fit
in a register. For any other function results, the returned value is
not stored in an object, either implicitly or explicitly (though of
course the compiler is still free to do the equivalent of storing it
in an object internally).

"&strlen(thing)" is still a constraint violation.

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

[Harald van =?UTF-8?b?RMSzaw==?=]

On Wed, 08 Oct 2008 17:37:56 -0400, CBFalconer wrote:

Harald van D?k wrote:

>Keith Thompson wrote:

... snip ...

>>

>>Where does C99 say that the array may be accessed *before* the next
sequence point?

6.2.4p1:
"An object has a storage duration that determines its lifetime.
There are three storage durations: static, automatic, and allocated.
[...]"
[...]

And why do you think that a functions returned value is a C object, if
you haven't stored it in such an object?

C does not have such a thing as a pointer to a value. If you can get a
pointer value of type pointer-to-object, and it is not null or pointing
just past the end of an object, it is a pointer to an object. Or are you
saying that the automatic conversion of array values to pointers results
(can result) in pointer non-values?

[Flash Gordon]

jacob navia wrote, On 08/10/08 21:11:

DiAvOl wrote:

>I think that the last 20-30 posts (or more) has nothing to do with the
subject of this thread, maybe creating a new subject for lcc-win32 and
post there would be a better idea

Just a thought

When I said that lcc-win compiles and executes that
code correctly they could not stand that.

Actually it was pointed out that what lcc-win does is allowed and that
Chuck was wrong to say it was a bug in lcc-win.

Denigrating lcc-win is the only thing they all agree with.

Wrong. They complain about *you* claiming it conforms to C99 even though
you know that you have not yet finished implementing C99. Personally I
would like to be able to use varidac macros as they would allow me to
greatly increase the debug facilities available to me on a significant
code-base without doing major edits to it, but that is one feature you
think is unimportant (an opinion you are entitled to but one I disagree
with).

Why?

It is the only compiler that is not a C++ compiler that
happens to compile C.

I used to use a compiler that is only a C compiler and have posted
comments about it here without anyone denigrating it so that can't be
the reason.

It has several enhancements and innovations that make
this people scream like mad dogs:
o Operator overloading
o generic functions
o default arguments

No, they complain about you discussing those extensions here.

The prototype figure for them is CB Falconer.

Hmm. In this very thread it has been pointed out that Chuck was wrong in
his claim that it was a bug in your compiler. People have even posted
that what your compiler does in this instance makes sense.

I agree with you. It would be better if I just ignore
those. Normally I stopped posting here.

Just stop taking everything as personal attacks.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/

[jacob navia]

CBFalconer wrote:

>
I doubt it will always work. For example:

typedef struct foo {char a[20]}; foo;
char ca, cb;
foo getfoo(void);
...
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);

Think about why I picked this test.

When I correct your code and write this:

typedef struct foo {char a[20];} foo;
char ca, cb;
foo getfoo(void) { foo f; f.a[0] = 'a'; f.a[1] = 0; return f; }
int main(void) {
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);
}
I obtain
' ' "a" ' '

Why?

Because lcc-win (as lcc) creates always a temporary object
when a function returns a structure. lcc-win passes a hidden
first argument to the function that contains a pointer to the
temporary variable created in the calling function.

When you write

foo f;
f = getfoo();

what gets generated is:

getfoo(&f);

When you do NOT use any variable in the assignment, lcc-win
creates an automatic temporary variable, that is why all these things
work.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[CBFalconer]

jacob navia wrote:

>

.... snip ...

>
Denigrating lcc-win is the only thing they all agree with.

Why? It is the only compiler that is not a C++ compiler that
happens to compile C.

WRONG. But not of interest.

>
It has several enhancements and innovations that make
this people scream like mad dogs:
o Operator overloading

NOT a C99 (nor C90) feature

o generic functions

NOT a C99 (nor C90) feature

o default arguments

NOT a C99 (nor C90) feature

so what has that to do with the subject?

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

[CBFalconer]

vi******@gmail.com wrote:

[e-mail] wrote:

[ about jacob claiming conformance ]

>Nonetheless, a paying customer who actually needs C90 conformance
could sue you for misrepresentation if you claimed it, and because
of the absence of these mandatory diagnostics, such a customer
would have a valid case.

I'm thinking in terms of American law; I'm not sure if this would
be case in France. The complaint would still be valid, but I don't
know how easy it would be to file a lawsuit based upon it.

I don't think such case would have any luck. Jacob could just claim
it's a bug he wasn't aware of. Else everyone would be able to sue
any buggy software and get money.

Can't be a valid case. If it was, Microsoft would have gone broke
about 2 decades ago.

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

[jameskuyper]

CBFalconer wrote:
....

This discussion started a few days ago when I mentioned that I
didn't think that provision would make it into the next C standard
(so far it only exists in a discussion draft) because it would
force too many inefficiencies. I have been defending that opinion
since then. Successfully, IMO.

I don't think so. As far as I can tell, nobody has even conceded the
existence of those inefficiencies, much less agreed that they are
problematic.

What's so inefficient about storing a copy of a struct in a
temporarily reserved piece of memory? That's often what happens anyway
when a function returns a struct type, for completely unrelated
reasons. The only ineffiiciency you've been able to identify applies
only to return values small enough to fit in a single register; a case
highly unlikely to be relevant to most structs or unions containing
arrays. I suppose a struct value containing an array of 8 chars might
be stored in a 64 bit register, but it's not the most obvious
implementation. The change planned for the next release of the C
standard has an impact only lvalue arrays, which can only occur inside
of structs and unions.

[lawrence.jones]

jacob navia <ja***@nospam.comwrote:

la************@siemens.com wrote:

No, it doesn't. It *mostly* conforms, if you like, but until you
implement *all* of the requirements, not just the "important" ones, it
does not (fully) conform.

I do not care about your opinion.

It's not my opinion -- the standard contains a list of requirements for
a conforming implementation; if lcc-win does not meet all of those
requirements (which it doesn't), then it's not conforming.

Ditto. If you use C99 constructs in your code it will accept
them. Pedants notwithstanding.

Conversely, if you use C89 constructs that look like C99 constructs, it
will either misinterpret them or reject them. The chance of such
constructs occurring "by accident" is small, but not zero.

Your compiler is an impressive and useful piece of work. As far as I
can tell, nobody hates it or you, we just don't want you confusing
people by misrepresenting it. Call it nearly conforming or say that
it's intended to be fully conforming but isn't quite there yet and no
one will argue with you. Just don't call it fully conforming when it's
not.
--
Larry Jones

I don't see why some people even HAVE cars. -- Calvin

[Keith Thompson]

la************@siemens.com writes:
[...]

Your compiler is an impressive and useful piece of work. As far as I
can tell, nobody hates it or you, we just don't want you confusing
people by misrepresenting it. Call it nearly conforming or say that
it's intended to be fully conforming but isn't quite there yet and no
one will argue with you. Just don't call it fully conforming when it's
not.

jacob, the above is an excellent summary of what I (and several
others) have been trying to tell you for a very long time.

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

Keith Thompson wrote:

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

>Nate Eldredge wrote:

>>>

... snip ...

>>>
You are correct in that it needs to allocate this space even if
the return value is going to be ignored. But again, this is
already the case. As I understand it, the only difference
between the current state of affairs and what's proposed for C1x
is how long the compiler has to keep the return value intact
before it can write over it.

Are you proposing to do away entirely with the ability to return
structs from C functions? Given the problems that arise, one
might argue that adding them to C was ill-considered, but I think
it's too late to take them back now.

Don't think about the complex returned values. They already need
special handling (after all, they were even forbidden to be
returned in early C). Consider the return value from, say,
strlen. This is of type size_t, which will be some form of
integer. It is normally returned in a register, and is a value.
What if you write:

&strlen(thing);

in your code somewhere. What are you taking the address of? Why?
Why did you want to force saving all such returns in a memory
location (and possibly letting the optimizer take them all out
again)? If you really want this you can write:

thinglen = strlen(thing);
use(&thinglen);

Here's what n1336 6.2.4p7 says (I think it's already been quoted in
this thread):

Yes, it has. And it has also been pointed out that n1336 is a very
preliminary draft for a future C1x standard. My comments have been
to the effect that I don't think this particular proposal will
live, and why not.

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

[CBFalconer]

Flash Gordon wrote:

jacob navia wrote, On 08/10/08 21:11:

.... snip ...

>

>It has several enhancements and innovations that make
this people scream like mad dogs:
o Operator overloading
o generic functions
o default arguments

No, they complain about you discussing those extensions here.

>The prototype figure for them is CB Falconer.

Hmm. In this very thread it has been pointed out that Chuck was
wrong in his claim that it was a bug in your compiler. People
have even posted that what your compiler does in this instance
makes sense.

I don't think I ever claimed that that was a bug. I am not going
over the thread to check. However I did point out that failure to
point out the occurence of undefined behaviour was NOT a bug.

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

[CBFalconer]

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

CBFalconer wrote:
...

>This discussion started a few days ago when I mentioned that I
didn't think that provision would make it into the next C standard
(so far it only exists in a discussion draft) because it would
force too many inefficiencies. I have been defending that opinion
since then. Successfully, IMO.

I don't think so. As far as I can tell, nobody has even conceded the
existence of those inefficiencies, much less agreed that they are
problematic.

What's so inefficient about storing a copy of a struct in a
temporarily reserved piece of memory? That's often what happens anyway
when a function returns a struct type, for completely unrelated
reasons. The only ineffiiciency you've been able to identify applies
only to return values small enough to fit in a single register; a case
highly unlikely to be relevant to most structs or unions containing
arrays. I suppose a struct value containing an array of 8 chars might
be stored in a 64 bit register, but it's not the most obvious
implementation. The change planned for the next release of the C
standard has an impact only lvalue arrays, which can only occur inside
of structs and unions.

But that provision would force the storage of all those small
values. That is where the inefficiency comes in. Also consider
the interactions.

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

[CBFalconer]

jacob navia wrote:

CBFalconer wrote:

>I doubt it will always work. For example:

typedef struct foo {char a[20]}; foo;
char ca, cb;
foo getfoo(void);
...
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);

Think about why I picked this test.

When I correct your code and write this:

typedef struct foo {char a[20];} foo;
char ca, cb;
foo getfoo(void) { foo f; f.a[0] = 'a'; f.a[1] = 0; return f; }
int main(void) {
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);
}

I obtain
' ' "a" ' '

Why?

Because lcc-win (as lcc) creates always a temporary object
when a function returns a structure. lcc-win passes a hidden
first argument to the function that contains a pointer to the
temporary variable created in the calling function.

Maybe in your system you can handle it for structures. But what if
you wanted the address of one of those characters? i.e.:

printf("%p \%s\" %p\n", (void*)&ca, &(getfoo().a),
(void*)&cb);

That n1336 proposal would require that to work. Ugh.

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

[Richard Heathfield]

DiAvOl said:

On Oct 8, 11:07 pm, [e-mail] wrote:

>On Oct 8, 10:45 pm, DiAvOl <[e-mail]:

I think that the last 20-30 posts (or more) has nothing to do with the
subject of this thread, maybe creating a new subject for lcc-win32 and
post there would be a better idea

Just a thought

Actually that's just how usenet works, it's not a web forum.
Many of the interesting discussions here in comp.lang.c don't have
anything to do with the subject line, or the OP question.

so you find this discussion interesting? what exactly is interesting
about it?

The great thing about threaded discussions is that you can easily ignore
the aspects of the discussion that you find uninteresting by simply not
reading that subthread.

I am relatively new here and all I see is some people shooting another
(jacob navia in this case)

Nobody is shooting jacob navia (although he likes to pretend that he gets
shot a lot). He has claimed (in this thread) to have a conforming C99
implementation and a conforming C89 implementation. He said: "My compiler
conforms to C99. It will compile C89 code without any problems and nit
conforms fully to the C89 standard also." - you can find this text in
message ID <gc**********@aioe.org>. But in the very next sentence, he
acknowledges that his compiler is not C89-conforming, and in a later
message <gc**********@aioe.orghe acknowledges that it isn't
C99-conforming either.

Nobody is under any obligation to produce C implementations. The fact that
jacob navia has not done so is not a reason to criticise him. What he
*has* produced, which is in any case very nearly a C implementation, is no
doubt useful to those people who use it (or they wouldn't use it, right?).

But false claims of conformance can mislead the unwary, and should be
debunked.

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

[Richard Heathfield]

CBFalconer said:

Flash Gordon wrote:

>jacob navia wrote, On 08/10/08 21:11:

... snip ...

>>

>>It has several enhancements and innovations that make
this people scream like mad dogs:
o Operator overloading
o generic functions
o default arguments

No, they complain about you discussing those extensions here.

>>The prototype figure for them is CB Falconer.

Hmm. In this very thread it has been pointed out that Chuck was
wrong in his claim that it was a bug in your compiler. People
have even posted that what your compiler does in this instance
makes sense.

I don't think I ever claimed that that was a bug.

"Your alleged 'good' experience with lcc shows a bug in lcc. I
don't know if you mean lcc-win32 (which has quite a few known
insects) or lcc (which is less well known here)." - message ID
<48***************@yahoo.com>

I am not going over the thread to check.

If only you would check more often.

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

[Keith Thompson]

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

Keith Thompson wrote:

[...]

>Here's what n1336 6.2.4p7 says (I think it's already been quoted in
this thread):

Yes, it has. And it has also been pointed out that n1336 is a very
preliminary draft for a future C1x standard. My comments have been
to the effect that I don't think this particular proposal will
live, and why not.

And the point of my reply was to refute your arguments. You're
claiming that the proposal "will involve too many ugly
inefficiencies". You snipped the paragraph in which I explained why
this is not the case:

| The proposed change in n1336 applies *only* to a structure or union
| that contains (directly or indirectly) an array member. In the
| majority of such cases, the struct or union is already too big to fit
| in a register. For any other function results, the returned value is
| not stored in an object, either implicitly or explicitly (though of
| course the compiler is still free to do the equivalent of storing it
| in an object internally).
|
| "&strlen(thing)" is still a constraint violation.

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

[Keith Thompson]

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

jacob navia wrote:

>CBFalconer wrote:

>>I doubt it will always work. For example:

typedef struct foo {char a[20]}; foo;
char ca, cb;
foo getfoo(void);
...
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);

Think about why I picked this test.

When I correct your code and write this:

typedef struct foo {char a[20];} foo;
char ca, cb;
foo getfoo(void) { foo f; f.a[0] = 'a'; f.a[1] = 0; return f; }
int main(void) {
printf("'%c' \"%s\" '%c'\n", ca, &(getfoo().a), cb);
}

I obtain
' ' "a" ' '

Why?

Because lcc-win (as lcc) creates always a temporary object
when a function returns a structure. lcc-win passes a hidden
first argument to the function that contains a pointer to the
temporary variable created in the calling function.

Maybe in your system you can handle it for structures. But what if
you wanted the address of one of those characters? i.e.:

printf("%p \%s\" %p\n", (void*)&ca, &(getfoo().a),
(void*)&cb);

That n1336 proposal would require that to work. Ugh.

I don't see the problem. The n1336 proposal simply requires the
creation of a temporary object of type foo, which must survive at
least until the end of the statement. In many implementations,
apparently including lcc-win, that temporary object is already created
as part of the protocol for returning a structure value.

BTW, &(getfoo().a) is the address of the array, not the address of one
of the characters. And that address would become meaningless after
the printf finishes.

Please see my other recent followup in this thread. If I've missed
something, please explain it to me.

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

[Martien Verbruggen]

On Wed, 08 Oct 2008 22:04:31 -0400,
CBFalconer <cb********@yahoo.comwrote:

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

>CBFalconer wrote:
...

>>This discussion started a few days ago when I mentioned that I
didn't think that provision would make it into the next C standard
(so far it only exists in a discussion draft) because it would
force too many inefficiencies. I have been defending that opinion
since then. Successfully, IMO.

I don't think so. As far as I can tell, nobody has even conceded the
existence of those inefficiencies, much less agreed that they are
problematic.

What's so inefficient about storing a copy of a struct in a
temporarily reserved piece of memory? That's often what happens anyway
when a function returns a struct type, for completely unrelated
reasons. The only ineffiiciency you've been able to identify applies
only to return values small enough to fit in a single register; a case
highly unlikely to be relevant to most structs or unions containing
arrays. I suppose a struct value containing an array of 8 chars might
be stored in a 64 bit register, but it's not the most obvious
implementation. The change planned for the next release of the C
standard has an impact only lvalue arrays, which can only occur inside
of structs and unions.

But that provision would force the storage of all those small
values. That is where the inefficiency comes in. Also consider
the interactions.

The storage of which small values? Which interactions? Could you be a
bit more verbose and maybe try to explain what you mean?

Martien
--
|
Martien Verbruggen | If at first you don't succeed, try again.
| Then quit; there's no use being a damn fool
| about it.