C++ and sizeof

[David Eppstein]

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, epps...@cs.columbia.edu, seismo!columbia!cs!eppstein

[t...@moss.att.com]

In article <35...@columbia.UUCP> epps...@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.

[Bjarne Stroustrup]

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

[Frank Adams]

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

[David Eppstein]

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