eppstein@garfield.columbia.edu (David Eppstein) (10/17/86)
Is there a good reason why CC expands sizeof itself? E.g. in
test.c: test..c:
struct x { struct x { /* sizeof = 8 */
int a; int _x_a ;
float b; float _x_b ;
}; } ;
int foo(struct x y) int foo (_auto_y )struct x _auto_y ;
{ {
return y.a + sizeof(y); return (_auto_y . _x_a + 8);
} }
why does the sizeof(y) become 8 and not sizeof(struct x)?
Is there some other use CC makes of the size that makes up for the
resulting lack of portability?
--
David Eppstein, eppstein@cs.columbia.edu, seismo!columbia!cs!eppsteintk@moss.ATT.COM (10/20/86)
In article <3522@columbia.UUCP> eppstein@garfield.columbia.edu (David Eppstein) writes: >Is there a good reason why CC expands sizeof itself? E.g. in > ... >why does the sizeof(y) become 8 and not sizeof(struct x)? >Is there some other use CC makes of the size that makes up for the >resulting lack of portability? What lack of portability? If you're counting on the C++ translator to produce "portable C" as its output I think you'll have problems since cfront uses machine dependent size and alignment information.
bs@alice.UucP (Bjarne Stroustrup) (10/24/86)
> Subject: C++ and sizeof > David Eppstein @ Columbia University CS Department > > Is there a good reason why CC expands sizeof itself? E.g. in > > test.c: test..c: > struct x { struct x { /* sizeof = 8 */ > int a; int _x_a ; > float b; float _x_b ; > }; } ; > > int foo(struct x y) int foo (_auto_y )struct x _auto_y ; > { { > return y.a + sizeof(y); return (_auto_y . _x_a + 8); > } } > > why does the sizeof(y) become 8 and not sizeof(struct x)? > Is there some other use CC makes of the size that makes up for the > resulting lack of portability? The intermediate C generated by cfront is intented to be about as portable as assembler. In general cfront cannot do better than that since in some cases evaluation of sizeofs are necessary for typechecking extern v[4]; extern v[sizeof(int)]; // legal iff sizeof(int)==4 In other cases necessary to generate C from C++ constructs: const isz = sizeof(int); const lsz = sizeof(long); ... switch (i) { case 1: ... case isz: ... case lsz: ... } That said, it is also clear that cfront might generate sizeofs in many cases thus increasing the range of constructs for which the intermediate C is portable. Please remember that sizeof is not the only or even the major source of non-portability of the intermediate C. The nastiest problem is that cfront must expand macros to generate the intermediate C . Macros defined in header files are traditional repositories of machine dependencies. Noteworthy examples can be found in stdio.h, ctype.h, signal.h and stdargs.h (varargs.h).
franka@mmintl.UUCP (Frank Adams) (10/24/86)
In article <1772@clyde.ATT.COM> tk@moss.UUCP (Thomas Kirk) writes: >In article <3522@columbia.UUCP> eppstein@garfield.columbia.edu (David Eppstein) writes: >>Is there a good reason why CC expands sizeof itself? E.g. in >> ... >>why does the sizeof(y) become 8 and not sizeof(struct x)? >>Is there some other use CC makes of the size that makes up for the >>resulting lack of portability? > >What lack of portability? If you're counting on the C++ translator to produce >"portable C" as its output I think you'll have problems since cfront uses >machine dependent size and alignment information. This fails to answer the question. *What* does cfront use machine dependant size and alignment information for? Off hand, I can't think of anything it does for which this information is necessary, although it is a simplification to be able to carry around numbers instead of expressions for sizes. Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
eppstein@garfield.columbia.edu (David Eppstein) (10/25/86)
Something I guess I didn't make clear in my original posting was that I was more interested in the effect of expanding sizeof on the portability of the C++ translator itself. I.e. it has to know enough about the machine to calculate sizeof in the first place. A compiler I worked on forces individual chars and the starts of char arrays to be word-aligned; this may not be a totally bizarre requirement but it might not have been anticipated, and surely there is worse out there. I didn't find the examples for why sizeof must be expanded particularly convincing; while CC has to calculate the sizes in those cases if is to accept and translate them, I am not sure that it should accept them in the first place. (To recap one was an array bound declared in one place as an explicit constant and in another as a size; the other was using sizes as case labels.) -- David Eppstein, eppstein@cs.columbia.edu, seismo!columbia!cs!eppstein