Pádraig Brady wrote:
For reference ls is also impacted. Hopefully this suffices:
Yes, thanks, that should be enough -- could you please install it?
On 05/12/14 19:13, Eric Blake wrote:
> On 10/29/2014 09:35 PM, Paul Eggert wrote:
>> Alan Modra wrote:
>>
>>> One thing though, I didn't put the ChangeLog diffs in the patch as I
>>> usually add them when committing.
>>
>> Oh, I missed that. I added them now. For Gnulib it's better to put
>> them
Alan Modra writes:
> The alternative is to do as Paul suggested and make obstack_blank
> accept a negative length argument, but that would
> - kill >2G obstacks on 32-bit targets,
> - lose the nice symmetry with other obstack functions,
> and obstack_blank_fast is the right interface to use for s
On Fri, Dec 05, 2014 at 09:02:46PM +, Gary V. Vaughan wrote:
> If there's a way to at least diagnose negative arguments rather than silently
> change behavior, that would save other projects some migration headaches...
We could diagnose one of the m4 uses of obstack_blank at compile time,
but
On Dec 5, 2014, at 7:13 PM, Eric Blake wrote:
> On 10/29/2014 09:35 PM, Paul Eggert wrote:
>> Alan Modra wrote:
>>
>>> One thing though, I didn't put the ChangeLog diffs in the patch as I
>>> usually add them when committing.
>>
>> Oh, I missed that. I added them now. For Gnulib it's better to
On 10/29/2014 09:35 PM, Paul Eggert wrote:
> Alan Modra wrote:
>
>> One thing though, I didn't put the ChangeLog diffs in the patch as I
>> usually add them when committing.
>
> Oh, I missed that. I added them now. For Gnulib it's better to put
> them into the patch.
>
>> It is no longer possi
On 11/05/2014 03:21 AM, Alan Modra wrote:
I think you need to keep the casts, otherwise
you can only specify new extra arg alloc and free functions.
Thanks for catching that; I installed the attached fix into gnulib. It
is annoying that gcc -Wall complains about using malloc and free here,
but
On Tue, Nov 04, 2014 at 12:43:05AM -0800, Paul Eggert wrote:
> >I've added: "Earlier versions of obstacks allowed you to use
> >@code{obstack_blank} to shrink objects. This will no longer work."
>
> But this doesn't suffice for obstack_blank_stack, which *can* shrink objects
> and where user code
On 11/02/2014 11:07 PM, Alan Modra wrote:
Really, it's a fiction that the size argument of obstack_blank_fast has a type.
Yes and no. It's a fiction in the sense that obstack_blank_fast is a macro, so
its argument doesn't actually have a C type. But it's not a fiction in the
sense that obst
On Fri, Oct 31, 2014 at 12:50:25PM -0700, Paul Eggert wrote:
> 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 argument to make the current
> object smaller." Technically, though, the argument is of
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
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
On Wed, Oct 29, 2014 at 08:35:18PM -0700, Paul Eggert wrote:
> Alan Modra wrote:
> >It is no longer possible to shrink an obstack with obstack_blank (but
> >you can still do that with obstack_blank_fast).
>
> Ouch, I hadn't noticed that. That's an incompatible change and I expect it
> will break
Alan Modra wrote:
One thing though, I didn't put the ChangeLog diffs in the patch as I
usually add them when committing.
Oh, I missed that. I added them now. For Gnulib it's better to put them into
the patch.
It is no longer possible to shrink an obstack with obstack_blank (but
you can s
Joseph S. Myers wrote:
Note that we can't use in glibc sources unless we move to
requiring GCC >= 4.7
Ah, thanks for mentioning that; the attached patch should fix that. I pushed
this into gnulib.
From d91a04a3dfc05b42031e8fd00af2cd29b6fa585d Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date:
On Wed, Oct 29, 2014 at 12:33:19AM -0700, Paul Eggert wrote:
> Thanks for doing all this. The gnulib patches are good as far as they go,
> but they need one more change: alignments should also change from int to
> size_t. The first attached gnulib patch does that, plus it fixes a
> longstanding in
On Wed, 29 Oct 2014, Paul Eggert wrote:
> While we're in the neighborhood we should be using C11's alignof rather than
> reinventing that particular wheel; the second attached gnulib patch does that.
Note that we can't use in glibc sources unless we move to
requiring GCC >= 4.7 (and it's not cl
Thanks for doing all this. The gnulib patches are good as far as they go, but
they need one more change: alignments should also change from int to size_t.
The first attached gnulib patch does that, plus it fixes a longstanding integer
overflow bug that can occur with large alignments (plus larg
This is a revised series, adding the SHLIB_COMPAT support Roland
McGrath requested for glibc, and omitting patch 5/5 in the previous
series that Paul Eggert disliked, with reason.
I've also moved as much of the glibc specific code out of gnulib as I
could, and abandoned the idea of renaming versio
20 matches
Mail list logo
