🚀 go-pugleaf

Consider the following program:

----------------------------------
#include <stdio.h>

#pragma pack(1)
union foo {
	char d1;
	long d2;
};
#pragma pack()

struct bar {
	char a;
	char b;
	char c;
	union foo d;
};

main()
{
	struct bar x;

	/* display the relative offsets of struct bar members */
	printf("\t%d %d %d %d\n",
		(char *) &x.a - (char *) &x,
		(char *) &x.b - (char *) &x,
		(char *) &x.c - (char *) &x,
		(char *) &x.d - (char *) &x);
}
----------------------------------

Program output (Compiled with cc on 3.2v2 DS or or gcc 2.2.2):

	0 1 2 4

Program output (Compiled with cc 3.2v4 DS, or rcc on both 3.2v2 DS
and 3.2v4 DS):

	0 1 2 3

So, with cc on 3.2v4 or rcc in both versions, the compiler does not put
a pad byte after field "c" in struct bar, whereas with cc on
3.2v2 DS or gcc, it does.

What significance is there?  Well, for most applications writers
there isn't a problem, as long as all modules that use this structure
are compiled with the same compiler.  There will be a problem if you
are going to be mixing object files or libraries compiled with different
compilers.

For device driver writers, there is definitely a problem.  If there
is a kernel structure defined as such, and the kernel was compiled with
a different compiler than yours, then there is a serious bug.

Guess what, there is exactly such a case.  In /usr/include/sys/scsi.h,
on both SCO 3.2v2 and 3.2v4, there is a "scsi_io_req" structure which
contains a subfield "union scsi_cdb".  The starting offset of this
union varies depending upon which compiler you use.

It appears that the SCO 3.2v4 kernel is compiled with the 3.2v2
Dev Sys compiler, so if you compile a SCSI device driver using the
3.2v4 DS compiler, you're in for a nice surprise.

Of course there is a workaround, just by explicitly inserting a
pad byte into the structure before the scsi_cdb union will solve this
particular case.  But how many other similar situations are there?

I don't know if there is an ANSI standard or somesuch that dictates
the correct compiler behavior in this scenario, but SCO has definitely
introduced an incompatibility between the cc compiler between 3.2v2 DS
and 3.2v4 DS.

Just thought I'd make everyone aware of this... I found out the hard
way.

-Ti
-- 
    ///  Ti Kan                vorsprung durch technik
   ///   AMB Research Laboratories, Sunnyvale, CA. USA
  ///    ti@amb.org
 //////  ...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!ti
///      ...!{uunet,sun,apple,sco}!altos!bazooka!ti