> If you say that 186 is the correct size, then that is because you are 
> saying that there are 186 CHARACTERS in the structure, and you know 
> EXACTLY which character is which.  So read a block of 186 characters, 
> and CONVERT them into the local structure.

ac> Thanks Paul, this makes perfect sense.  The Tobruk source code to deal with 
ac> FTN packets is a good demonstration of this.

Yeah.  If you actually profile the code, and find that converting
from characters to local data types is *really* the bottleneck in
your program, then you can #ifdef around that and read directly
into a structure.  I normally make that sort of thing a non-default
#ifdef, as an example, see trav.c in Tobruk.  By default it compiles
to 100% ISO C (which means it only handles one file).

AC>> behavior of QuickC's default structure aligning is unacceptable, 
AC>> based on the above structure.

> No, your code is unacceptable to ISO/IEC 9899:1990.  BFN.  Paul.

ac> Heck, I must be in the wrong echo.  Are you sure this is AUST_C_HERE and 
ac> not AUST_ISO_C_HERE? :-)

ISO_C is the alternative echo.

ac> I suppose it comes under "Platform dependant code".  Does platform 

Ok, the term is that it is not "strictly conforming" because it
relies on "implementation-defined" features.

ac> dependancy make code unacceptable to the ISO C standard?  I should hope the 

No, it will compile fine.

ac> aim of the standard would be to simply point out that it is platform 
ac> dependant.  If it was unacceptable then the majority of ANSI/ISO C 
ac> compilers would probably refuse to compile it! :-)

Yes, that's correct.  That's the difference between "conforming"
and "strictly conforming" as far as I am aware.  BFN.  Paul.
@EOT:

---