Re: undefined-behavior obstack.c:139

On Wed, Feb 22, 2023 at 09:04:05AM +, Alexey Palienko wrote: > Hi! > First of all, I would like to thank you for your contribution to the open > source! > > I found some problem with m4 1.4.18. It has been built by clang 13 with "-g > -fsanitize=address,undefined -fno-omit-frame-pointer >

Re: undefined-behavior obstack.c:139

Am So., 3. Dez. 2023 um 10:05 Uhr schrieb Paul Eggert : > On 2023-12-02 01:04, Bruno Haible wrote: > > On the contrary, I will try to find and eliminate such alarms. > > Please don't complicate and/or slow down shared Gnulib code just to > pacify this particular false alarm from Clang. The obstack

Re: undefined-behavior obstack.c:139

On 2023-12-02 01:04, Bruno Haible wrote: On the contrary, I will try to find and eliminate such alarms. Please don't complicate and/or slow down shared Gnulib code just to pacify this particular false alarm from Clang. The obstack fix was fine, because it made obstack clearer and no slower. B

Re: undefined-behavior obstack.c:139

On Sat, Dec 02, 2023 at 09:50:33AM +0100, Bruno Haible wrote: > I still don't know whether it's OK to have pointers to arrays with > 0 elements (which are not "array objects", since "objects" are non- > empty (§ 6.2.6.1.(2))). From § 6.7.6.2 about array declarators: If the expression is a cons

Re: undefined-behavior obstack.c:139

Paul Eggert wrote: > > Indeed, this sentence appears to forbid ((char *) NULL) + something. > > Yes. However, Gnulib code can still use ((char *) NULL) + something) > because the Gnulib portability guidelines allow it. > > The issue with clang false positives is covered here: > > https://www.gn

Re: undefined-behavior obstack.c:139

Andreas F. Borchert wrote: > In summary, null pointer constants are not pointers to an object > or an element of an array object and thereby must not be used > for pointer arithmetic. Thanks for the explanations. I still don't know whether it's OK to have pointers to arrays with 0 elements (which

Re: undefined-behavior obstack.c:139

On 2023-12-01 12:36, Marc Nieper-Wißkirchen wrote: It may not be a false alarm in future versions of the compiler. If that happens, Gnulib (and lots of other software) won't work in those future versions. This is so unlikely that we needn't worry about it now.

Re: undefined-behavior obstack.c:139

Am Fr., 1. Dez. 2023 um 21:01 Uhr schrieb Paul Eggert : > On 2023-12-01 10:40, Bruno Haible wrote: > > > Indeed, this sentence appears to forbid ((char *) NULL) + something. > > Yes. However, Gnulib code can still use ((char *) NULL) + something) > because the Gnulib portability guidelines allow i

Re: undefined-behavior obstack.c:139

Am Fr., 1. Dez. 2023 um 19:42 Uhr schrieb Bruno Haible : > Marc Nieper-Wißkirchen wrote: > > By 6.5.6 "Additive Operators": > > > > (2) "... one operator shall be a pointer to a complete object type..." > > > > NULL, which is a null pointer constant, is not necessarily a pointer to a > > complete

Re: undefined-behavior obstack.c:139

By 6.5.6 "Additive Operators": (2) "... one operator shall be a pointer to a complete object type..." NULL, which is a null pointer constant, is not necessarily a pointer to a complete object type. (9) "... If the pointer operand and the result do not point to elements of the same array object o

Re: undefined-behavior obstack.c:139

On 2023-12-01 10:40, Bruno Haible wrote: Indeed, this sentence appears to forbid ((char *) NULL) + something. Yes. However, Gnulib code can still use ((char *) NULL) + something) because the Gnulib portability guidelines allow it. The issue with clang false positives is covered here: https

Re: undefined-behavior obstack.c:139

Marc Nieper-Wißkirchen wrote: > By 6.5.6 "Additive Operators": > > (2) "... one operator shall be a pointer to a complete object type..." > > NULL, which is a null pointer constant, is not necessarily a pointer to a > complete object type. In my test program, I used a variable of type 'char *'.

Re: undefined-behavior obstack.c:139

On Fri, Dec 01, 2023 at 05:01:45PM +0100, Bruno Haible wrote: > Jeffrey Walton wrote: > > I think that's a valid finding. NULL is not a valid address. You can't > > add anything to it. > > Can you back this opinion with citations from ISO C 23 [1] ? See N3096 (most recent draft of C23 [1]), quote

Re: undefined-behavior obstack.c:139

Jeffrey Walton wrote: > I think that's a valid finding. NULL is not a valid address. You can't > add anything to it. Can you back this opinion with citations from ISO C 23 [1] ? Bruno [1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf

Re: undefined-behavior obstack.c:139

On Fri, Dec 1, 2023 at 8:15 AM Bruno Haible wrote: > > [CCing bug-gnulib because obstack.c comes from gnulib.] > > Alexey Palienko wrote in > : > > > It has been built by clang 13 with "-g -fsanitize=address,undefined > > -fno-omit

Re: undefined-behavior obstack.c:139

[CCing bug-gnulib because obstack.c comes from gnulib.] Alexey Palienko wrote in : > It has been built by clang 13 with "-g -fsanitize=address,undefined > -fno-omit-frame-pointer -fsanitize-address-use-after-scope > -fno-sanitize