James Carlson wrote:
> As for the extended FILE bits, I think that if they don't want to port
> to Solaris, then that's entirely their right. The clear alternative
> would be for someone in OpenSolaris-land to fork the GNU coreutil
> source in order to provide the desired port. That's how the w
On 6/2/08, James Carlson wrote:
> I. Szczesniak writes:
> > On 6/2/08, James Carlson wrote:
>
> > > It's also lifted if you call enable_extended_FILE_stdio(3C), use the
> > > extendedFILE.so.1 preload, or 'F' is used as the last character in the
> > > fopen(3C) mode string.
> >
> > FYI, en
I. Szczesniak writes:
> On 6/2/08, James Carlson wrote:
> > If there's a problem here, and it's not just broken code in the
> > application, then filing bugs would help. I searched for, but did not
> > find, any references to this problem either at any external site or in
> > the bug database
Richard L. Hamilton wrote:
>> - Stack would be non-executable by default
> An advantage, certainly, although if someone is paranoid (and has no
> self-modifying code that would choke on it), this can be done for 32-bit with
> an /etc/system setting.
The ON consolidation, and some others, already e
James Carlson wrote:
> > FYI, enable_extended_FILE_stdio(3C) is incompatible to many
> > applications, including coreutil. Using a FD > 256 crashes such
> > applications.
>
> "Coreutil"? As in GNU coreutils?
>
> If there's a problem here, and it's not just broken code in the
> application, then
"I. Szczesniak" wrote:
> > It's also lifted if you call enable_extended_FILE_stdio(3C), use the
> > extendedFILE.so.1 preload, or 'F' is used as the last character in the
> > fopen(3C) mode string.
>
> FYI, enable_extended_FILE_stdio(3C) is incompatible to many
> applications, including coreuti
> > I can think of three main categories of capacity
> limits on 32-bit that might
> > be higher on 64-bit:
> > * file size max of 2GB
> > * register size and usage
> > * available address space, and therefore amount
> that can be mmap()'d at once
> > (Also, IIRC stdio is supposed to handle > 256 f
John Plocher wrote:
[snip]
> [I'm attaching Richard's original mail since it was only sent to
> opensolaris-arc and probably didn't get into the case mail log]
>
> Richard L. Hamilton wrote:
> > I can think of three main categories of capacity limits on 32-bit that might
> > be higher on 64-bit:
>
Alan Coopersmith wrote:
> Richard L. Hamilton wrote:
> >> I can think of three main categories of capacity limits on 32-bit that
> >> might
> >> be higher on 64-bit:
> >> * file size max of 2GB
> >> * register size and usage
> >> * available address space, and therefore amount that can be mmap()'
On 6/2/08, James Carlson wrote:
> Alan Coopersmith writes:
> > Richard L. Hamilton wrote:
> > >> I can think of three main categories of capacity limits on 32-bit that
> > >> might
> > >> be higher on 64-bit:
> > >> * file size max of 2GB
> > >> * register size and usage
> > >> * available
I. Szczesniak writes:
> On 6/2/08, James Carlson wrote:
> > It's also lifted if you call enable_extended_FILE_stdio(3C), use the
> > extendedFILE.so.1 preload, or 'F' is used as the last character in the
> > fopen(3C) mode string.
>
> FYI, enable_extended_FILE_stdio(3C) is incompatible to many
Alan Coopersmith writes:
> Richard L. Hamilton wrote:
> >> I can think of three main categories of capacity limits on 32-bit that
> >> might
> >> be higher on 64-bit:
> >> * file size max of 2GB
> >> * register size and usage
> >> * available address space, and therefore amount that can be mmap()'d
On Mon, Jun 02, 2008 at 11:46:02AM -0700, Alan Coopersmith wrote:
> Nicolas Williams wrote:
> > On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith wrote:
> (Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.)
> >> Yes, the 256 FILE stdio limit is lifted in 64-bit.
On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith wrote:
> Richard L. Hamilton wrote:
> >> I can think of three main categories of capacity limits on 32-bit that
> >> might
> >> be higher on 64-bit:
> >> * file size max of 2GB
> >> * register size and usage
> >> * available address space,
Nicolas Williams wrote:
> On Mon, Jun 02, 2008 at 11:24:02AM -0700, Alan Coopersmith wrote:
(Also, IIRC stdio is supposed to handle > 256 file pointers on 64-bit.)
>> Yes, the 256 FILE stdio limit is lifted in 64-bit. The other main
>
> Wait a minute. Our stdio does not support more than 2
Richard L. Hamilton wrote:
>> I can think of three main categories of capacity limits on 32-bit that
>> might
>> be higher on 64-bit:
>> * file size max of 2GB
>> * register size and usage
>> * available address space, and therefore amount that can be mmap()'d
>> at once
>> (Also, IIRC stdio is sup
[Arggh - I forgot to re-address this to PSARC-ext to make sure it ended
up in the case log... -John]
Original Message
Subject: Re: Switch SPARC GNU coreutils+bash from 32 to 64bit [PSARC/2008/351
Date: Mon, 02 Jun 2008 11:08:33 -0700
From: John Plocher
To: Richard L. Hamilton
17 matches
Mail list logo
