Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!princeton!allegra!alice!bs
From: bs@alice.UucP (Bjarne Stroustrup)
Newsgroups: net.lang.c++
Subject: C++ and sizeof
Message-ID: <6206@alice.uUCp>
Date: Fri, 24-Oct-86 10:57:47 EDT
Article-I.D.: alice.6206
Posted: Fri Oct 24 10:57:47 1986
Date-Received: Sat, 25-Oct-86 06:16:36 EDT
Organization: Bell Labs, Murray Hill
Lines: 50

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