ckk@g.cs.cmu.edu (Chris Koenigsberg) (06/10/86)
Keywords:not in MY K&R!!
tps@sdchem said the following program should be legal as it was from
"K&R p.206":
typedef float distance;
main()
{
auto int distance;
/*###8 [cc] unknown size%%%*/
/*###8 [cc] cannot recover from earlier errors: goodbye!%%%*/
/*###8 [cc] syntax error%%%*/
/*###8 [cc] warning: illegal combination of pointer and integer, op =%%%*/
distance = 1;
printf( "distance = %d\n", distance );
}keppel@pavepaws.berkeley.edu (David Keppel) (06/10/86)
In article <1003@g.cs.cmu.edu> ckk@g.cs.cmu.edu (Chris Koenigsberg) writes: >not in MY K&R!! > >tps@sdchem said the following program should be legal as it was from >"K&R p.206": >> typedef float distance; >> >> main() >> { >> >> auto int distance; >> >> /*###8 [cc] unknown size%%%*/ >> /*###8 [cc] cannot recover from earlier errors: goodbye!%%%*/ >> /*###8 [cc] syntax error%%%*/ >> /*###8 [cc] warning: illegal combination of pointer and integer, op =%%%*/ >> distance = 1; >> printf( "distance = %d\n", distance ); >> } Well here's what's in my K&R (1978) pg 206: KR KR Remember also (section 8.5) that identifiers associated with KR ordinary variables on the one hand and those associated with KR structure and union members and tags on the other form two disjoint KR classes which do not conflict. Members and tags follow the same KR scope rules as other identifiers. typedef [sic] names are in the KR same class as ordinary identifiers. They may be redeclared in inner KR blocks, but an explicit type must be given in the inner declaration: KR KR typedef float distance; KR ... KR { KR auto int distance; KR ... KR KR The int must be present in the second declaration, or it would be KR taken to be a declaration with no declarators and type KR distance[dagger]. KR KR ------- KR [dagger] It is agreed that the ice is thin here. :-D avid K eppel ..!ucbvax!pavepaws!keppel "Learning by Osmosis: Gospel in, Gospel out"
jsisi@trwrb.UUCP (Dan Jones) (06/11/86)
In article <1003@g.cs.cmu.edu> ckk@g.cs.cmu.edu (Chris Koenigsberg) writes: >Keywords:not in MY K&R!! This is in reference to the note by tps@sdchem about the code fragment found on page 206 of K & R. It is there in App. A of my volume (ISBN 0-13-110163-3, 1978), *BUT* it is flagged with a footnote which reads: "It is agreed that the ice is thin here." The footnote refers to the requirement of "auto int distance" rather than "auto distance" to avoid confusing the declaration syntax, but it is clear than the same scoping issue must have been in the back of someone's mind. And now for something completely different ... I tried the code here using the Green Hills C compiler and it handled the scoping issue 'correctly'. The pcc based UniSoft compiler muffed it exactly as reported by tps@sdchem. Thus, I would suggest being very careful since you never know what compiler your code may see next. Not only that, but it is just plain bad design to overload typedefs, depending on scoping to save the functionality of the code. [Couldn't resist my two cents worth.] Dan Jones ...!trwrb!jcc-one!djones Here is the code fragment for those who may have missed it: typedef float distance; main() { auto int distance; distance = 1; printf( "distance = %d\n", distance ); }
tps@sdchem.UUCP (Tom Stockfisch) (06/13/86)
>[redefinition of typedef as auto works on one machined but not another...]. >Thus, I would suggest being very careful since >you never know what compiler your code may see next. Not only that, but it >is just plain bad design to overload typedefs, depending on scoping to save >the functionality of the code. [Couldn't resist my two cents worth.] > > Dan Jones > ...!trwrb!jcc-one!djones Do you also think reusing an *extern* name in a local block is "plain bad design"? I can't see the difference. I agree you should avoid overloading names, but the idea behind the overloading classes is so you can confidently define local variables which are guaranteed to be independent of the rest of your project. Not having to worry about a typedef defined in some 'include' file improves modularity. -- Tom Stockfisch, UCSD Chemistry