Re: [PATCH v1] Remove 'restrict' from 'nptr' in strtol(3)-like functions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> 






[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux