On 2023-12-18 05:27, Bruno Haible wrote:
I would be willing to
1) open a bug report with the Clang ASAN people, asking them to move
the (char *) NULL + 0 detection to a separate, "pedantic"
category.
...
We would thus also need to
2) ask the clang people whether they can pro
Paul Eggert wrote:
> The bad citizen here is clang, not Gnulib or Coreutils. Or maybe it's
> the C standard; it doesn't matter. Clang needn't (and doesn't) complain
> about every violation of the C standard, and it should not be
> complaining about this one.
I would be willing to
1) open a bu
On 2023-12-16 13:09, Bruno Haible wrote:
It's like with other changes we saw in the past:
- strict aliasing rules - forbid to cast (int**) to (char**) etc.
- signed integer overflow.
What was once a common style is now outlawed.
It's not like those changes, because those other changes wer
Hi Paul,
Paul Eggert wrote:
> PS. The name END_OF_ARRAY is not the best, since a null pointer does not
> point to an array, and even when the pointer is non-null the macro can
> be used to point elsewhere than to the end of an array. A better name
> would be something like PTR_ADD, since the fi
On 12/4/23 05:57, Bruno Haible wrote:
In both cases, the ability to add NULL + 0 unifies code paths for
empty arrays and non-empty arrays. Such unified code paths are desirable:
they make the code look simpler.
...
Paul, is the attached patch OK with you?
Thanks, but I'm of two minds about tha
Paul Eggert 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. But we shouldn
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.
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
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
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
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
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 *'.
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
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:
21 matches
Mail list logo
