-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 11/29/2006 11:03 AM:
> Eric Blake <[EMAIL PROTECTED]> writes:
>
>>> See http://tinyurl.com/yd5669 for details.
>> This message on the cygwin list has a good point,
>
> For first-fit memory allocators, perhaps; but these ar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Matthew Woehlke on 11/29/2006 4:48 PM:
>>> int
>>> open (const char* pathname, int flags)
>>
>> You need to remember the optional mode argument to open.
>
> I saw that in the manpage, but didn't get it. Last I checked C does not
> support
On 29 Nov 2006, Matthew Woehlke told this:
> (...which, aside from the infamous NSK/OSS you've all come to hate me
> for :-) reportedly includes OS/2. According to "The Linux Programmer's
> Manual" (i.e. 'man fchdir'), "The fchdir call is compatible with SVr4,
> 4.4BSD and X/OPEN". Note the conspic
Eric Blake wrote:
Matthew Woehlke writes:
A well-written fchdir module would be welcome. Such a module would have
no effect on coreutils proper, other gnulib modules, or any system with
fchdir support.
Ok, thanks... Anyway, here's a start:
[snip]
int
open (const char* pathname, int flags)
Y
Matthew Woehlke users.sourceforge.net> writes:
> > A well-written fchdir module would be welcome. Such a module would have
> > no effect on coreutils proper, other gnulib modules, or any system with
> > fchdir support.
>
> Ok, thanks... Anyway, here's a start:
>
> struct fd_heap_node {
>in
Jim Meyering wrote:
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
Jim Meyering wrote:
...
I did a survey, some time ago, of reasonable porting targets, and all
had fchdir. Eventually I should remove the test for fchdir, too.
So NSK/OSS has just been demoted to 'unreasonable'? Or can we go with
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
...
>> I did a survey, some time ago, of reasonable porting targets, and all
>> had fchdir. Eventually I should remove the test for fchdir, too.
>
> So NSK/OSS has just been demoted to 'unreasonable'? Or can we go with
> Bruno's sugg
Jim Meyering wrote:
Matthew Woehlke wrote:
(...which, aside from the infamous NSK/OSS you've all come to hate me
for :-) reportedly includes OS/2. According to "The Linux Programmer's
Manual" (i.e. 'man fchdir'), "The fchdir call is compatible with SVr4,
4.4BSD and X/OPEN". Note the conspicuous
Bruno Haible wrote:
Matthew Woehlke wrote:
I also noticed that although there is a HAVE_FCHDIR (properly set in
config.h), it is not being used.
How needed are the *at functions? Can I rip them out? Can I emulate
fchdir()? Is there some other way to achieve what fchdir() is being used
for?
Bruno Haible <[EMAIL PROTECTED]> writes:
>> Bruno, what is the reason for this change?
>
> It's to allow modules to augment noinst_LTLIBRARIES. (For example, if a
> package wants to be buildable with CC=g++ but needs the regex module, it
> needs to add "-x c" to the CPPFLAGS of this module. Automa
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> (...which, aside from the infamous NSK/OSS you've all come to hate me
> for :-) reportedly includes OS/2. According to "The Linux Programmer's
> Manual" (i.e. 'man fchdir'), "The fchdir call is compatible with SVr4,
> 4.4BSD and X/OPEN". Note the conspic
Matthew Woehlke wrote:
> I also noticed that although there is a HAVE_FCHDIR (properly set in
> config.h), it is not being used.
>
> How needed are the *at functions? Can I rip them out? Can I emulate
> fchdir()? Is there some other way to achieve what fchdir() is being used
> for?
Emulating f
(...which, aside from the infamous NSK/OSS you've all come to hate me
for :-) reportedly includes OS/2. According to "The Linux Programmer's
Manual" (i.e. 'man fchdir'), "The fchdir call is compatible with SVr4,
4.4BSD and X/OPEN". Note the conspicuous absence of "POSIX".)
I also noticed that
Eric Blake <[EMAIL PROTECTED]> writes:
>> See http://tinyurl.com/yd5669 for details.
>
> This message on the cygwin list has a good point,
For first-fit memory allocators, perhaps; but these are ancient
technology and I wouldn't worry about x2nrealloc on their account.
That being said, if you ca
Simon Josefsson wrote:
> With recent gnulib, I get this during autoreconf:
>
> gl/Makefile.am:24: noinst_LTLIBRARIES multiply defined in condition TRUE ...
> gl/Makefile.am:16: ... `noinst_LTLIBRARIES' previously defined here
>
> The Makefile.am reads:
>
> AUTOMAKE_OPTIONS = 1.5 gnits
>
> noins
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Robbie Gates on 11/29/2006 3:57 AM:
>> reduces asprintf's use of realloc from quadratic
>> to log-linear performance (ie. calling realloc every time you add a byte
>> is bad, compared to doubling the buffer size every time you call
>> real
Sylvain Beucler <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 28, 2006 at 11:32:55AM +0100, Jim Meyering wrote:
>> BTW, I've converted gnulib's (as of a day or two ago) CVS repo into a
>> git repository (with proper "User Name <[EMAIL PROTECTED]>" labels), so if
>> there's a way to put up a trial git re
With recent gnulib, I get this during autoreconf:
gl/Makefile.am:24: noinst_LTLIBRARIES multiply defined in condition TRUE ...
gl/Makefile.am:16: ... `noinst_LTLIBRARIES' previously defined here
The Makefile.am reads:
AUTOMAKE_OPTIONS = 1.5 gnits
noinst_LTLIBRARIES = libgnu.la
libgnu_la_SOURCE
The attached patch fixes poll to return POLLIN if an accept is possible.
A much better fix would have been to use SO_ACCEPTCONN, but due to a bug
in the kernel it is not possible to read this option from user mode.
Will apply if nobody complains in a couple of days.
Paolo
2006-11-29 Paolo Bo
19 matches
Mail list logo
