Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!mit-eddie!genrad!decvax!watmath!rbutterworth
From: rbutterworth@watmath.UUCP (Ray Butterworth)
Newsgroups: comp.lang.c
Subject: Re: structure element offsets
Message-ID: <3695@watmath.UUCP>
Date: Mon, 1-Dec-86 11:26:45 EST
Article-I.D.: watmath.3695
Posted: Mon Dec  1 11:26:45 1986
Date-Received: Tue, 2-Dec-86 02:08:14 EST
References: <1096@spice.cs.cmu.edu> <768@nike.UUCP> <3622@watmath.UUCP> <386@viper.UUCP>
Organization: U of Waterloo, Ontario
Lines: 39
Keywords: structure, offset

In article <386@viper.UUCP>, dave@viper.UUCP (David Messer) writes:
> It could be because you used OFFSET(Str,f2) instead of the correct
> OFFSET(f2,Str).  You got the parameters reversed.
I must have quoted it wrong in the news article.  Sorry.
The other order seems to fit more naturally with the C language.

> A simpiler definition of the OFFSET macro is the following:
> 	#define OFFSET(mos)  ((long)(&(((char *)0)->mos)))
> This will produce a proper offset on almost all machines.  (But
> not all, some machines have different formats to pointers to
> different types.  Also, this macro assumes that (long)((char *)0) == 0L.)

"on almost all machines" means it is totally wrong on some machines.
What is the point of making something simpler if it's going to be
wrong?
How about "#define OFFSET(mos) 4"?  That's really simple and will
also be correct sometimes.
What is the point of bothering to assume that (long)(char*)0 is 0?
Why not simply subtract whatever (char*)0 really is from the other
pointer and always get the correct answer on all machines (as I
originally suggested)?

On any one machine, the simplest and most complicated forms of this
macro will generate exactly the same code (assuming both are correct).
What is it you think you are gaining by "simplifying" it?

Besides, what makes you think you can get away with ((char*)0)->mos?
Compilers which accept this (e.g. BSD) give this warning:
"xxx.c", line 15: warning: struct/union or struct/union pointer required
And if two structures should happen to have members with the same name:
"xxx.c", line 15: nonunique name demands struct/union or struct/union pointer

> I'm always right and I never lie. | Software Consultant 
> My company knows this and agrees  | UUCP:  ihnp4!quest!viper!dave 
> with everything I say.            |        ihnp4!meccts!viper!dave

With advice like that, I pity your clients.
If it is a company of more than one, I hope the owners know
what excellent advertising you are providing for them.