Am Freitag, dem 05.07.2024 um 17:53 +0200 schrieb Alejandro Colomar:
> Hi Martin,
> 
> On Fri, Jul 05, 2024 at 05:34:55PM GMT, Martin Uecker wrote:
> > > I've written functions that more closely resemble strtol(3), to show
> > > that in the end they all share the same issue regarding const-ness:
> 
> (Above I meant s/const/restrict/)
> 
> > > 
> > >   $ cat d.c 
> > >   int d(const char *restrict ca, char *restrict a)
> > >   {
> > >           return ca > a;
> > >   }
> > > 
> > >   int main(void)
> > >   {
> > >           char x = 3;
> > >           char *xp = &x;
> > >           d(xp, xp);
> > >   }
> > >   $ cc -Wall -Wextra d.c 
> > >   d.c: In function ‘main’:
> > >   d.c:10:9: warning: passing argument 2 to ‘restrict’-qualified parameter 
> > > aliases with argument 1 [-Wrestrict]
> > >      10 |         d(xp, xp);
> > >         |         ^
> > > 
> > > This trivial program causes a diagnostic.  (Although I think the '>'
> > > should also cause a diagnostic!!)
> > > 
> > > Let's add a reference, to resemble strtol(3):
> > > 
> > >   $ cat d2.c 
> > >   int d2(const char *restrict ca, char *restrict *restrict ap)
> > >   {
> > >           return ca > *ap;
> > >   }
> > > 
> > >   int main(void)
> > >   {
> > >           char x = 3;
> > >           char *xp = &x;
> > >           d2(xp, &xp);
> > >   }
> > >   $ cc -Wall -Wextra d2.c 
> > >   $ 
> > > 
> > > Why does this not cause a -Wrestrict diagnostic, while d.c does?  How
> > > are these programs any different regarding pointer restrict-ness?
> > 
> > It would require data flow anaylsis to produce the diagnostic while
> > the first can simply be diagnosed by comparing arguments.
> 
> Agree.  It seems like a task for -fanalyzer.
> 
>       $ cc -Wall -Wextra -fanalyzer -fuse-linker-plugin -flto d2.c
>       $
> 
> I'm unable to trigger that at all.  It's probably not implemented, I
> guess.  I've updated the bug report
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112833> to change the
> component to 'analyzer'.
> 
> At least, I hope there's consensus that while current GCC doesn't warn
> about this, ideally it should, which means it should warn for valid uses
> of strtol(3), which means strtol(3) should be fixed, in all of ISO,
> POSIX, and glibc.

I am not sure. 

> 
> > > > > Well, I don't know how to report that defect to WG14.  If you help me,
> > > > > I'll be pleased to do so.  Do they have a public mailing list or
> > > > > anything like that?
> > > > 
> > > > One can submit clarification or change requests:
> > > > 
> > > > https://www.open-std.org/jtc1/sc22/wg14/www/contributing.html
> 
> P.S.:
> 
> I've sent a mail to UNE (the Spanish National Body for ISO), and
> asked them about joining WG14.  Let's see what they say.
> 
> P.S. 2:
> 
> I'm also preparing a paper; would you mind championing it if I'm not yet
> able to do it when it's ready?

Guests can present too.

> 
> P.S. 3:
> 
> Do you know of any Spanish member of WG14?  Maybe I can talk with them
> to have more information about how they work.

You could ask Miguel Ojeda.

Martin

> 

Reply via email to