"James Youngman" wrote:
> On Mon, Dec 15, 2008 at 12:18 AM, Bruno Haible wrote:
>> However, for openat-die.c I don't see a good replacement. In particular, I
>> don't see a way how openat_restore_fail() could be handled in library code.
>> A program cannot simply continue when its current directo
Bruno Haible wrote:
>> openat emulation depends on save-cwd (GPL), which can call xgetcwd (GPL),
>> which
>> in turn can call xalloc_die (GPL)?
>
> openat() and the related system calls are not supposed to signal errors by
> themselves and exit the program. Is it possible to restructure the code
James Youngman wrote:
> only fchdir does have the
> advantage that we know that restoring the current directory can't fail.
Yes, this should work on Unix systems. On mingw, open (".", O_RDONLY) fails,
but that should be fixable by modifying lib/open.c and lib/fchdir.c.
But is that restriction -
Daniel Richard G. wrote:
> -std puts the compiler into relaxed-ANSI mode, instead of the default, which
> is K&R. This flag was actually added by autoconf itself---the build failure I
> quoted was obtained with all *FLAGS variables unset.
>
> (The only other options here are -std1 [strict ANSI],
On Mon, Dec 15, 2008 at 12:18 AM, Bruno Haible wrote:
> However, for openat-die.c I don't see a good replacement. In particular, I
> don't see a way how openat_restore_fail() could be handled in library code.
> A program cannot simply continue when its current directory is different from
> what it
Hi Jim,
> openat emulation depends on save-cwd (GPL), which can call xgetcwd (GPL),
> which
> in turn can call xalloc_die (GPL)?
openat() and the related system calls are not supposed to signal errors by
themselves and exit the program. Is it possible to restructure the code so that
they only re
Sam Steingold wrote:
> How do I figure out if the fd (specifically, stdin=0) is open?
> apparently it is closed when the application is run by nohup.
> the only thing I could figure out so far is fstat: when 0 is open,
> st_mode is 8592, when it is closed it is 8630...
When fd is closed, fstat sho
Karl Berry wrote:
> What I don't understand with your proposal is how this magical url
> vs. file bit is known.
When producing/printing an error message, this information has to come
from the program. The program certainly knows whether it has used a function
like fopen() or open_url() to access t
Sam Steingold wrote:
> How do I figure out if the fd (specifically, stdin=0) is open?
> apparently it is closed when the application is run by nohup.
> the only thing I could figure out so far is fstat: when 0 is open,
> st_mode is 8592, when it is closed it is 8630...
Hi Sam,
This is very light
How do I figure out if the fd (specifically, stdin=0) is open?
apparently it is closed when the application is run by nohup.
the only thing I could figure out so far is fstat: when 0 is open,
st_mode is 8592, when it is closed it is 8630...
PS. Sorry about asking here, this is the most knowlegeabl
Bruno Haible wrote:
> Part 4: New functions.
>
> Jim, some of these functions (fchmodat, fchownat, fdopendir, fstatat, mkdirat,
> openat, unlinkat) are provided by gnulib module 'openat'. Others (faccessat,
> linkat, mkfifoat, mknodat, readlinkat, renameat, symlinkat, utimensat) are
> not.
> What
Ralf Wildenhues cited Daniel Richard G. and wrote:
> > However, I'm running into a more tricky issue during the build...
> >
> > source='sig2str.c' object='sig2str.o' libtool=no DEPDIR=.deps
> > depmode=tru64
> > /bin/ksh ../build-aux/depcomp cc -std -std -I.-ieee -g -c -o
> > sig2str.
On Sun, Dec 14, 2008 at 7:05 PM, Bruno Haible wrote:
> James Youngman wrote:
>> +2008-12-14 James Youngman
>> +
>> + getopt: Indicate the problem with ambiguous options clearly.
>> + * lib/getopt.c (_getopt_internal_r): Print the first and second
>> + possibility when there is an am
James Youngman wrote:
> +2008-12-14 James Youngman
> +
> + getopt: Indicate the problem with ambiguous options clearly.
> + * lib/getopt.c (_getopt_internal_r): Print the first and second
> + possibility when there is an ambiguous match.
The patch looks good. But the master sources
---
ChangeLog|6 ++
lib/getopt.c | 25 +
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7faac2b..b593588 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-12-14 James Youngman
+
+ getopt: Indicat
Part 4: New functions.
Jim, some of these functions (fchmodat, fchownat, fdopendir, fstatat, mkdirat,
openat, unlinkat) are provided by gnulib module 'openat'. Others (faccessat,
linkat, mkfifoat, mknodat, readlinkat, renameat, symlinkat, utimensat) are not.
What do you think about
- splitting t
Part 2: Updating the references to POSIX to refer to the new spec.
2008-12-14 Bruno Haible
Update doc for POSIX:2008.
* doc/posix-functions/*.texi: Update URL of POSIX specification.
--- doc/posix-functions/FD_CLR.texi.orig2008-12-14 14:36:13.0
+0100
+++ doc/p
Eric Blake wrote:
> POSIX 2008 is now freely available at:
> ...
> http://www.opengroup.org/onlinepubs/9699919799/toc.htm
I'm starting to update the gnulib documentation. Part 1: Handling of
functions that were removed.
2008-12-14 Bruno Haible
Update doc for POSIX:2008.
* doc/
Hello Ralf,
The relocatable-prog-wrapper module is a bit special, because its dependencies
cannot contain .c files. Since the 'errno' module satisfies this condition, it's
ok. Sorting the entries, however, is not necessary. I committed thisin your
name.
Thanks!
2008-12-14 Ralf Wildenhues
Hello Ralf,
> OK to commit? lib/unilbrk/tables.h #include's unitypes.h, otherwise
> causing a compile failure with
> gnulib-tool --test unilbrk/tables
Thanks for the fix. I prefer to let it depend on unilbrk/base, for
consistency with the other unilbrk/* modules. Applied this:
2008-12-14 Ra
[ adding bug-gnulib, removing bug-autoconf ]
* Daniel Richard G. wrote on Sat, Dec 13, 2008 at 11:16:28PM CET:
> However, I'm running into a more tricky issue during the build...
>
> source='sig2str.c' object='sig2str.o' libtool=no DEPDIR=.deps depmode=tru64
> /bin/ksh ../build-aux/depcomp cc
21 matches
Mail list logo
