Re: WG14 paper for removing restrict from nptr in strtol(3)

[Martin Uecker <ma.uecker@gmail.com>]

Am Sonntag, dem 07.07.2024 um 13:07 +0200 schrieb Alejandro Colomar via Gcc:
> Hi Martin,
> 
> On Sun, Jul 07, 2024 at 09:15:23AM GMT, Martin Uecker wrote:
> > 
> > Hi Alejandro,
> > 
> > if in caller it is known that endptr has access mode "write_only"
> > then it can conclude that the content of *endptr has access mode
> > "none", couldn't it?
> 
> Hmmmm.  I think you're correct.  I'll incorporate that and see how it
> affects the caller.
> 
> At first glance, I think it would result in
> 
> 	nptr	access(read_only)	alias *endptr
> 	endptr	access(write_only)	unique
> 	errno	access(read_write)	unique
> 	*endptr	access(none)		alias nptr
> 
> Which is actually having perfect information, regardless of 'restrict'
> on nptr.  :-)

Yes, but my point is that even with "restrict" a smarter
compiler could then also be smart enough not to warn even
when *endptr aliases nptr.

> 
> > You also need to discuss backwards compatibility.  Changing
> > the type of those functions can break valid programs.
> 
> I might be forgetting about other possibilities, but the only one I had
> in mind that could break API would be function pointers.  However, a
> small experiment seems to say it doesn't:

Right, the outermost qualifiers are ignored, so this is not a
compatibility problem.  So I think this is not an issue, but
it is worth pointing it out.

Martin

> 
> 	$ cat strtolp.c 
> 	#include <stdlib.h>
> 
> 	long
> 	alx_strtol(const char *nptr, char **restrict endptr, int base)
> 	{
> 		return strtol(nptr, endptr, base);
> 	}
> 
> 	typedef long (*strtolp_t)(const char *restrict nptr,
> 				  char **restrict endptr, int base);
> 	typedef long (*strtolpnr_t)(const char *nptr,
> 				   char **restrict endptr, int base);
> 
> 	int
> 	main(void)
> 	{
> 		[[maybe_unused]] strtolp_t    a = &strtol;
> 		[[maybe_unused]] strtolpnr_t  b = &strtol;
> 		[[maybe_unused]] strtolp_t    c = &alx_strtol;
> 		[[maybe_unused]] strtolpnr_t  d = &alx_strtol;
> 	}
> 
> 	$ cc -Wall -Wextra strtolp.c 
> 	$
> 
> Anyway, I'll say that it doesn't seem to break API.
> 
> >  You would
> > need to make a case that this is unlikely to affect any real
> > world program.
> 
> If you have something else in mind that could break API, please let me
> know, and I'll add it to the experiments.
> 
> Thanks!
> 
> Have a lovely day!
> Alex
>