t 107820858999056 to
> null pointer
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior obstack.c:139:35 in
>
> I think, it is so and for 1.4.19
Bruno Haible supplied a fix for this, which will appear in the
upcoming 1.4.20.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org
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
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
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
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
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
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.
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
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
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
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
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 *'.
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
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
gt; > obstack.c:139:35: runtime error: applying non-zero offset 107820858999056
> > to null pointer
> > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior obstack.c:139:35 in
>
> I reproduce the issue with the newest m4 snapshot and with clang 17.
>
> However, it's
ter-scope
> -fno-sanitize-recover=all"
> And we have an error:
>
> #
> /home/docker/.conan/data/m4/latest/_/_/package/3421fde5744f1eadef515027cbcbb9a8fbcd667c/bin/m4
> obstack.c:139:35: runtime error: applying non-zero offset 107820858999056 to
> null pointer
> SUMMARY:
we have an error:
#
/home/docker/.conan/data/m4/latest/_/_/package/3421fde5744f1eadef515027cbcbb9a8fbcd667c/bin/m4
obstack.c:139:35: runtime error: applying non-zero offset 107820858999056 to
null pointer
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior obstack.c:139:35 in
I think, it is
17 matches
Mail list logo
