Bruce Lilly wrote:
On Tue, Nov 11, 2014 at 7:21 AM, Andrew Gabriel <
illu...@cucumber.demon.co.uk> wrote
We currently support 32 bit and 64 bit kernel. A bug fix needs to work on
both 32 and 64 bit versions, so that would not be acceptable as a bug fix
for this issue (if it was something you were trying to fix in the distro).
There isn't anything specific in the program in question that would
definitively qualify as a "bug".
The program operates correctly e.g. even when compiled as a 32-bit
application on NetBSD:
# file grap
grap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically
linked (uses shared libs), for NetBSD 6.1.5, not stripped
# ./grap -d grap.defines test.grap | grep aligned
line invis "2038-01-20T23:59:59" aligned from Frame.Bottom.end + (0, -0.4)
to Frame.Bottom.start + (0, -0.4)
There are two parts of the problem, neither of which is specific to
application code:
1. 32-bit time_t provided by Solaris-derived kernel, run-time, and build
system is inadequate (well-known, long-standing issue)
2. default build on Solaris-derived 64-bit systems is 32-bits. Even though
the 64-bit version works as expected on OI, it isn't built as 64-bit
without special effort; i.e. by default anything using time_t is broken,
even on 64-bit OI.
Other OSes (e.g. NetBSD as shown above) have solved issue #1.
If issue #1 is solved on illumos, issue #2 becomes strictly a performance
tweak.
If there's a "bug" involved here, it is issue #1.
Issue #2 means that without special Solaris-specific effort, applications
using time_t or any library functions that directly or indirectly use
time_t may exhibit anomalous behavior when built for Solaris or illumos,
even on 64-bit systems.
Applications which need to handle dates outside of the operating system
time (such as dates of births, deaths, marriages, retirements, etc)
shouldn't be using time_t -- that's very well established.
You have an alternative?
Note that every standard time-based function eventually involves time_t.
That includes strftime() and strptime() as in the example, time(),
clock_gettime(), all of the ctime functions (localtime(), gmtime(), etc.) ,
mktime(), difftime(), and so on.
These are all for handling times related to the operating system -
time_t is not for handling arbitrary dates/times.
No banking/finance, spreadsheet, statistical or other application
handling general dates goes anywhere near these functions. It's a bug in
grap if it does. I just checked the AT&T grap, and it doesn't (although
I'm not sure if it has any support for dates).
Generally, 32 bit apps which are simply rebuilt as 64 bit (without being
modified to explicitly make use of larger address space) run faster on x86
because of the extra registers available for compiler optimisation, and run
slower on sparc because of the larger working set size.
That sounds like a good reason (in addition to the time_t correctness
issue) for making 64-bit builds the default, at least on 64-bit x86.
The Solaris philosphy is that the default build is to build something
that works on all supported x86 platforms.
If you want to build for specific architectures, instruction set
features, or even for the very specific features of processor you are
currently running on, those options exist, but selecting them
unwittingly gets people into trouble when they build a binary and then
find it won't work on some other system. If you then start building
multiple binaries, the testing complexity multiplies considerably. The
performance difference is almost always never worth the effort. There
are some other reasons which make the effort necessary, such as a
debugger needing to be 64 bit to debug a 64 bit process, or a large
application which can make good use of more than 4GB address space.
If openindiana drops support for 32bit kernel at some point, then it
might make sense.
--
Andrew
_______________________________________________
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
