ChangeLog|6 ++
m4/time_h.m4 |4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 5c563fd..df89859 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2012-06-23 Paul Eggert
+
+ time: fix obsolete comment
+ * m4/time
On 06/23/2012 07:54 AM, Paolo Bonzini wrote:
> I'm waiting for feedback from the Gnulib guys.
Can you please summarize the issue, the proposed fixes,
and the pros and cons of each? The discussion has been
spread out for so long that I've forgotten half of it.
No need for anything fancy; URLs are
On 06/23/2012 09:22 AM, Bruno Haible wrote:
> getopt-posix: No longer guarantee that option processing is resettable.
That looks good to me, and thanks.
Hi Paul, Eric,
I wrote:
> It seems to me that
> - musl's getopt is POSIX compliant (at least it passes the 3 parts of
> the test when run individually).
> - The getopt.m4 test fails only because musl does not support one of
> the 3 known ways to reset option processing. Does it support
On 06/23/2012 08:10 AM, Paolo Bonzini wrote:
> However, in the case of close_stdin, is this important for something
> that happens rarely
I tend to agree that it's not that important, but isn't
this question moot now that freadahead has been ported
to musl? (And welcome back from vacation)
On Sun, Jun 17, 2012 at 6:15 PM, Bruno Haible wrote:
> Paul Eggert wrote:
>> On 06/12/2012 04:21 AM, Paolo Bonzini wrote:
>> > perhaps we can follow the suggestion and
>> > replace "if (freadahead (f))" with "if (freading(f) && !feof(f))" in
>> > closein.c.
>>
>> Yes, thanks, I like this idea the
On OpenBSD 5.0, I'm seeing this test failure in a testdir for module
'getopt-gnu':
test-getopt_long.h:232: assertion failed
FAIL: test-getopt
The issue is with disambiguation, say, when the user enters --foo
and the available options are --foobar and --foobaz but they have the same
actions.
This
On Sun, Jun 17, 2012 at 11:40 PM, Bruno Haible wrote:
> Isaac Dunham wrote:
>> > The test as it stands is "error out on unsupported platforms unless
>> > user specifies to use slow method".
>> > My proposal is "On unsupported platforms, use the slow method instead
>> > of erroring out."
>
> If we
> On the other hand, so far I saw no reply to my attempts to refute
> counterarguments
> against these patches. So, should I just submit git patches for one (or both)
> of them,
> for inclusion? Or does anybody still have reservations about this?
I'm waiting for feedback from the Gnulib guys. T
