www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/07/23/01:13:25

Xref: news-dnh.mv.net comp.os.msdos.djgpp:1083
Newsgroups: comp.os.msdos.djgpp
Path: news-dnh.mv.net!mv!news.sprintlink.net!gatech!news.mathworks.com!news.kei.com!world!aml
From: aml AT world DOT std DOT com (Andrew M. Langmead)
Subject: Re: Byte Order
Organization: The World @ Software Tool & Die
References: <mictaliDC18sJ DOT F1u AT netcom DOT com>
Date: Thu, 20 Jul 1995 23:35:34 GMT
Lines: 25
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Dj-Gateway: from newsgroup comp.os.msdos.djgpp

mictali AT netcom DOT com (Jere McDevitt) writes:

>Simply put, I have a program that uses a structure with a LONG variable.  I
>set the variable to a value in a DJGPP compiled application and write the
>structure to a file.  When I read the same structure back in using a Dos
>application (16 bit ) compiled with Borlandc 3.1 (variable sizes match -
>used short not int) then the byte order of the LONG variable is reversed. 
>What was written out as 0x00000084 comes in as 0x84000000.  

This is probably not a problem with byte ordering but with structure
padding.  GCC, more than a lot of other compilers and padding bytes
between elements of a structure. It does this to make sure the access
to the members is always on a boundry that will allow the fastest
access. 

To test that this is the case, make a small program that declares one
of these structures and the prints the structure
(printf("%d\n",sizeof(struct theStruct))). I bet that the Borland and
GCC will print different numbers.

GCC does provide a __packed__ attribute that allows structure members
to be packed together if possible, and probably give youthe same
format that Borland would.
-- 
Andrew Langmead

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019