Ben Pfaff writes:
>> I propose to add to getopt_long() — in Gnulib — code that verifies
>> the consistency between the two places, when a certain environment
>> variable (say, GETOPT_DEBUG) is set. And produces output on stderr
>> such as:
>> getopt_long: warning: option '--context' requires an
On Tue, Jun 24, 2025 at 6:16 PM Bruno Haible via Gnulib discussion
list wrote:
>
> I propose to add to getopt_long() — in Gnulib — code that verifies
> the consistency between the two places, when a certain environment
> variable (say, GETOPT_DEBUG) is set. And produces output on stderr
> such as:
On Wed, Jun 25, 2025 at 07:35:58PM +0200, Alejandro Colomar wrote:
> Hi Eric,
>
> On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote:
> > > > @@ New footnote XXX
> > > > +XXX)
> > > > +While atypical,
> > > > +realloc may fail
> > > > +for a c
On Wed, Jun 25, 2025 at 06:07:06PM +, Wilco Dijkstra wrote:
> Hi Alejandro,
>
> > > > > +XXX)
> > > > > +While atypical,
> > > > > +realloc may fail
> > > > > +for a call that shrinks the block of memory.
> > > >
> > > > Is it worth wording this as "may fail or return a different pointer
>
Hi Bruno,
Bruno Haible wrote:
The problem is that the properties of an option have to be specified
in *two* places: in the long_options array *and* in the 3rd argument
to getopt_long().
I propose to add to getopt_long() - in Gnulib - code that verifies
the consistency between the two places, wh
Hello!
Le mercredi 25 juin 2025 à 10:06 -0700, Paul Eggert a écrit :
> It would be nice to do the getopt check statically, if we're going to
> do
> it at all.
>
> While we're on the getopt topic, glibc might add translation of
> getopt
> argument strings:
>
> https://sourceware.org/pipermail/l
On Wed, Jun 25, 2025 at 06:07:06PM +, Wilco Dijkstra wrote:
> Hi Alejandro,
>
> > > > > +XXX)
> > > > > +While atypical,
> > > > > +realloc may fail
> > > > > +for a call that shrinks the block of memory.
> > > >
> > > > Is it worth wording this as "may fail or return a different pointer
>
Paul Eggert writes:
> I'm not sure it'd be that much smaller than what getopt-gnu already
> does. All we'd be removing is the idea of using the system getopt if
> it suffices, so that we always replace the system getopt if it exists.
The old version of the getopt files I have does that by checki
Hi Eric,
On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote:
> > > @@ New footnote XXX
> > > +XXX)
> > > +While atypical,
> > > +realloc may fail
> > > +for a call that shrinks the block of memory.
> >
> > Is it worth wording this as "may fail or return a different pointe
On 2025-06-25 08:09, Antonio Diaz Diaz wrote:
I think that it would be better to fix the problem for good by
deprecating getopt_long and recommending instead something that defines
the options in one place
It's a question of reinventing the wheel yet again, vs patching the
wheel we have.
I
On Wed, Jun 25, 2025 at 07:47:55PM +0200, Alejandro Colomar wrote:
> Hi Eric,
>
> On Wed, Jun 25, 2025 at 07:36:01PM +0200, Alejandro Colomar wrote:
> > On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote:
> > > > > @@ New footnote XXX
> > > > > +XXX)
> > > > > +Whi
Hi Alejandro,
> > > > +XXX)
> > > > +While atypical,
> > > > +realloc may fail
> > > > +for a call that shrinks the block of memory.
> > >
> > > Is it worth wording this as "may fail or return a different pointer
> > > for a call that shrinks the block of memory"?
> Oh, the text is still ther
Hi Wilco,
On Wed, Jun 25, 2025 at 06:07:06PM +, Wilco Dijkstra wrote:
> In principle a realloc that shrinks a non-NULL block does never need to fail.
> If it can't shrink the current block (either because internal design means it
> can't make it any smaller or because it doesn't have memory fo
On Wed, Jun 25, 2025 at 01:03:13PM -0500, Eric Blake wrote:
> On Wed, Jun 25, 2025 at 07:35:58PM +0200, Alejandro Colomar wrote:
> > Hi Eric,
> >
> > On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote:
> > > > > @@ New footnote XXX
> > > > > +XXX)
> > > > > +While
Hi Eric,
On Wed, Jun 25, 2025 at 07:36:01PM +0200, Alejandro Colomar wrote:
> On Wed, Jun 25, 2025 at 03:16:06PM +0200, Alejandro Colomar wrote:
> > > > @@ New footnote XXX
> > > > +XXX)
> > > > +While atypical,
> > > > +realloc may fail
> > > > +for a call
Hi Eric,
On Wed, Jun 25, 2025 at 07:58:06AM -0500, Eric Blake wrote:
> On Wed, Jun 25, 2025 at 03:58:31AM +0200, Alejandro Colomar wrote:
[...]
> > implementation of realloc(3), present in Unix V7, inherited by
> > the BSDs, and currently available in range of systems, including
> >
Paul Eggert wrote:
> > Paul, Jim: Would it be OK to move them to a Gnulib module?
>
> Sounds good to me.
Done through these three patches.
In the third patch, while writing a unit test, I noticed that the
documentation of kwsexec() was misleading, and corrected that.
2025-06-25 Bruno Haible
On Tue, Jun 24, 2025 at 8:19 PM Rich Felker wrote:
>
> On Tue, Jun 24, 2025 at 08:14:32PM -0400, Jeffrey Walton wrote:
> > On Tue, Jun 24, 2025 at 10:18 AM Alejandro Colomar wrote:
> > >
> > > Hi Florian,
> > >
> > > On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote:
> > > > [...]
>
On Tue, Jun 24, 2025 at 11:07:53AM +0200, Florian Weimer wrote:
> * Alejandro Colomar:
>
> > Here's a new revision of the proposal. I've removed ENOMEM, since it's
> > not strictly necessary; it's only necessary that those systems that
> > already set it continue setting it (and my proposal for P
On Wed, Jun 25, 2025 at 03:58:31AM +0200, Alejandro Colomar wrote:
> Hi!
>
> Here's a revision addressing a few things:
>
...
> Rationale
>
> However, this doesn't need to be like that. The traditional
> implementation of realloc(3), present in Unix V7, inherited by
> the BSD
20 matches
Mail list logo
