Re: z/OS enum size pitfall

2017-08-22 Thread Ben Pfaff
On Tue, Aug 22, 2017 at 10:09:22PM -0400, Daniel Richard G. wrote: > On Tue, 2017 Aug 22 15:01-0700, Ben Pfaff wrote: > > > > I don't know what XLC conforms to. > > > > C11 has the same text in 6.7.2.2p4. The specification for enums has > > not changed significantly since C89. > > > > Paul Eggert

Re: z/OS enum size pitfall

2017-08-22 Thread Daniel Richard G.
On Tue, 2017 Aug 22 15:01-0700, Ben Pfaff wrote: > > I don't know what XLC conforms to. > > C11 has the same text in 6.7.2.2p4. The specification for enums has > not changed significantly since C89. > > Paul Eggert already explained the distinction between enumeration > constants and enumeration

Re: z/OS enum size pitfall

2017-08-22 Thread Ben Pfaff
On Tue, Aug 22, 2017 at 10:43:07PM +0200, Tim Rühsen wrote: > On Dienstag, 22. August 2017 13:25:55 CEST Ben Pfaff wrote: > > On Tue, Aug 22, 2017 at 04:13:54PM -0400, Daniel Richard G. wrote: > > > What happens is that BILLION is implicitly typed as an unsigned int, > > > rather than an int. If yo

Re: clang's Undefined Sanitizer

2017-08-22 Thread Adhemerval Zanella
On 22/08/2017 18:34, Paul Eggert wrote: > On 08/22/2017 10:39 AM, Adhemerval Zanella wrote: >> In fact I decided to *not* sync flexmember because with >> following patch I intend to send (which are in the original thread) >> make flexmember unnecessary. > > I see that you sent these proposed pat

Re: z/OS enum size pitfall

2017-08-22 Thread Paul Eggert
On 08/22/2017 01:13 PM, Daniel Richard G. wrote: I have been in contact with IBM about this, originally reporting the issue as a compiler bug. However, they responded that the compiler behavior is conformant to the C standard and that they are less concerned with matching the behavior of other sy

Re: clang's Undefined Sanitizer

2017-08-22 Thread Paul Eggert
On 08/22/2017 10:39 AM, Adhemerval Zanella wrote: In fact I decided to *not* sync flexmember because with following patch I intend to send (which are in the original thread) make flexmember unnecessary. I see that you sent these proposed patches to glibc glob in the thread starting here: htt

Re: z/OS enum size pitfall

2017-08-22 Thread Tim Rühsen
On Dienstag, 22. August 2017 13:25:55 CEST Ben Pfaff wrote: > On Tue, Aug 22, 2017 at 04:13:54PM -0400, Daniel Richard G. wrote: > > Hello list, > > > > I'm writing in to report a bizarre issue with the IBM z/OS XLC compiler > > that is currently causing one gnulib test to fail (test-timespec), an

Re: z/OS enum size pitfall

2017-08-22 Thread Ben Pfaff
On Tue, Aug 22, 2017 at 04:13:54PM -0400, Daniel Richard G. wrote: > Hello list, > > I'm writing in to report a bizarre issue with the IBM z/OS XLC compiler > that is currently causing one gnulib test to fail (test-timespec), and > may present an issue for application code simply because no other

z/OS enum size pitfall

2017-08-22 Thread Daniel Richard G.
Hello list, I'm writing in to report a bizarre issue with the IBM z/OS XLC compiler that is currently causing one gnulib test to fail (test-timespec), and may present an issue for application code simply because no other compiler does things this way. My hope is to have gnulib integrate a workarou

Re: clang's Undefined Sanitizer

2017-08-22 Thread Adhemerval Zanella
On 22/08/2017 14:29, Paul Eggert wrote: > On 08/22/2017 09:49 AM, Bruno Haible wrote: >> It obviously does not handle the 'struct globnames' allocated with >> the FLEXSIZEOF macro (lines 1719..1732). > > Yes, and I installed the attached patch into Gnulib to try to fix this. I > hope it is enou

Re: clang's Undefined Sanitizer

2017-08-22 Thread Paul Eggert
On 08/22/2017 09:49 AM, Bruno Haible wrote: It obviously does not handle the 'struct globnames' allocated with the FLEXSIZEOF macro (lines 1719..1732). Yes, and I installed the attached patch into Gnulib to try to fix this. I hope it is enough to pacify clang's Undefined Sanitizer. If not, Tim

Re: Valgrind is complaining unitialized values in freea (malloca.c:135)

2017-08-22 Thread Bruno Haible
Hi, Marc Nieper-Wißkirchen wrote: > In freea in malloca.c, a possibly uninitialized indicator word is used for > a comparison so that Valgrind reports: "Conditional jump or move depends on > uninitialised value(s)". > > Valgrind is not smart enough to understand the logic in freea. > > It would

Re: clang's Undefined Sanitizer

2017-08-22 Thread Bruno Haible
[Changing the subject, as this is an unrelated topic.] Hi Tim, > I also see several false positives from clang's Undefined Sanitizer due to > alloca 'magic' (reallocations on stack space ?). This might not be directly > related, but I think there is a common coding pattern. > > glob.c:1738:23: r

Re: Valgrind is complaining unitialized values in freea (malloca.c:135)

2017-08-22 Thread Marc Nieper-Wißkirchen
I just noticed the file lib/malloca.valgrind, which can be used with the Valgrind option suppressions. Marc Am 22.08.2017 5:52 nachm. schrieb "Tim Rühsen" : > On Dienstag, 22. August 2017 06:11:41 CEST Marc Nieper-Wißkirchen wrote: > > In freea in malloca.c, a possibly uninitialized indicator wo

Re: Valgrind is complaining unitialized values in freea (malloca.c:135)

2017-08-22 Thread Tim Rühsen
On Dienstag, 22. August 2017 06:11:41 CEST Marc Nieper-Wißkirchen wrote: > In freea in malloca.c, a possibly uninitialized indicator word is used for > a comparison so that Valgrind reports: "Conditional jump or move depends on > uninitialised value(s)". > > Valgrind is not smart enough to underst

Valgrind is complaining unitialized values in freea (malloca.c:135)

2017-08-22 Thread Marc Nieper-Wißkirchen
In freea in malloca.c, a possibly uninitialized indicator word is used for a comparison so that Valgrind reports: "Conditional jump or move depends on uninitialised value(s)". Valgrind is not smart enough to understand the logic in freea. It would be nice if the warning could be silenced, either