From: Adam M. <mi...@li...> - 2002-02-04 22:27:29
|
"Steve D. Perkins" <mai...@st...> writes: > > Adam has found that BYTE_ORDER is needed to determine endianess by > > autoconfigurization. Actually, two things have happened since I posted this: 1. The gcc people were kind enough to put in some gcc-specific autoconf hackery to handle mingw without BYTE_ORDER 2. The upcoming autoconf2.50 handles byte ordering without scanning headers (it builds a binary with static data and then inspects it). So the only reason left for you to consider introducing BYTE_ORDER/param.h is if you want mingw to be usable with autoconf2.13 when crosscompiling. Probably not a huge audience, and even those people can re-run autoconf2.50 on their configure.in's to make stuff work. > Ahh, now we are on the same page. I would say to push for compliance > with ANSI standards wherever they exist. That is... if there is as "ANSI > compliant" means for determining endianess, > we should push for the GCJ folks to incorporate the standard. Well, it's actually the autoconf folks. Right now, I (by myself) am "the gcj-on-mingw folks". =) Check out www.xwt.org if you want to see what it can do. AFAIK, param.h is actually a pre-POSIX UNIX. BYTE_ORDER is a BSD thing, possibly POSIX as well (not sure though). - a |