[OpenIndiana-discuss] Bash bug issue

[Jim Klimov]

4 ноября 2014 г. 4:36:39 CET, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> пишет:
>On Mon, 3 Nov 2014, Bruce Lilly wrote:
>>
>> As of this late date, /usr/bin/bash here is in fact the bash
>executable,
>> not a link; but that means that it's 32-bit only and might well
>present
>> unexpected issues on 64-bit systems when dealing with large files
>etc.
>> (basically anything that involves pointers, long integers, time_t,
>> ptrdiff_t, clock_t, dev_t, off_t, size_t, or ssize_t in the sources).
>
>Such problems are highly unlikely.  Solaris supports large files (LFS) 
>in 32-bit applications and Autoconf-configured GNU programs use it by 
>default.  Few shell jobs require over 2GB of data, so ptrdiff_t is not 
>likely to be a problem, and size_t and ssize_t are unlikely to cause 
>problems either.  Perhaps time_t is still an issue.
>
>While it would be nice if Solaris software was all 64-bit, in actual 
>practice I notice no difference in day to day use between systems with 
>32-bit applications and 64-bit.  Only certain memory-hungry
>applications will significantly benefit.
>
>Regardless, the OpenIndiana project did produce an updated bash 
>binary.  I initially built my own, but switched to the OpenIndiana 
>version when it became available.
>
>Bob

Also note that 64-bit programs have a larger footprint in memory (bigger pointers). While people might dismiss it today (saying all our boxes are big anyway) - not all environments are big or get many benefits from such over-use of resources. You have laptops, vm's, local zones... even if the hardware box is a big powerhouse, why physically deny yourself an ability to run 70 mixed workloads instead of 50 64-bit ones (numbers made up arbitrarily)?

Another rationale I saw in a Sun blog back when Solaris 10 was new and young (relaying from memory, corruption might collect over the years), was that much of the application worker code sufficed to be 32-bit so why not remain such (benefits above). Most of the access to larger items can be done with the 64-bit OS facilities (via syscalls? ipc? weird omnivore linking? I don't remember exactly now...)
So most of the programs (thousands of binaries supplied with a sol10 distro and extension discs) remained 32-bit only. A minority of the lrograms that were deemed to really need this (under 700? or even 100?) were dual-built and provided with the isaexec hack to pick the right binary at run-time depending on the running kernel (32/64).

So... just in case, here were some old news from the attic ;)
You know where the grain and salt are ;)

//Jim
--
Typos courtesy of K-9 Mail on my Samsung Android