stevenw@oakhill.UUCP (Steven Weintraub) (11/29/90)
We recently received the following code in as a test case of our compiler.
---------------------------------------------------------------------------
char f_char() { return (char) 1; }
unsigned char f_uchar() { return (unsigned char) 1; }
short f_short() { return (short) 1; }
unsigned short f_ushort() { return (unsigned short) 1; }
int f_int() { return (int) 1; }
unsigned int f_uint() { return (unsigned int) 1; }
long f_long() { return (long) 1; }
unsigned long f_ulong() { return (unsigned long) 1; }
float f_float() { return (float) 1; }
double f_double() { return (double) 1; }
#define SIZER(type,func) size = sizeof(f_##func()); \
printf("%-6s ",#func); \
if (size == sizeof(type)) \
printf("good"); \
else \
printf("bug "); \
printf(" size = %d should be %d\n",size,sizeof(type));
main()
{
int size;
SIZER(char ,char);
SIZER(unsigned char ,uchar);
SIZER(short ,short);
SIZER(unsigned short,ushort);
SIZER(int ,int);
SIZER(unsigned int ,uint);
SIZER(long ,long);
SIZER(unsigned long ,ulong);
SIZER(float ,float);
SIZER(double ,double);
}
---------------------------------------------------------------------------
As can be seen is it prototypes several functions, and then takes the
sizeof the return value of that function (once one wades through the
define). The results we get are :
char bug size = 4 should be 1 <-------------
uchar bug size = 4 should be 1 <-------------
short bug size = 4 should be 2 <-------------
ushort bug size = 4 should be 2 <-------------
int good size = 4 should be 4
uint good size = 4 should be 4
long good size = 4 should be 4
ulong good size = 4 should be 4
float bug size = 8 should be 4 <-------------
double good size = 8 should be 8
As can be guessed, the compiler returns a promoted return value.
We have two camps on this issue. One camp here claims this behavior is
not incorrect, there is nothing in the standard which prevents this. The
other camp claims that the standard requires that a char function returns
a char, thus having sizeof(char).
This all breaks down to an argument of semantics in the standard. Even
parts some of us feel clearly point to the second explanation (like
3.3.3.4 in the rational), others claim does not constrain what is PASSED
back. To fix it one way or another is easy, we just want to know which
way to fix it.
enough from this mooncalf - Steven
----------------------------------------------------------------------------
Steven R Weintraub | O Lord,
...!cs.utexas.edu!oakhill!stevenw | let me talk gently,
Motorola Inc. Austin, Texas | for I might have to eat my
(512) 891-3023 (office) (512) 453-6953 (home) | words tomorrow.
----------------------------------------------------------------------------gwyn@smoke.brl.mil (Doug Gwyn) (11/29/90)
In article <4253@oakhill.UUCP> stevenw@oakhill.UUCP (Steven Weintraub) writes: >This all breaks down to an argument of semantics in the standard. This is an open issue that turned up during the closing moments of the last X3J11 meeting. I think the clear intent is that the return type of the function is narrow, with widening occurring only when used in an expression, but others may disagree. This needs an interpretation ruling.