I think that the Solaris *at functions were really primarily intended for
use with O_XATTR to get at "file attribute" magic pseudo-directories rather
than to optimize use of normal directories and files. Probably mkdirat
doesn't make sense in Solaris attribute pseudo-directories. But mkdirat is
a
> cp, cpio, mv, and tar currently use mkfifo and mknod,
> so you might want to add mkfifoat and mknodat to the list, too.
I suppose, though those are used by so few programs it is a bit more
questionable.
> I haven't looked too closely at find, but its -execdir predicate
> makes me think having e
> So I guess the exec*at business would ultimately be more complicated,
> with two file descriptor parameters: one identifying the working
> directory, and another by which to interpret the first parameter
> if it's a relative file name.
It seems adequate to just use chdir/fchdir for changing cwd,
> I.e., don't forget gfdl.texi. Is that the intention?
>
> Yes. I checked in new versions of all the Texinfo licenses to gnulib:
> fdl.texi gpl-2.0.texi gpl-3.0.texi lgpl-2.1.texi lgpl-3.0.texi.
>
> Let me know if problems ...
The old lgpl.texi was usable in a manual like libc's with:
> Similarly, if you include the LGPL in the manual (there is no
> requirement to do so, as far as I know), both gpl.texi and lgpl.texi
> should be included, in separate nodes. Yes, this is a change from the
> previous standalone lgpl.texi ...
Ok. The license was originally included in the C libr
> What is the reason? Can malloc() return NULL with errno being set to something
> different than ENOMEM?
It is probably just overly-conservative code in those callers.
Those changes are fine.
Paul's points are valid as a generic thing. But they aren't the key
points for considering changes to libc.
The entire discussion about maximum usable size is unnecessary
fritter. We already have __libc_use_alloca, alloca_account,
etc. (include/alloca.h) to govern that decision for libc code.
If
The substance of the change seems fine. It needs a proper ChangeLog entry.
See the glibc wiki for full instructions on posting patches.
> + struct stat64 st;
> + int r = fd >= 0 ? fstat64(fd, &st) : stat64(name, &st);
Put space before paren in those calls.
It's shorter and more common to inver
The patch itself now looks fine to me. The log entry is inadequate.
It needs to mention each file and function touched and say what was
done there. "Update caller." is sufficient text for a function to
which the only change was trivial argument reordering or whatnot. But
in most of these cases,
That looks fine.
> * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
> Pass fd to __internal_statvfs instead of calling fstat64.
> * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> Pass fd to __internal_statvfs64 instead of calling fstat64.
In a case like this, it'
> Roland McGrath wrote:
> > That looks fine.
> >
> > > * sysdeps/unix/sysv/linux/fstatvfs.c (fstatvfs):
> > > Pass fd to __internal_statvfs instead of calling fstat64.
> > > * sysdeps/unix/sysv/linux/fstatvfs64.c (__fstatvfs64):
> > >
That change is fine.
> a) Delete nonsense about "not polluting the namespace with stddef.h
> symbols" since string.h includes stddef.h a little later anyway.
If you are talking specifically about the glibc implementation's string.h,
then you are confused. glibc's string.h complies with the C and POSIX
standards, and
This is definitely not going to make it into glibc-2.20, so you might want
to wait until we're out of release freeze to worry too much about the
glibc-oriented bits. Meanwhile, you can iron out your other cleanups with
gnulib folks.
For glibc you need to do some more work to make the provision of
It would be easier to review if you separated the very trivial changes from
the others. The size_t change is clearly fine and can be approved quickly.
The refactoring requires more attention.
Looks OK from the libc side.
> a) Don't be concerned about "not polluting the namespace with stddef.h
>symbols" in obstack.h, since gnulib string.h includes stddef.h
>anyway, and it seems unlikely that anyone would care.
libc is where this sort of constraint is most likely to be important. I
doubt gnulib users care.
18 matches
Mail list logo
