Simon Burge <simonb@netbsd.org> writes:
> Ok, back to my example of endian support - if we have something in
> nice portable ANSI C, does this alleviate the need for things like the
> endian-specific macros in <sys/endian.h> - or should they stay because
> they're a nice clean interface to do what we want to do?

They should stay, but they're irrelevant for code to be used on
cross-compile hosts (even if those happen to be NetBSD hosts 8-).

they provide a clean, potentially optimized, mechanism for
NetBSD-specific code to use.

code being used on cross-compile hosts should be clean in the sense of
being compliant with ANSI C, but shouldn't have a gigantic need for
speed/optimization.


> On a similar
> note, is it worthwhile or pointless to do something like:
> 
> 	#if (defined(__unix__) || defined(unix)) && !defined(USG)
> 	# include <sys/param.h>
> 	#endif
> 	#if defined(__NetBSD_Version__) && (__NetBSD_Version__ > something)
> 	# include <sys/endian.h>
> 	#else
> 	# define HTOBE64(foo) ....
> 	  ...
> 	#endif
> 
> in tools that are run on the compiling host?

I'd just punt and use a portable implementation.  who knows, maybe the
happy macro implementation is broken on a certain version of NetBSD?
(if standard C features are broken, well, what can you really assume?
8-)



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.