On Thu, Oct 30, 2014 at 8:05 AM, Eric Blake wrote:
> On 10/29/2014 12:29 PM, Jim Meyering wrote:
>> Thanks to many fixes and improvements by Paul Eggert and Norihiro Tanaka,
>> here is a pre-release snapshot:
>>
>> grep snapshot:
>> http://meyering.net/grep/grep-ss.tar.xz 1.2 MB
>
> You pro
Eric Blake wrote:
Can we use ssize_t instead of size_t for obstack_blank_fast?
Not portably, no. ssize_t need not be the same width as size_t.
As I understand it, ssize_t was partly invented to support platforms where
'read' took a 64-bit size_t argument and returned a 32-bit signed result -
On 10/31/2014 01:50 PM, Paul Eggert wrote:
> On 10/29/2014 11:07 PM, Alan Modra wrote:
>> So there are my reasons for leaving obstack_blank as is.
>
> Thanks, they're persuasive. With that in mind, I have a minor complaint
> about obstack_blank_fast's revised documentation. It says "You can use
Hello,
I'm translating some GNU packages po files.
The pot file of gnulib on Translation Project is too old,
and many fuzzy messages appear in many packages that import
gnulib.
Would you please upload latest pot file to Translation Project Server?
Thanks in advance,
--
Yasuaki Taniguchi (谷口康明)
On 10/29/2014 11:07 PM, Alan Modra wrote:
So there are my reasons for leaving obstack_blank as is.
Thanks, they're persuasive. With that in mind, I have a minor complaint
about obstack_blank_fast's revised documentation. It says "You can use
@code{obstack_blank_fast} with a negative size ar
* m4/linkat.m4 (gl_FUNC_LINKAT): linkat() is available on Yosemite
but not usable because it doesn't support creating hardlinks
to symlinks. Therefore add a generic test for this capability
and replace with our emulation if needed.
---
ChangeLog|8
m4/linkat.m4 | 22 +++
On 10/31/2014 06:25 PM, Pádraig Brady wrote:
> * m4/linkat.m4 (gl_FUNC_LINKAT): The compile check for AT_SYMLINK_FOLLOW
> was rundundant for a few reasons. It was present to support compiling
> on new systems but running on the old narrow window of Linux 2.6.1[67].
> It setup and cleaned up test f
I'll have to redo this one to use more of the !HAVE_LINKAT emulation in this
case
* m4/linkat.m4 (gl_FUNC_LINKAT): The compile check for AT_SYMLINK_FOLLOW
was rundundant for a few reasons. It was present to support compiling
on new systems but running on the old narrow window of Linux 2.6.1[67].
It setup and cleaned up test files which weren't actually used.
On non __linux__ it
On Thu, Oct 30, 2014 at 12:52:29PM -0700, Roland McGrath wrote:
> 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.
Split as requested and attached.
-
On Thu, Oct 30, 2014 at 12:51:11PM -0700, Roland McGrath wrote:
> > 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
On 10/29/2014 12:29 PM, Jim Meyering wrote:
> Thanks to many fixes and improvements by Paul Eggert and Norihiro Tanaka,
> here is a pre-release snapshot:
>
> grep snapshot:
> http://meyering.net/grep/grep-ss.tar.xz 1.2 MB
You probably want to fix your process for sending these mails;
'rele
> 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.
15 matches
Mail list logo
