lai@vedge.UUCP (David Lai) (01/28/89)
Here f() returns a structure.
I am trying to figure out why C compilers like the latter expression
and cant handle the first expression. From what I gather from the
ANSI specs, it says that a function call is not an lvalue (*). Therefore
the latter expression should be illegal (& requires an lvalue).
As far as I can tell the first expression is legal... the . operator
anly requires that the left hand side be a struct or union, it does not
have to be an lvalue.
So why is it that the C compilers (Sun and HP-UX's) both complain that
the expression f().c is illegal, but run fine on (&(f()))->c.
Seems to me that the logic is reversed here.
(*) I got that info from Harbinson and Steele. I have the May Draft of ANSI,
but cant find the page where it mentions that. Can anyone point me to
the appropriate ANSI section number?
--
"What is a DJ if he can't scratch?" - Uncle Jamms Army
The views expressed are those of the author, and not of Visual Edge, nor Usenet.
David Lai (vedge!lai@larry.mcrcim.mcgill.edu || ...watmath!onfcanim!vedge!lai)guy@auspex.UUCP (Guy Harris) (01/29/89)
>I am trying to figure out why C compilers like the latter expression >and cant handle the first expression. Because they're buggy. In particular, pre-S5 versions of PCC (upon which the Sun compiler is based) had some bogus code for determining whether something was a legal structure reference. The S5 version had a differently bogus version that attempted to fix the first version. The SunOS 4.0 compiler has one that avoids both of those forms of bogosity; however, it still doesn't catch some other illegal constructs. I think the 4.3-tahoe compiler has something to catch those as well. HP-UX may, at least on the 68K-based HPs, also have a PCC-derived compiler, and thus have inherited one or more of the aforementioned bugs. This is why "my compiler does/doesn't accept this construct" is not always a good test of whether the construct is legal or not. That's why you need a standard - and conformance tests, so that bugs such as the aforementioned get caught and, hopefully, fixed.
walter@hpclwjm.HP.COM (Walter Murray) (01/31/89)
> I got that info from Harbinson and Steele. I have the May Draft of ANSI, > but cant find the page where it mentions that. Can anyone point me to > the appropriate ANSI section number? > David Lai Section 3.3.3.2. Unary & requires an lvalue. Section 3.3.2.3. The . operator does not require an lvalue. If the left operand is an lvalue, the result is an lvalue. Especially, see section 3.3.2.3 of the Rationale. By the way, the HP-UX compiler for the Series 800, which is not derived from PCC, gets this right. Walter Murray HP, California Language Lab ----------
middleto@sdsu.UUCP (Tom Middleton) (02/02/89)
In article <2648@vedge.UUCP> lai@vedge.UUCP (David Lai) writes: >Here f() returns a structure. I may be missing the point here but it seems that one problem is f() does not return a structure but rather a pointer to a structure. I don't know how an entire structure can be returned by a function. This would imply that f()->c should be legal, but I don't know if that is what you meant to say in the first place. Seems to me that &(f()) is the address of the pointer returned by the function f and although (&(f()))-> is legal it isn't what you think it is. -- G O P A D R E S ! Thomas Earl Middleton 1989 aka Happy Bare N L C H A M P S ! UUCP ...!ucsd!sdsu!middleto W S C H A M P S ! ARPA middleto%sdsu.uucp@ucsd.edu
mike@hpfcdc.HP.COM (Mike McNelly) (02/03/89)
> Here f() returns a structure. > I am trying to figure out why C compilers like the latter expression > and cant handle the first expression. From what I gather from the > ANSI specs, it says that a function call is not an lvalue (*). Therefore > the latter expression should be illegal (& requires an lvalue). > As far as I can tell the first expression is legal... the . operator > anly requires that the left hand side be a struct or union, it does not > have to be an lvalue. > So why is it that the C compilers (Sun and HP-UX's) both complain that > the expression f().c is illegal, but run fine on (&(f()))->c. > Seems to me that the logic is reversed here. You're correct. We consider the behavior to be a bug, too. The problem of f().c has been fixed for release 6.5 on HP-UX Series 300 due to be released "real soon now". I have no information on the (&(f()))->c problem. Mike McNelly mike%hpfcla@hplabs.hp.com
throopw@xyzzy.UUCP (Wayne A. Throop) (02/09/89)
> middleto@sdsu.UUCP (Tom Middleton) >> Here f() returns a structure. > I may be missing the point here but it seems that one problem is f() > does not return a structure but rather a pointer to a structure. Yes, indeed, you ARE missing the point. In particular you seem to be confusing arrays and structures. In ansi C (which is what this newsgroup is mostly about) structures can be passed by value and returned as the result of a function. (In fact this has also been a common extension to most C language systems based on K&R C for some time.) > Seems to me that > &(f()) is the address of the pointer returned by the function f and > although (&(f()))-> is legal it isn't what you think it is. Of course, the address-of operator "&" can only be applied to things which "have addresses", and function results are not one of these. -- I think. I think I am. Therefore I am ... I think. --- Moody Blues -- Wayne Throop <the-known-world>!mcnc!rti!xyzzy!throopw
middleto@sdsu.UUCP (Tom Middleton) (02/10/89)
I'd like to thank the people who emailed a response to my comment about
returning a pointer rather than an entire structure. They correctly
guessed that I wasn't up to date. (My K&R is from the late seventies,
unfortunately I've been doing mostly FORTRAN since then.) The reason
I read this group is to catch up on the C language standards, I suspect
I may again in the future make an assumption based on old information.
I'm sure you people will update me. :-)
I'd also like to thank the people who emailed a response, rather than
posting, for emailing. They recognized that the misunderstanding I had
was not of global concern and therefore there was no reason to waste
bandwith by posting. Being able to discern between problems that a few
individuals may have versus something that really affects most people
is an important attribute when deciding whether to post or email a
response. I'm glad to see most people showed they had that ability.
Now, please, I respectfully request that you (emailers and posters) stop.
Enough is enough. Thank you.
--
G O P A D R E S ! Thomas Earl Middleton
1989 aka Happy Bare
N L C H A M P S ! UUCP ...!ucsd!sdsu!middleto
W S C H A M P S ! ARPA middleto%sdsu.uucp@ucsd.edu