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

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

 



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.

Cheers,
Alex

> > > > 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?

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.

-- 
<https://www.alejandro-colomar.es/>

Attachment: signature.asc
Description: PGP signature


[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