[EMAIL PROTECTED] (Karl Berry) wrote:
> since no one cares if gzip can't recursively compress or decompress a
> hierarchy that's really deep or that contains very long names.
>
> Really?
Hi Karl!
I figure if someone cared, it would have been fixed in the last 10 years ;-)
> Well, I guess
[EMAIL PROTECTED] (Karl Berry) writes:
> Well, whatever. Even if Paul wants to address this, I'm sure it's
> nothing to do for the first release.
Right you are. Right now I'm just trying to address security holes in
gzip, like buffer overruns (I just half an hour ago found another
hole, wow! I'
since no one cares if gzip can't recursively compress or decompress a
hierarchy that's really deep or that contains very long names.
Really?
Well, I guess the deepest things gzip would operate on is distributions
of some sort. That probably doesn't compare to the monstrous stuff you
ma
Eric Blake wrote:
> > What about the FD table; should it be a hash table, a binary tree, an
> > ordered linked list, or something else entirely?
>
> Gnulib already provides the gl_list module. The idea there is that you start
> by coding with an array list (probably a good choice anyways, since
Eric Blake <[EMAIL PROTECTED]> wrote:
> Jim Meyering meyering.net> writes:
>
>> Right.
>> I did a survey, some time ago, of reasonable porting targets, and all
>> had fchdir. Eventually I should remove the test for fchdir, too.
>
> FYI, mingw is another relatively-active porting target that lacks
Eric Blake <[EMAIL PROTECTED]> wrote:
> To my knowledge, gettext does not depend on fchdir (as evidenced by the fact
> that it builds on mingw). But coreutils, findutils, tar, and gzip all use
> gnulib directory traversal.
When I think of gnulib directory traversal, I think of its lib/fts.c.
I kn
Eric Blake wrote:
Matthew Woehlke writes:
That sounds like a good idea, but... does that mean I have to *write* an
entire unistd.h *and* make it work everywhere, or is there a way to
'drop in' one that pulls the system unistd.h, plus extras?
For an example of how to provide a replacement , se
Matthew Woehlke users.sourceforge.net> writes:
> That sounds like a good idea, but... does that mean I have to *write* an
> entire unistd.h *and* make it work everywhere, or is there a way to
> 'drop in' one that pulls the system unistd.h, plus extras?
For an example of how to provide a replac
Jim Meyering meyering.net> writes:
>
> Right.
> I did a survey, some time ago, of reasonable porting targets, and all
> had fchdir. Eventually I should remove the test for fchdir, too.
FYI, mingw is another relatively-active porting target that lacks fchdir, which
would benefit from a good fc
Eric Blake wrote:
According to Matthew Woehlke on 11/29/2006 4:48 PM:
The licensing issue is a more important question; do any of the fchdir
users need to stay LGPL?
fts-lgpl already has licensing issues that have been brought up this
month, so I don't think you would be making matters any wor
Jim Meyering wrote:
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
...except that a declaration for fchdir() is already provided (hmm,
sorry, should have mentioned it is the link that dies, not the compile).
So why would an fchdir.h be needed?
If your system really does have an fchdir declaration
Bruno Haible <[EMAIL PROTECTED]> writes:
> Huh? I think there is a misunderstanding. The GNU standards don't want
> 'pathname' to occur in the documentation in the sense as POSIX uses it,
> because of the PATH variable and the concept of search paths. Paul then
> doesn't want to use 'pathname' in
Eric Blake wrote:
> Also, GNU coding
> standards recommend using just 'name', rather than 'filename' or even 'file'.
Huh? I think there is a misunderstanding. The GNU standards don't want
'pathname' to occur in the documentation in the sense as POSIX uses it,
because of the PATH variable and the
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> ...except that a declaration for fchdir() is already provided (hmm,
> sorry, should have mentioned it is the link that dies, not the compile).
> So why would an fchdir.h be needed?
If your system really does have an fchdir declaration (in unistd.h?),
th
-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?
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
25 matches
Mail list logo
