Ove Kaaven wrote: > It looks like there are some portability issues in the current > code...
On three platforms which don't have the CPU power (or GPU support!) to actually, y'know, run the software. :) > Steve Langasek wrote: > > So this assumes the kernel will never expose more than 48bits of > > address space to userspace processes -- a short-sighted and > > groundless assumption, the reason Linux hasn't "documented this > > rigorously" is because there is no such guarantee. The NASAL_NAN64 > > option should be thrown out for all Linux variants. This is in the Nasal interpreter. Language interpreters routinely enjoy making some platform assumptions in the name of performance. In this case, that union trick chops the size of a naRef (and therefore the memory footprint of almost everything Nasal does) in half. I'm more than prepared to pay for this benefit in the form of the occasional dispeptic rant from uninformed distribution folks who are more interested in wagging their fingers at developers than they are in actually running the software [How's that for tone, Steve? I can flame with the best of them if you really want to throw down. Try a little less presumption next time.] As explained very clearly in the comments, all known platforms support this code just fine, and the benefits are very large. And I'm even conservative about refusing to compile on platforms on which I can't test, thus the #error (it's a feature, not a bug!). I'm happy to take patches, though. This support is trivially really easy to add, if Mr. Langasek is actually willing to help out a little. Just the output of "echo | gcc -dM -E -" on each of the platforms is sufficient. > > ... which is a cop-out, and a serious regression because the old code built > > and ran fine on all architectures. On all *debian* architectures. I had a ton of trouble getting the original stuff to work for everyone who wanted to use it. Manually enumerating architectures was the overwhelmingly simpler choice. I'm sorry you disagree. Andy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
