Christopher Faylor wrote:
I have mixed feelings about alloca, personally. I use it all of the time but
it is always with some trepidation because, AFAIK, the failure condition for
alloca is a SEGV. OTOH, it is very convenient.
In this case, however, I think you really want to use realloc. Yo
On Sun, Nov 06, 2005 at 01:52:14PM -0500, Charles Wilson wrote:
>Christopher Faylor wrote:
>
>>A signal shouldn't cause a truncated read when retrieving data from
>>disk on cygwin or linux.
>
>ACK.
>
>>I think the only sane way to handle this is to put the read in a loop
>>and realloc the buffer as
Charles Wilson wrote:
> Revised patch attached. I'm wondering, tho, about the advisability of
> using alloca'ed (rather than malloc'ed) memory to hold the contents of a
> file of unrestricted size. Aren't there limits on the available space
> within a single stack frame? Does it make sense (is
It would help if I actually attached the patch.
Charles Wilson wrote:
Christopher Faylor wrote:
A signal shouldn't cause a truncated read when retrieving data from
disk on cygwin or linux.
ACK.
I think the only sane way to handle this is to put the read in a loop
and realloc the buffer as
Christopher Faylor wrote:
A signal shouldn't cause a truncated read when retrieving data from
disk on cygwin or linux.
ACK.
I think the only sane way to handle this is to put the read in a loop
and realloc the buffer as needed as long as the read continues to return
'>0'.
Ok.
It's obviou
On Sun, Nov 06, 2005 at 12:50:11AM -0500, Charles Wilson wrote:
>Gary R. Van Sickle wrote:
>>I'm not sure the test is actually valid anyway. IIRC (and I may not, POSIX
>>may prove me wrong here), there's no guarantee that read() will return the
>>number of bytes you requested, so at a minium to ma
The following seems to do the trick, at least on my (binmount) system
with dos-ified /var/lib/alternatives/* files.
I don't think I'm doing anything obviously stupid here, but see attached
patch. If it looks okay, I'll put out a 'testing' release of
alternatives shortly.
--
Chuck
diff -urN
Gary R. Van Sickle wrote:
I'm not sure the test is actually valid anyway. IIRC (and I may not, POSIX
may prove me wrong here), there's no guarantee that read() will return the
number of bytes you requested, so at a minium to make this 100% correct
you'd have to do something like this:
// Read e
> From: Charles Wilson
> Sent: Saturday, November 05, 2005 12:12 PM
> To: Mailing List: CygWin
> Subject: Re: BUG: alternatives
>
> Gary R. Van Sickle wrote:
> > More investigation reveals that it's textmode mounts that
> alternatives
> > doesn&#x
st is "be consistent with
solutions for other instances of this problem".
stephan();
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Charles Wilson
Sent: Saturday, November 05, 2005 10:12 AM
To: CygWin
Subject: Re: BUG: alternatives
Ga
Gary R. Van Sickle wrote:
More investigation reveals that it's textmode mounts that alternatives
doesn't like, not necessarily (although almost certainly as well as) \r\n
line endings.
I'm pretty sure the problem is here:
if (read(fd, buf, sb.st_size) != sb.st_size) {
close(fd);
More investigation reveals that it's textmode mounts that alternatives
doesn't like, not necessarily (although almost certainly as well as) \r\n
line endings.
--
Gary R. Van Sickle
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Gary R. Van Sick
Running d2u on /var/lib/alternatives/automake makes it work (at least
--config now gets me to the menu). It doesn't have an entry for
automake-1.9 though, which I do have installed. That may have been an
absorbed error on installation.
--
Gary R. Van Sickle
> -Original Message-
> Fro
13 matches
Mail list logo
