[OpenIndiana-discuss] 32-bit and/or 64-bit programs (Was: Bash bug issue)

[Bruce Lilly]

On Tue, Nov 11, 2014 at 7:21 AM, Andrew Gabriel <
illumos at 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.


> 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.