Bruno Haible wrote:
TYPE_MAXIMUM (nfds_t) / 2 is good for a quick check against an out-of-bounds
nfd.
POSIX [1] says that nfd is out-of-bounds if it is > getdtablesize().
OK, but getdtablesize returns 'int' so the 'poll' code should compare to INT_MAX
rather than to an expression that would n
Bruno Haible wrote:
- Some schemers even thought it was worthwhile to write a paper about their
implementation of this specification. [3].
Yes, Gnulib addresses this problem in the ftoastr module, using a simpler but
presumably less-efficient approach. As it happens, an improved algorithm wa
Hi Paul,
> > - if (nfd < 0)
> > + if (nfd > TYPE_MAXIMUM (nfds_t) / 2)
>
> This doesn't look right. What does TYPE_MAXIMUM (nfds_t) / 2 have to do with
> anything?
TYPE_MAXIMUM (nfds_t) / 2 is good for a quick check against an out-of-bounds
nfd.
POSIX [1] says that nfd is out-of-bounds if it
Hi Paul,
> Perhaps this is because I am a fan of shorter, more-intuitive numbers. You can
> blame me for the fact that in Emacs the double-precision floating-point number
> closest to 0.1 displays as "0.1" rather than as the more-precise but uglier
> "0.10001".
Likewise, in Lisp cultu
On Mac OS X, the getlogin_r test fails. The cause is that when the buffer size
is exactly as large as the login name (without terminating NUL), the Mac OS X
implementation does not return ERANGE; nor does it return the login name without
terminating NUL; no: it truncates the login name! So, when I
Pádraig Brady wrote:
using PRIuMAX may be best?
That would be too easy :-). I installed the attached.
From 8edebfe6f97d0e378d042accb2475a32a53f100f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 22 Apr 2017 15:13:24 -0700
Subject: [PATCH] parse-datetime: fix %z and prefer signed int
MIM
On 22/04/17 02:18, Paul Eggert wrote:
> Thanks for the heads-up. That code has long been on my list of things to
> clean
FYI I'm currently running date(1) with this change
+ ASAN enabled, through the latest AFL fuzzer,
seeded with the coreutils test corpus.
Bruno Haible wrote:
- if (nfd < 0)
+ if (nfd > TYPE_MAXIMUM (nfds_t) / 2)
This doesn't look right. What does TYPE_MAXIMUM (nfds_t) / 2 have to do with
anything? Plus, five lines later there's a comment that starts "Don't check
directly for NFD too large" and this seems to directly contradic
Bruno Haible wrote:
The algorithm for the second case also applies to the first case, but
no engineer with a sane mind would apply this algorithm to the first case.
Ah, that explains it! I was crazy, because I indeed thought of just that one
interpretation, and applied it to both cases.
Perh
Bruno Haible wrote:
What is the semantic difference between _Noreturn and
__attribute_noreturn__?
__attribute__ ((__noreturn__)), which the latter expands to, also works with
function pointers, whereas _Noreturn does not. The distinction can matter when a
function's address is assigned to a f
Wow impressive improvements!
On 22/04/17 02:18, Paul Eggert wrote:
> (date): Fix printf of size_t to use %z.
In coreutils we explicitly disallow the C99 %j and %z specifiers
due to portability issues on solaris 8 for example:
http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=v8.23-75-g7d1fe88
On 04/22/2017 11:18 AM, Paul Eggert wrote:
Thanks for the heads-up. That code has long been on my list of things to
clean up, and your message prompted me to go about it. I installed the
attached, which fixes the runtime problem corresponding to the
diagnostic you mentioned, along with a lot of o
On Mac OS X, I'm seeing a test failure of vasnprintf-posix:
test-vasnprintf-posix.c:272
printf "%.0a" of 1.51 returns "0x1p+0", where "0x2p+0" is expected. This is a
bug, because POSIX [1] says:
"For the a and A conversion specifiers, if FLT_RADIX is a power of 2,
the value shall be correctly
On Mac OS X, I'm seeing these warnings:
test-vasnprintf-posix3.c:64:1: warning: unused function 'test_vasnprintf'
[-Wunused-function]
test_vasnprintf ()
^
test-vasnprintf-posix3.c:70:1: warning: unused function 'test_asnprintf'
[-Wunused-function]
test_asnprintf ()
^
This fixes it:
2017-04-2
On Mac OS X, with CPPFLAGS=-Wall, I'm seeing this warning:
test-sys_file.c:26:11: warning: no case matching constant switch condition '0'
switch (0)
^
This fixes it:
2017-04-22 Bruno Haible
sys_file tests: Avoid warning.
* tests/test-sys_file.c (main): Add a def
On Mac OS X, I'm seeing this warning:
test-sethostname1.c:23:1: warning: incompatible pointer types initializing 'int
(*)(const char *, size_t)' (aka 'int (*)(const char *, unsigned long)') with an
expression of type 'int (const char *, int)' [-Wincompatible-pointer-types]
SIGNATURE_CHECK (setho
On Mac OS X, I'm seeing these warnings:
In file included from test-quotearg.c:32:
./test-quotearg.h:59:1: warning: unused function 'compare_strings'
[-Wunused-function]
compare_strings (char *(func) (char const *, size_t *),
^
./test-quotearg.h:102:1: warning: unused function 'use_quotearg_buffer
On Mac OS X, I'm seeing this warning:
poll.c:338:11: warning: comparison of unsigned expression < 0 is always false
[-Wtautological-compare]
if (nfd < 0)
~~~ ^ ~
Indeed, nfd is of type nfds_t, which is an unsigned integer type per POSIX [1].
This fixes it:
2017-04-22 Bruno Haible
On Mac OS X, with CPPFLAGS=-Wall, I'm seeing these warnings:
get-rusage-data.c:230:30: warning: 'sbrk' is deprecated
[-Wdeprecated-declarations]
void *new_page = sbrk (pagesize);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Develo
On Mac OS X 10.12 (with gcc -> clang), with CPPFLAGS=-Wall, I get this
warning:
obstack.c:351:31: warning: incompatible pointer types initializing 'void
(*)(void) __attribute__((noreturn))' with an expression of type 'void (void)'
[-Wincompatible-pointer-types]
__attribute_noreturn__ void (*obst
Paul Eggert wrote:
> > Why would you consider the expected result "0x1.922p+1" wrong?
>
> The POSIX spec says "if the precision is missing and FLT_RADIX is a power of
> 2,
> then the precision shall be sufficient for an exact representation of the
> value;
> if the precision is missing and FLT
Hi,
Gisle Vanem wrote:
> I get:
>xbinary-io.c(34): warning C4047: 'function': 'const char *' differs in
> levels of indirection from 'int'
>xbinary-io.c(34): warning C4024: 'error': different types for formal and
> actual parameter 3
Fixed by the patch below. Thanks for reporting this.
Bruno Haible wrote:
Why would you consider the expected result "0x1.922p+1" wrong?
The POSIX spec says "if the precision is missing and FLT_RADIX is a power of 2,
then the precision shall be sufficient for an exact representation of the value;
if the precision is missing and FLT_RADIX is not
Thanks for the heads-up. That code has long been on my list of things to clean
up, and your message prompted me to go about it. I installed the attached, which
fixes the runtime problem corresponding to the diagnostic you mentioned, along
with a lot of other problems. Please give it a try. I hop
Bruno Haible wrote:
diff --git a/lib/gettext.h b/lib/gettext.h
index 888e2fc..2a12bb6 100644
--- a/lib/gettext.h
+++ b/lib/gettext.h
@@ -18,8 +18,9 @@
#ifndef _LIBGETTEXT_H
#define _LIBGETTEXT_H 1
-/* NLS can be disabled through the configure --disable-nls option. */
-#if ENABLE_NLS
+/* NLS
25 matches
Mail list logo
