Funny bugs in some C compilers

PAD Powell[Admin] padpowell at wateng.UUCP
Wed Aug 31 02:09:11 AEST 1983


I hit a really odd bug the other day, and just thought I would pass it along
to the C compiler community.  Suppose that I have a structure,
with fields of various widths, and my machine architecture demands that
I have addresses on various alingments.  For the sake of argument,
char is any alignment, short is mod 2 (2 chars), int is mod 4, and float is
mod 16.  The structure I defined was:
struct test {
	char c; short s; int i; float f; }
I pass a struct value to a subroutine (I mean function), and also have a local
variable.
test_funct( s ) struct test s;
	{ struct test t; /* bunch of assignments */ return( s == t) }
Now in the "bunch of assignments, I set the various fields of t to the same
values as the fields of s.  According to various persons, in the extended
version of C, passing a structure by "value" is permitted.  Also, comparison
and assignment of structures is permitted.  However,  this code fails with
several compilers, for the funny reason that the comparison fails.  When the
"t" variable is allocated on the stack, the "cracks" or unused space in the
structure are set to garbage.  The code usually generated for comparison will
compare the entire structure in the most effective manner, usually using a block
comparison instruction.  This is one of the most annoying of all types of
language "flakes",  which has been called by various people the "semantic
gap",  or the problems of mapping a language to a machine architecture.

I suppose that there is a way of fixing this.
1.  Extend the definition of the language so that all local variables are
	initialized to 0.
	Pro: it solves the problem.
	Con: THE OVERHEAD!!!!  Function calls are bad enough, and now you
	want to make them worse?
2.  Extend the definition so that all "cracks" in structures are set to 0.
	Pro: it solves the problem.
	Con: overhead is still substantial.  Reduces the cost, but is still
	pretty bad.
3.  Write a big BOLDFACED, BOXED, and perhaps dayglow orange warning in
	the language definition manual, and indicate that keeping around
	a static or global variable, set to all 0's, and assignment of it
	to a structure variable will guarantee that the "cracks" are
	filled with 0's.
	Pro: it probably will solve the problem.
	Con: Manuals are never read.  The problem still exists, and people
	will still hit it.  This will lead to net.lang.c getting flames about
	once every 6 months from the next group of people to hit this...
	Also, assignment of structure to structure must be defined so that
	the crack filling is guaranteed to work.

Patrick Powell, U. Waterloo, Waterloo, Ont.
...watmath!wateng!padpowell



More information about the Comp.lang.c mailing list