tag 25390 fixed
close 25390
thanks
Hello,
Thanks again for everyone who reported, fixed and improved sed and dfa/gnulib.
sed's update to latest gnulib is pushed here:
http://git.savannah.gnu.org/cgit/sed.git/commit/?id=44d99bf5c98ea77de0addf55ad7fe281396de996
followed by the new test:
http
Hello all, I am not subscribed so please cc me.
>From my local gnulib git repo when I run:
./gnulib-tool --create-testdir --dir=/tmp/test3 parse-datetime
It fails with:
/bin/sh ../build-aux/ylwrap ./parse-datetime.y \
y.tab.c parse-datetime.c \
* doc/intprops.texi (Integer Range Overflow): Update URLs.
---
ChangeLog | 5 +
doc/intprops.texi | 4 ++--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index d269b54..63d7b04 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2017-01-16 Pa
Eric Blake wrote:
POSIX is allowed to make guarantees where the
C standard left things unspecified, particularly if those guarantees are
already something that many coders are already relying on because they
don't know any better.
Yes, Gnulib code makes several such assumptions, documented in t
On 01/16/2017 04:20 PM, Eric Blake wrote:
> And the principle is that POSIX is allowed to make guarantees where the
> C standard left things unspecified, particularly if those guarantees are
> already something that many coders are already relying on because they
> don't know any better.
My case
On 01/16/2017 04:00 PM, Kamil Dudka wrote:
> On Monday, January 16, 2017 11:57:03 Paul Eggert wrote:
>> Kamil Dudka wrote:
>>> It can cause a real crash in certain execution environments.
>>
>> Which ones? I'm not interested in environments like -fsanitize=undefined,
>> which is designed to catch v
On Monday, January 16, 2017 11:57:03 Paul Eggert wrote:
> Kamil Dudka wrote:
> > It can cause a real crash in certain execution environments.
>
> Which ones? I'm not interested in environments like -fsanitize=undefined,
> which is designed to catch violations of the standard. I want to know of a
>
The 'host-cpu-c-abi' module (which is used by GNU libffcall) does not know
about some ABIs that have appeared in the last few years. This fixes it.
2017-01-16 Bruno Haible
host-cpu-c-abi: Add support for armhf, arm64, x32, s390x.
* m4/host-cpu-c-abi.m4 (gl_HOST_CPU_C_ABI): Req
Kamil Dudka wrote:
It can cause a real crash in certain execution environments.
Which ones? I'm not interested in environments like -fsanitize=undefined, which
is designed to catch violations of the standard. I want to know of a real
execution environment where memcpy (0, 0, 0) does something
On Monday, January 16, 2017 10:29:34 Eric Blake wrote:
> On 01/15/2017 08:09 PM, Paul Eggert wrote:
> > * lib/dfa.c (copy): Don’t pass NULL with size 0 to memcpy,
> > as this runs afoul of gcc -fsanitize=undefined.
>
> It's lame that gcc warns on that usage; I'm half-tempted to propose a
> POSIX b
Eric Blake wrote:
On 01/15/2017 08:09 PM, Paul Eggert wrote:
* lib/dfa.c (copy): Don’t pass NULL with size 0 to memcpy,
as this runs afoul of gcc -fsanitize=undefined.
It's lame that gcc warns on that usage
I agree; I wish it didn't, as the usage is benign on all real-world platforms
other t
On 01/15/2017 08:09 PM, Paul Eggert wrote:
> * lib/dfa.c (copy): Don’t pass NULL with size 0 to memcpy,
> as this runs afoul of gcc -fsanitize=undefined.
It's lame that gcc warns on that usage; I'm half-tempted to propose a
POSIX bug that various memory functions (memcpy being one of them)
should
12 matches
Mail list logo
