PE> I don't know.  Always code on the assumption that structures
PE> aren't aligned in a particular manner, and you will end up 
PE> with portable code.  BFN.  Paul.

AC> I'm not so sure.  This is the structure:

AC> typedef struct {                                                       
AC>     unsigned short  zone;       /* FTN zone number */                  
AC>     unsigned short  net;        /* FTN net number */                   
AC>     unsigned short  node;       /* FTN node number */                  
AC>     unsigned short  point;      /* FTN point number */                 
AC> }               EZYNETADDR;                                            
AC>                                                                        
AC> typedef struct {                                                       
AC>     unsigned short  prevreply;  /* Message to which this replies */    
AC>     unsigned short  nextreply;  /* Message which replies to this */    
AC>     unsigned long   text_ofs;   /* Physical offset of message text into
AC>                                  * MSGT???.BBS */                      
AC>     unsigned long   msg_len;    /* Message text length (including null 
AC>                                  * terminator) */                      
AC>     EZYNETADDR      orig;       /* Originating network address of this 
AC>                                  * message */                          
AC>     EZYNETADDR      dest;       /* Destination network address of this 
AC>                                  * message */                          
AC>     unsigned short  cost;       /* Cost of message in lowest unit of   
AC>                                  * originator's currency */            
AC>     unsigned char   msgattr;    /* EZYMSG_M_xxx */                     
AC>     unsigned char   netattr;    /* EZYMSG_N_xxx */                     
AC>     unsigned char   rsvd1;      /* reserved */                               

You see here that there are 3 characters?  The compiler may well pad
1 or 3 bytes to make the next long appear on a 4-byte boundary.

AC>     unsigned long   date_written;   /* Date that the message was written */  
AC>     unsigned long   date_received;  /* Date that the message was received 
AC> */ 
AC>     unsigned char   toname[36]; /* Name of user to whom this message is      
AC>                                  * addressed; counted string */              
AC>     unsigned char   fromname[36];   /* Name of user who created this 
AC> message;
AC>                                      * counted string */                     
AC>     unsigned char   subject[73];/* Message subject; counted string */        

It will probably pad on the end so that you can malloc multiple 
structures in one hit, and have the first field (a short) aligned
on a short boundary.  Actually it may well make sure it is aligned
on a 4-byte boundary, because there are longs in the structure too.

AC> I wrote a small program to report sizeof(EZYMSGHDR).  Borland C++ 3.1 
AC> reported the correct size, 186 bytes; Microsoft QuickC 2.5 reported 188 

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.  In 
fact, I bet you even are saying that the shorts are stored in a
particular format, ie little-endian.  So the way you do it is
define a structure, as above, and when you read it in you go
prevreply = buf[0] | (buf[1] << 8);

Guaranteed to work that way.  BTW, buf is unsigned char.  That way
your code will work on a machine where shorts are 64 bits, ints
are 64 bits, and longs are 64 bits, all of which are stored in
big-endian format.

AC> bytes, due to its default of 2-byte structure alignment.  Perhaps it has 
AC> something to do with EZYNETADDR being nested inside EZYMSGHDR.  I will 
AC> investigate when I have some more time, but in my opinion the behavior of 
AC> QuickC's default structure aligning is unacceptable, based on the above 
AC> structure.

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

---