> 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.
Looks OK from the libc side.
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.
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
> 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
That change is fine.
> 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 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'
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,
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
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
Those changes are fine.
> 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.
> 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
> 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:
> 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,
> 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
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
18 matches
Mail list logo
