Chris G. Demetriou wrote:

> Simon Burge <simonb@netbsd.org> writes:
> > So how do we solve the problem of generating a file, in this particular
> > case of having 64 bit data of a specific endianness?
> 
> Actually, if you're going to push that line of questioning, it's
> worse: how can you get a 64-bit data type in a portable manner?  "you
> can't."
> 
> However, that doesn't mean that you can't do it.  It's a simple
> problem of converting data structures to disk.  it doesn't have to be
> fast, or anything.  People have been outputting data of a specific
> endianness, or specific file formats, for years, in portable manners,
> without using the latest, greatest NetBSD features...

This was the driving reason behind creating <sys/endian.h> - ever
since we converted to 64 bit off_t's, we've been using a 32-bit endian
function on a 64 bit quantity!

> Do you really want me to write the code here to show you how to
> portably output a 32-bit number in little-endian order or something,
> using no NetBSD special features?

No - I'd much rather use one macro do the work since it already exists
in NetBSD.  There's no need to polute our source tree with guff that we
don't need.  I'm happy to change fortune and monop so that they run on a
"run of the mill" system if cross-compiling is a realistic goal of the
project.  At the moment, the goals on the web pages[1] list "the ability
to recompile itself", not "the ability for anything to recompile it"...

Simon.

[1] http://www.NetBSD.ORG/Goals/system.html