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
Sorry, somehow I thought those patches were for glibc review, not gnulib
review.
The gnulib part is patch 5/5. I see a few problems there:
These days _GL_ATTRIBUTE_PURE is defined by m4/gnulib-common.m4 and so
there should be no need to include stdwhatever.h to define it if one is
using gnul
On Fri, Aug 29, 2014 at 09:57:49AM +0200, Thien-Thi Nguyen wrote:
> () Alan Modra
> () Fri, 29 Aug 2014 11:15:57 +0930
>
>On Mon, Aug 04, 2014 at 02:16:06PM +0930, Alan Modra wrote:
>> On Sat, Jul 26, 2014 at 03:27:07PM +0930, Alan Modra wrote:
>> > This patch series gives obstacks so
() Alan Modra
() Fri, 29 Aug 2014 11:15:57 +0930
On Mon, Aug 04, 2014 at 02:16:06PM +0930, Alan Modra wrote:
> On Sat, Jul 26, 2014 at 03:27:07PM +0930, Alan Modra wrote:
> > This patch series gives obstacks some much needed TLC. The first patch
http://lists.gnu.org/archive/html/bug
On Mon, Aug 04, 2014 at 02:16:06PM +0930, Alan Modra wrote:
> On Sat, Jul 26, 2014 at 03:27:07PM +0930, Alan Modra wrote:
> > This patch series gives obstacks some much needed TLC. The first patch
http://lists.gnu.org/archive/html/bug-gnulib/2014-07/msg00106.html
> Ping. It's been over a week,
On Sat, Jul 26, 2014 at 03:27:07PM +0930, Alan Modra wrote:
> This patch series gives obstacks some much needed TLC. The first patch
Ping. It's been over a week, and I haven't seen any comments on the
bulk of the patch series, except for Roland's comment about including
stddef.h unconditionally.
This patch series gives obstacks some much needed TLC. The first patch
is mostly just a tidy, with one perhaps controversial change, renaming
the function obstack_free to _obstack_free. This will be visible to
users who compile some code using a new obstack.h and try to link
against an old (but n
26 matches
Mail list logo
