Newsgroups: | comp.arch,comp.compilers |
From: | tim@franck.Princeton.EDU (Tim Hollebeek) |
Keywords: | C, architecture, comment |
Organization: | Princeton University |
References: | <4074ig$nh7@masala.cc.uh.edu> 95-08-182 |
Date: | Fri, 25 Aug 1995 07:01:50 GMT |
>doconnor@sedona.intel.com (Dennis O'Connor -FT-~) wrote:
>
>> So, how about it, GNU and ANSI ? Let's see __BIGEND__
>> and __LITTLEEND__ incorporated into the standards.
>> Thanks.
Bernd Paysan <paysan@informatik.tu-muenchen.de> wrote:
>I would support your request. Especially I found out that it is quite a
>problem not having anything that you can rely on. E.g. when we (that's
>Anton Ertl and me) started writing gforth, we used a macro BIGENDIAN
>that was only defined, when the machine was b.e.. No we compiled under
>Linux, and (surprise!) the program didn't work correct. Why? Linux'
>include files define BIGENDIAN 0 when the machine is l.e., and BIGENDIAN 1
>if it is b.e. :-(. Now we use WORDS_BIGENDIAN (that's what autoconf uses)
>and hope, that this is unique...
First, isn't what you really want
_NO_NON_STANDARD_DEFINES_VISIBLE_OUTSIDE_STANDARD_INCLUDES ?
Assuming that's not a problem, it's trivial to write a program to
determine endian-ness and generate a configure.h, or use autoconf.
Secondly, htonl() et al haven't been mentioned yet, along with
XDR, which give you three ways (including shifts) of ignoring the problem.
It seems that if you start specifying endianness, there are alot of
other things that one would want as well, and pretty soon we're not
much better off (unless, of course, you suggest that compilers should
supply everything that autoconf does ...)
--
Tim Hollebeek
PChem Grad Student
Princeton University
[We all know that you can test for endian-ness at runtime. The question is
whether you can or should test at compile0time. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.