On 7/27/22 12:27, Bruno Haible wrote:
We had this discussion already in Feb 2020:
Oh, thanks for reminding me; I'd quite forgotten.
what we need is not to add more 'restrict' here and
there, but rather an understandable (and still correct) explanation of
what 'restrict' means, including for
On Wed, 2022-07-27 at 21:27 +0200, Bruno Haible wrote:
> [Removing coreutils from CC.]
> Paul Eggert wrote:
> > Thanks for the bug report. It's clearly a bug in 'touch'. I
> > installed
> > the attached patch into Coreutils master on Savannah.
>
> It's good to see that the 'restrict' annotations
[Removing coreutils from CC.]
Paul Eggert wrote:
> Thanks for the bug report. It's clearly a bug in 'touch'. I installed
> the attached patch into Coreutils master on Savannah.
It's good to see that the 'restrict' annotations that we discussed in
February 2020 [1] and then added [2] actually caug
Thanks for the bug report. It's clearly a bug in 'touch'. I installed
the attached patch into Coreutils master on Savannah.
It strikes me that the signatures for parse_datetime and parse_datetime2
could use more 'restrict's. For example, instead of this:
bool parse_datetime (struct timespec
Hi everyone,
I'm currently working on new warnings for gcc's -fanalyzer. I've
implemented a version of Wrestrict inside the analyzer, using its
region model to detect more cases of overlapping buffers in memcpy and
aliases to restrict-qualified parameters. While testing my new warning,
I got one r
