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

[Alejandro Colomar via Gcc]

Hi Dave,

On Mon, Jul 08, 2024 at 06:48:51PM GMT, David Malcolm wrote:
> > restrict, as of the formal definition of ISO C is useless crap.  The
> > more I read it, the more I agree.
> 
> Please note that "useless crap" was your wording, not mine.

Yup.  :)

> 
> > 
> > restrict, as of what -Wrestrict warns about, seems a reasonable
> > thing.
> > 
> > How about a [[gnu::restrict()]] attribute, similar to
> > [[gnu::access()]],
> > which is simpler than the qualifier?  Since restrict is only
> > meaningful
> > in function boundaries, it would make sense to have a function
> > attribute.  We don't want a qualifier that must follow discarding
> > rules.
> 
> If it doesn't have the same meaning as "restrict" then perhaps call the
> proposed attribute something other than "restrict"?

Yup, I was thinking that maybe noalias is a better name.

> 
> That said, I don't have strong opinions on any of this, except to note
> that I have more than enough *other* work on improvements to GCC's
> static analyzer and usability to keep me busy, so getting sucked into
> discussion/implementation on 'restrict' is something I want to avoid,
> and -Wanalyzer-overlapping-buffers is getting the job done for me at
> the moment.
> 
> [...snip...]
> 
> Hope this is constructive; sorry again if I missed anything due to only
> skimming the thread

It is.  I don't want you to work on this if you don't have time or
interest.  Just having the idea floating aroud, and if somebody finds
time to have a look at it in the next decade, maybe try it.  :-)

Does that make sense?

Cheers,
Alex

> 
> Dave
> 
> 

-- 



signature.asc
Description: PGP signature

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

[Jakub Jelinek via Gcc]

On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > > restrict, as of what -Wrestrict warns about, seems a reasonable
> > > thing.
> > > 
> > > How about a [[gnu::restrict()]] attribute, similar to
> > > [[gnu::access()]],
> > > which is simpler than the qualifier?  Since restrict is only
> > > meaningful
> > > in function boundaries, it would make sense to have a function
> > > attribute.  We don't want a qualifier that must follow discarding
> > > rules.
> > 
> > If it doesn't have the same meaning as "restrict" then perhaps call the
> > proposed attribute something other than "restrict"?
> 
> Yup, I was thinking that maybe noalias is a better name.

Name is one thing, but you'd also need to clearly define what it means.
When restrict is access based, it is clear what it means.

If you want something else which is not based on accesses and which should
allow warnings in the callers, I suppose you need to specify not just the
pointer but the extent as well (and maybe stride) or that it is an '\0'
terminated string, because if you want to say that for
void foo (char *, const char *, int);
the 2 pointers don't really alias, the size information is missing.  So,
shall the new warning warn on
struct S { char a[1024]; char b[1024]; } s;
foo (s.a, s.b, 512);
or not?  Or foo (s.a, s.a + 512, 512);

Jakub

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

[Alejandro Colomar via Gcc]

Hi Martin,

On Tue, Jul 09, 2024 at 07:58:40AM GMT, Martin Uecker wrote:
> Am Montag, dem 08.07.2024 um 22:17 +0200 schrieb Alejandro Colomar:
> > Hi Martin,
> > 
> > On Mon, Jul 08, 2024 at 06:05:08PM GMT, Martin Uecker wrote:
> > > Am Montag, dem 08.07.2024 um 17:01 +0200 schrieb Alejandro Colomar:
> > > > On Mon, Jul 08, 2024 at 10:30:48AM GMT, David Malcolm wrote:
> > > 
> > > ...
> > > > And then have it mean something strict, such as: The object pointed to
> > > > by the pointer is not pointed to by any other pointer; period.
> > > > 
> > > > This definition is already what -Wrestrict seems to understand.
> > > 
> > > One of the main uses of restrict is scientific computing. In this
> > > context such a definition of "restrict" would not work for many 
> > > important use cases. But I agree that for warning purposes the
> > > definition of "restrict" in ISO C is not helpful.
> > 
> > Do you have some examples of functions where this matters and is
> > important?  I'm curious to see them.  Maybe we find some alternative.
> 
> In many numerical algorithms you want to operate on
> different parts of the same array object.  E.g. for matrix
> decompositions you want to take a row / column and add it 
> to another. Other examples are algorithms that decompose
> some input (.e.g. high and low band in a wavelet transform)
> and store it into the same output array, etc.
> 
> Without new notation for strided array slicing, one

I'll have to remove dust from my old proposal of [.nmemb]?  :)

> fundamentally needs the flexibility of restrict that
> only guarantuees that actual accesses do not conflict.

I guess a combination of [.nmemb] (or the third argument of
[[gnu::access()]] and [[alx::noalias]] could be good enough for such a
use case?

[[alx::noalias(1)]] [[alx::noalias(2)]]
void add(int a[.n], const int b[.n], n);

//or

[[alx::noalias(1)]] [[alx::noalias(2)]]
[[gnu::access(read_write, 1, 3)]] [[gnu::access(read_only, 2, 3)]]
void add(int a[], const int b[], n);

mad(&arr[0], &arr[50], 50);

The caller should be able to know that while the pointers can alias
within the caller, they don't alias within the callee, since the callee
has no right to access past the specified bound*.

*  The standard would have to tighten bounds in function interfaces,
   since right now, the value is just ignored if it doesn't come with
   'static' (which I never understood), and if specified with 'static',
   it's just a lower bound not a strict bound.  I would propose changing
   the meaning of [N] in a function prototype to mean a strict bound.

Does that make sense?

Have a lovely day!
Alex

> But this then implies that one can not use restrict as a
> contract specification on function prototypes, but has
> to analyze the implementation of a function to see if
> it is used correctly.  But I would not see it as a design 
> problem of restrict. It was simply not the intended use 
> case when originally designed. 

-- 



signature.asc
Description: PGP signature

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

[Alejandro Colomar via Gcc]

Hi Jakub,

On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote:
> On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > Yup, I was thinking that maybe noalias is a better name.
> 
> Name is one thing, but you'd also need to clearly define what it means.
> When restrict is access based, it is clear what it means.
> 
> If you want something else which is not based on accesses and which should
> allow warnings in the callers, I suppose you need to specify not just the
> pointer but the extent as well (and maybe stride) or that it is an '\0'

Agree.  Here's how I'd define it as an attribute:

noalias

The noalias function attribute specifies that the pointer to
which it applies is the only reference to the array object that
it points to (except that a pointer to one past the last
element may overlap another object).

If the number of elements is specified with array notation, the
array object to be considered is a subobject of the original
array object, which is limited to the number of elements
specified in the function prototype.

Example:

[[alx::noalias(1)]] [[alx::noalias(2)]]
[[gnu::access(read_write, 1)]] [[gnu::access(read_only, 2)]]
void add_inplace(int a[n], const int b[n], size_t n);

char arr[100] = ...;

add_inplace(arr, arr + 50, 50);

In the example above, the parameters a and b don't alias inside
the function, since the subobjects of 50 elements do not overlap
eachother, even though they are one single array object to the
outer function.

It may need some adjustment, to avoid conflicts with other parts of
ISO C, but this is the idea I have in mind.

> terminated string, because if you want to say that for
> void foo (char *, const char *, int);
> the 2 pointers don't really alias, the size information is missing.  So,
> shall the new warning warn on
> struct S { char a[1024]; char b[1024]; } s;
> foo (s.a, s.b, 512);

This does not need clarification of bounds.  You're passing separate
objects, and thus cannot alias (except that maybe you're able to cast
to the struct type, and then access s.b from a pointer derived from
s.a; I never know that rule too well).

> or not?  Or foo (s.a, s.a + 512, 512);

According to the definition I provide in this email, the above is just
fine.

Thanks!

Have a lovely day!
Alex

> 
>   Jakub
> 
> 

-- 



signature.asc
Description: PGP signature

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

[Alejandro Colomar via Gcc]

On Tue, Jul 09, 2024 at 12:28:18PM GMT, Alejandro Colomar wrote:
> Hi Jakub,
> 
> On Tue, Jul 09, 2024 at 11:18:11AM GMT, Jakub Jelinek wrote:
> > On Tue, Jul 09, 2024 at 11:07:59AM +0200, Alejandro Colomar wrote:
> > > Yup, I was thinking that maybe noalias is a better name.
> > 
> > Name is one thing, but you'd also need to clearly define what it means.
> > When restrict is access based, it is clear what it means.
> > 
> > If you want something else which is not based on accesses and which should
> > allow warnings in the callers, I suppose you need to specify not just the
> > pointer but the extent as well (and maybe stride) or that it is an '\0'
> 
> Agree.  Here's how I'd define it as an attribute:
> 
> noalias
> 
>   The noalias function attribute specifies that the pointer to
>   which it applies is the only reference to the array object that
>   it points to (except that a pointer to one past the last
>   element may overlap another object).
> 
>   If the number of elements is specified with array notation, the
>   array object to be considered is a subobject of the original
>   array object, which is limited to the number of elements
>   specified in the function prototype.
> 
>   Example:
> 
>   [[alx::noalias(1)]] [[alx::noalias(2)]]
>   [[gnu::access(read_write, 1)]] [[gnu::access(read_only, 2)]]
>   void add_inplace(int a[n], const int b[n], size_t n);

Ooops, I meant 'n' to be the first parameter.

> 
>   char arr[100] = ...;
> 
>   add_inplace(arr, arr + 50, 50);
> 
>   In the example above, the parameters a and b don't alias inside
>   the function, since the subobjects of 50 elements do not overlap
>   eachother, even though they are one single array object to the
>   outer function.
> 
> It may need some adjustment, to avoid conflicts with other parts of
> ISO C, but this is the idea I have in mind.
> 
> > terminated string, because if you want to say that for
> > void foo (char *, const char *, int);
> > the 2 pointers don't really alias, the size information is missing.  So,
> > shall the new warning warn on
> > struct S { char a[1024]; char b[1024]; } s;
> > foo (s.a, s.b, 512);
> 
> This does not need clarification of bounds.  You're passing separate
> objects, and thus cannot alias (except that maybe you're able to cast
> to the struct type, and then access s.b from a pointer derived from
> s.a; I never know that rule too well).
> 
> > or not?  Or foo (s.a, s.a + 512, 512);
> 
> According to the definition I provide in this email, the above is just
> fine.
> 
> Thanks!
> 
> Have a lovely day!
> Alex
> 
> > 
> > Jakub
> > 
> > 
> 
> -- 
> 



-- 



signature.asc
Description: PGP signature

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

[Paul Eggert]

On 7/8/24 00:52, Alejandro Colomar wrote:
> a small set of functions
> accept pointers that alias each other, but one of them is never
> accessed; in those few cases, restrict was added to the parameters in
> ISO C, but I claim it would be better removed.

Are these aliasing pointers the nptr and initial *endptr of strtol? That 
is, are you saying that last line in the following example, which is 
currently invalid, should become valid and should be implementable as 
‘end = s; long l = 0;’?


   char *end;
   char *s = (char *) &end;
   *s = '\0';
   long l = strtol (s, &end, 0);

If so, I fail to see the motivation for the proposed change, as nobody 
writes (or should write) code like that. And if not, evidently I 
misunderstand the proposal.



> the small set of functions where this happens don't seem to use any 
state,

> so we don't need to care about implementations using internal buffers
> that are passed somehow to the user.

For strtol (nptr, endptr, 10) evidently the state that’s of concern is 
the value of *endptr. But here it’s possible that an implementation 
could use that state, even if the source code of the implementation's 
strtol does not. For example, suppose the key part of the base 10 
implementation in strtol.c is this:


bool overflow = false;
long int n = 0;
for (; '0' <= *nptr && *nptr <= '9'; nptr++)
  {
overflow |= ckd_mul (&n, n, 10);
overflow |= ckd_add (&n, n, *nptr - '0');
  }
*endptr = (char *) nptr;
... more code goes here ...

Currently, on typical platforms where CHAR_WIDTH < INT_WIDTH and 
INT_WIDTH == UINT_WIDTH, the C standard lets the compiler to compile 
this code as if it were the following instead.


bool overflow = false;
long int n = 0;
*endptr = (char *) nptr;
unsigned int digit = *nptr++ - '0';
if (digit <= 9)
  {
n = digit;
while ((digit = *nptr++ - '0') <= 9)
  {
overflow |= ckd_mul (&n, n, 10);
overflow |= ckd_add (&n, n, digit);
  }
*endptr = (char *) nptr;
  }
... more code goes here ...

This sort of thing might make sense on some architectures. However, the 
proposed change would not allow this optimization, because it’s invalid 
when nptr points into *endptr.


For strtol I suppose this is not that big a deal; strtol is kinda slow 
anyway so who cares if it’s a bit slower? But surely we wouldn’t want to 
give up even this minor performance win unless we get something in 
return, and I’m still not seeing what we get in return.



> Maybe I should use abstract names for the objects, to avoid confusing
> them with the pointer variables that are used to pass them?

That might help, yes, since v0.2 is unclear on this point.


> this formal
> definition is quite unreadable, though.  The more I read it, the less
> sure I am about it.

Yes, it’s lovely isn’t it? One must understand what the C committee
intended in order to read and understand that part of the standard.


>If L is used to access the value of the object X that it
>designates, and X is also modified (by any means), then the
>following requirements apply: T shall not be const-qualified
>
> This reads to me as "const variables are not writable when they are
> accessed via a restricted pointer; casting away is not enough".  Am I
> reading this correctly?

In that quoted statement, the restricted pointer is not allowed to be 
pointer-to-const. However, I’m not quite sure what your question means, 
as the phrase “const variables” does not appear in the standard. Perhaps 
give an example to clarify the question?



>> an implementation is allowed to set errno = EINVAL first thing, and 
then set
>> errno to some other nonzero value if it determines that the 
arguments are

>> valid. I wouldn't implement strtol that way, but I can see where someone
>> else might do that.
>
> In any case an implementation is not obliged to pessimize strtol(3).  It
> is only allowed to.  Should we not allow them to do so?

Of course the standard should allow suboptimal implementations. However, 
I’m not sure what the point of the question is. The “errno = EINVAL 
first thing” comment says that removing ‘restrict’ obliges the 
implementation to support obviously-bogus calls like strtol(&errno, 
...), which might make the implementation less efficient. I don’t see 
how the question is relevant to that comment.



> Let's take a simpler one: rename(2).  Is it allowed to receive &errno?
> Hopefully not.

I agree with that hope, but the current C standard seems to allow it. I 
think we both agree this is a defect in the standard.



 Why is this change worth
 making? Real-world programs do not make calls like that.
>>>
>>> Because it makes analysis of 'restrict' more consistent.  The obvious
>>> improvement of GCC's analyzer to catch restrict violations will trigger
>>> false positives in normal uses of strtol(3).
>>
>> v0.2 does not support this line of reasoning. On t

How to implement Native TLS for a specific platform?

[Julian Waters via Gcc]

Hi all,

I'm currently trying to implement Native TLS on a platform that gcc uses
emutls for at the moment, but I can't seem to figure out where and how to
implement it. I have a rough idea of the assembly required for TLS on this
platform, but I don't know where to plug it in to the compiler to make it
work. Could someone point me in the right direction for implementing TLS
for a platform that doesn't have it implemented at the moment?

I'm aware that I am being vague as to which platform I want to implement it
for. It's a platform that is likely low priority in the eyes of most gcc
maintainers, so I'm deliberately avoiding mentioning what platform it is so
I don't get crickets for a reply :)

best regards,
Julian

md: define_code_attr / define_mode_attr: Default value?

[Georg-Johann Lay]

Is it possible to specify a default value in
define_code_attr resp. define_mode_attr ?

I had a quick look at read-rtl, and it seem to be not the case.
Or am I missing something?

Johann

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

[Alejandro Colomar via Gcc]

Hi Paul,

On Tue, Jul 09, 2024 at 02:09:24PM GMT, Paul Eggert wrote:
> On 7/8/24 00:52, Alejandro Colomar wrote:
> > a small set of functions
> > accept pointers that alias each other, but one of them is never
> > accessed; in those few cases, restrict was added to the parameters in
> > ISO C, but I claim it would be better removed.
> 
> Are these aliasing pointers the nptr and initial *endptr of strtol?

Yes.

> That is,
> are you saying that last line in the following example, which is currently
> invalid, should become valid and should be implementable as ‘end = s; long l
> = 0;’?

No.  I don't think this is a consequence of the previous statement.

> 
>char *end;
>char *s = (char *) &end;
>*s = '\0';
>long l = strtol (s, &end, 0);
> 
> If so, I fail to see the motivation for the proposed change, as nobody
> writes (or should write) code like that. And if not, evidently I
> misunderstand the proposal.

My proposal is:

 long int
-strtol(const char *restrict nptr, char **restrict endptr, int base);
+strtol(const char *nptr, char **restrict endptr, int base);

My proposal doesn't make valid the example above.  To make that example
valid, you'd need:

long int
strtol(const char *nptr, char **endptr, int base);

Because in the example above, you're aliasing nptr with endptr, not with
*endptr.  Thus, endptr cannot be a restricted pointer for that example
to be valid.

[... snip ...]

I'm not sure I understood that part, but it's probably a consequence of
the misuderstanding from above.  Let's ignore it for now, and please
resend if you think it's still a concern.

> 
> > Maybe I should use abstract names for the objects, to avoid confusing
> > them with the pointer variables that are used to pass them?
> 
> That might help, yes, since v0.2 is unclear on this point.

Ok; will do.

> > this formal
> > definition is quite unreadable, though.  The more I read it, the less
> > sure I am about it.
> 
> Yes, it’s lovely isn’t it? One must understand what the C committee
> intended in order to read and understand that part of the standard.

:-)

> > If L is used to access the value of the object X that it
> > designates, and X is also modified (by any means), then the
> > following requirements apply: T shall not be const-qualified
> >
> > This reads to me as "const variables are not writable when they are
> > accessed via a restricted pointer; casting away is not enough".  Am I
> > reading this correctly?
> 
> In that quoted statement, the restricted pointer is not allowed to be
> pointer-to-const. However, I’m not quite sure what your question means, as
> the phrase “const variables” does not appear in the standard. Perhaps give
> an example to clarify the question?

I should have said

"An object pointed to by a pointer-to-const cannot be written if the
pointer is a restricted one; casting const away is not enough."

Is this interpretation of restrict correct?

> >> an implementation is allowed to set errno = EINVAL first thing, and then
> set
> >> errno to some other nonzero value if it determines that the arguments are
> >> valid. I wouldn't implement strtol that way, but I can see where someone
> >> else might do that.
> >
> > In any case an implementation is not obliged to pessimize strtol(3).  It
> > is only allowed to.  Should we not allow them to do so?
> 
> Of course the standard should allow suboptimal implementations. However, I’m
> not sure what the point of the question is. The “errno = EINVAL first thing”
> comment says that removing ‘restrict’ obliges the implementation to support
> obviously-bogus calls like strtol(&errno, ...), which might make the
> implementation less efficient.

See for example how musl implements strtol(3):

$ grepc strtox src/stdlib/strtol.c
src/stdlib/strtol.c:static unsigned long long strtox(const char *s, char **p, 
int base, unsigned long long lim)
{
FILE f;
sh_fromstring(&f, s);
shlim(&f, 0);
unsigned long long y = __intscan(&f, base, 1, lim);
if (p) {
size_t cnt = shcnt(&f);
*p = (char *)s + cnt;
}
return y;
}

The work is done within __intscan(), which could be prototyped as

hidden unsigned long long
__intscan(FILE *restrict, unsigned, int, unsigned long long);

And now you're able to optimize internally, since thanks to that helper
function you know it doesn't alias errno, regardless of the external
API.


BTW, now I remember that strtol(3) says:

ERRORS
 This function does not modify errno on success.

Which means that setting errno at function start wouldn't make much
sense.  Although there's probably a contrived way of doing it and still
be conformant (plus, I think ISO C doesn't say that about errno).

> I don’t see how the question is relevant to
> that comment.
> 
> 
> > Let's take a simpler one: rename(2).  Is it allowed to receive &errno?
> > Hopefully not.
> 
> I agree with that hope, 

Re: md: define_code_attr / define_mode_attr: Default value?

[Richard Sandiford via Gcc]

Georg-Johann Lay  writes:
> Is it possible to specify a default value in
> define_code_attr resp. define_mode_attr ?
>
> I had a quick look at read-rtl, and it seem to be not the case.

Yeah, that's right.  I'd assumed the attributes would be used
in cases where an active choice has to be made for each code/mode,
with missing codes/modes being a noisy failure.

Adding a default value sounds ok though, and would be consistent
with insn attributes.

Richard


> Or am I missing something?
>
> Johann

Re: [WG14] Request for document number; strtol restrictness

[Alejandro Colomar via Gcc]

Hi Daniel,

On Sun, Jul 07, 2024 at 03:46:48PM GMT, Daniel Plakosh wrote:
> Alex,
> 
> Your document number is below:
> 
> n3294 - strtol(3) et al. shouldn't have a restricted first parameter
> 
> Please return the updated document with this number

Am I allowed to retitle the paper?

  n3294 - [[noalias()]] function attribute as a replacement of restrict

Sorry for any inconveniences.

Thanks,
Alex

> 
> Best regards,
> 
> Dan
> 
> Technical Director - Enabling Mission Capability at Scale
> Principal Member of the Technical Staff
> Software Engineering Institute
> Carnegie Mellon University
> 4500 Fifth Avenue
> Pittsburgh, PA 15213
> WORK: 412-268-7197
> CELL: 412-427-4606
> 
> -Original Message-
> From: Alejandro Colomar  
> Sent: Friday, July 5, 2024 3:42 PM
> To: dplak...@cert.org
> Cc: Martin Uecker ; Jonathan Wakely ; 
> Xi Ruoyao ; Jakub Jelinek ; 
> libc-al...@sourceware.org; gcc@gcc.gnu.org; Paul Eggert ; 
> linux-...@vger.kernel.org; LIU Hao ; Richard Earnshaw 
> ; Sam James 
> Subject: [WG14] Request for document number; strtol restrictness
> 
> Hi,
> 
> I have a paper for removing restrict from the first parameter of
> strtol(3) et al.  The title is
> 
>   strtol(3) et al. should’t have a restricted first parameter.
> 
> If it helps, I already have a draft of the paper, which I attach (both the 
> PDF, and the man(7) source).
> 
> Cheers,
> Alex
> 
> --
> 

-- 



signature.asc
Description: PGP signature

RE: [WG14] Request for document number; strtol restrictness

[Daniel Plakosh]

Alejandro,

Sure please remind me when you submit

Best regards,

Dan

Technical Director - Enabling Mission Capability at Scale
Principal Member of the Technical Staff
Software Engineering Institute
Carnegie Mellon University
4500 Fifth Avenue
Pittsburgh, PA 15213
WORK: 412-268-7197
CELL: 412-427-4606

-Original Message-
From: Alejandro Colomar  
Sent: Tuesday, July 09, 2024 3:00 PM
To: Daniel Plakosh 
Cc: dplak...@cert.org; Martin Uecker ; Jonathan Wakely 
; Xi Ruoyao ; Jakub Jelinek 
; libc-al...@sourceware.org; gcc@gcc.gnu.org; Paul Eggert 
; linux-...@vger.kernel.org; LIU Hao ; 
Richard Earnshaw ; Sam James 
Subject: Re: [WG14] Request for document number; strtol restrictness

Hi Daniel,

On Sun, Jul 07, 2024 at 03:46:48PM GMT, Daniel Plakosh wrote:
> Alex,
> 
> Your document number is below:
> 
> n3294 - strtol(3) et al. shouldn't have a restricted first parameter
> 
> Please return the updated document with this number

Am I allowed to retitle the paper?

  n3294 - [[noalias()]] function attribute as a replacement of restrict

Sorry for any inconveniences.

Thanks,
Alex

> 
> Best regards,
> 
> Dan
> 
> Technical Director - Enabling Mission Capability at Scale Principal 
> Member of the Technical Staff Software Engineering Institute Carnegie 
> Mellon University
> 4500 Fifth Avenue
> Pittsburgh, PA 15213
> WORK: 412-268-7197
> CELL: 412-427-4606
> 
> -Original Message-
> From: Alejandro Colomar 
> Sent: Friday, July 5, 2024 3:42 PM
> To: dplak...@cert.org
> Cc: Martin Uecker ; Jonathan Wakely 
> ; Xi Ruoyao ; Jakub Jelinek 
> ; libc-al...@sourceware.org; gcc@gcc.gnu.org; Paul 
> Eggert ; linux-...@vger.kernel.org; LIU Hao 
> ; Richard Earnshaw ; Sam 
> James 
> Subject: [WG14] Request for document number; strtol restrictness
> 
> Hi,
> 
> I have a paper for removing restrict from the first parameter of
> strtol(3) et al.  The title is
> 
>   strtol(3) et al. should’t have a restricted first parameter.
> 
> If it helps, I already have a draft of the paper, which I attach (both the 
> PDF, and the man(7) source).
> 
> Cheers,
> Alex
> 
> --
> 

--

n3294 - The restrict function attribute as a replacement of the restrict qualifier

[Alejandro Colomar via Gcc]

Here's a proposal for adding a function attribute for replacing
the restrict restrict qualifier.  It's v0.3 of n3294 (now we have a
document number).

I was going to name it [[noalias()]], but I thought that it would be
possible to mark several pointers as possibly referencing the same
object, and then the name [[restrict()]] made more sense.

It's based on a proposal I sent to Martin recently in this discussion.

Do you have any feedback for this?

I've attached the man(7) source and the resulting PDF, and below goes
a plain text rendering (formatting is lost).


Have a lovely night!
Alex

---

N3294 (WG14)Proposal for C2y   N3294 (WG14)

Name
 n3294  - The [[restrict()]] function attribute as a replacement of
 the restrict qualifier

Category
 Feature and deprecation.

Author
 Alejandro  Colomar  Andres;  maintainer  of  the  Linux  man-pages
 project.

   Cc
 GNU C library
 GNU Compiler Collection
 Linux man‐pages
 Paul Eggert
 Xi Ruoyao
 Jakub Jelinek
 Martin Uecker
 LIU Hao
 Jonathan Wakely
 Richard Earnshaw
 Sam James
 Emanuele Torre
 Ben Boeckel
 "Eissfeldt, Heiko"
 David Malcolm

Description
   restrict qualifier
 The  restrict  qualifier is not useful for diagnostics.  Being de‐
 fined in terms of accesses, the API is not enough for a caller  to
 know what the function will do with the objects it receives.

 That is, a caller cannot know if the following call is correct:

void f(const int *restrict a, int **restrict b);

f(a, &a);

 Having  no way to determine if a call will result in Undefined Be‐
 havior makes it a dangerous qualifier.

 The reader might notice that this prototype and call is very simi‐
 lar to the prototype of strtol(3), and the use reminds of a  rela‐
 tively common use of that function.

   Diagnostics
 A good replacement of the restrict qualifier should allow to spec‐
 ify  in  the  API of the following function that it doesn’t accept
 pointers that alias.

void
replace(const T *restrict new, T **restrict ls, size_t pos)
{
 memcpy(ls[pos], new, sizeof(T));
}

 This proposal suggests the following:

[[restrict(1)]] [[restrict(2)]]
void
replace(const T *restrict new, T **restrict ls, size_t pos);

replace(arr[3], arr, 2);  // UB; can be diagnosed

   Qualifiers
 It is also unfortunate that restrict  is  a  qualifier,  since  it
 doesn’t  follow  the  rules  that  apply  to all other qualifiers.
 While it is discarded easily, its  semantics  make  it  as  if  it
 couldn’t be discarded.

   Function attribute
 The purpose of restrict is to

 •  Allow functions to optimize based on the knowledge that certain
objects are not accessed by any other object in the same scope;
usually a function boundary, which is the most opaque boundary,
and where this information is not otherwise available.

 •  Diagnose  calls  that  would result in Undefined Behavior under
this memory model.

 Qualifiers don’t seem to be good for  carrying  this  information,
 but  function attributes are precisely for adding information that
 cannot be expressed by just using the type system.

 An attribute would need to be more strict than the restrict quali‐
 fier to allow diagnosing non‐trivial cases, such as the call shown
 above.

 A caller only knows what the callee receives,  not  what  it  does
 with  it.  Thus, for diagnostics to work, the semantics of a func‐
 tion attribute should be specified in terms of what a function  is
 allowed to receive.

   [[restrict]]
 The  [[restrict]] function attribute specifies that the pointer to
 which it applies is the only reference  to  the  array  object  to
 which  it  points (except that a pointer to one past the last ele‐
 ment may overlap another object).

 If the number of elements is specified with array  notation  or  a
 compiler‐specific  attribute, the array object to be considered is
 a subobject of the original array object, which is limited by  the
 number of elementsspecified in the function prototype.

 For the following prototype:

[[restrict(1)]] [[restrict(2)]]
void add_inplace(size_t n, int a[n], const int b[n]);

 In  the following calls, the caller is able to determine with cer‐
 tainty if the behavior is defined or undefined:

char  a[100] = ...;
char  b[50] = ...;

add_inplace(50, a, a + 50);  // Ok
add_inplace(50, a, b);   // Ok
add_inplace(50, a, a);   // UB

 In the first of the three calls, the parameters don’t alias inside
 the function, since the subobjects of 50 elements do  not  overlap
 each  other,  

Sourceware Open Office, Friday 16:00 UTC

[Mark Wielaard]

Friday July 12, 16:00 UTC
https://bbb.sfconservancy.org/b/mar-aom-dmo-fko
Using #overseers on irc.libera.chat as backup.

To get the right time in your local timezone:
$ date -d "Fri Jul 12 16:00 UTC 2024"

Sourceware relies on cooperation among a broad diversity of core
toolchain and developer tool projects, hackers, organizations, ideas,
and communication styles. The monthly Sourceware Open Office meetings
are one way of coming together as a community and discuss our shared
development infrastructure.

- Discussion topics:

  - Sourceware @ Conservancy - Year One
https://inbox.sourceware.org/20240529190215.ga26...@gnu.wildebeest.org/
It was a busy year and we would like to give an overview of
various topics. Communications, New and updated services, Security,
New and upgraded hardware, Finances and Next year plans

  - https://sourceware.org/sourceware-security-vision.html
An update on the plans and funding story.

  - How do we get consensus on and integrate alternative Core
Toolchain Infrastructure ideas for different funding models,
governance, cyber security and service deployments to ensure that
everyone involved is confident our infrastructure plans work out
well for the whole community.

We used to have both a BBB meeting room and an irc channel
discussion. But that became a little confusing. So for some previous
meetings we used irc exclusively. But this time we'll try to use the
BBB meeting room exclusively.

https://bbb.sfconservancy.org/b/mar-aom-dmo-fko

Re: Bad interaction between gcc and glibc's handling of GNU extension [GCC PR 115724]

[Alejandro Colomar via Gcc]

Hi Mark,

David Malcolm  wrote:
> On Tue, 2024-07-02 at 22:39 +0200, Mark Wielaard wrote:
> > Is there an "optimal" optimization level for -fanalyzer (like having
> > -Og for debugging)?
>
> There isn't, sorry.

What I do is compile several times in a loop, with all optimization
levels, to maximize diagnostics.

$(_REALNAME): %.so.$(DISTVERSION): $(TU_h) $(TU_c) $(MK) $(LIB_pc) | $$(@D)/
$(info  $(INFO_)LD  $@)
for opt in g 0 1 2 s 3 fast; do \
$(LD) $(LDFLAGS) -O$$opt -o $*.O$$opt.so.$(DISTVERSION) $(TU_c) 
$(LDLIBS); \
done
$(LD) $(LDFLAGS) -o $@  $(TU_c) 
$(LDLIBS)



The shell is

SHELL   := bash
.SHELLFLAGS := -Eeuo pipefail -c

so it aborts at the first error, and I don't see repeated errors.  It
slows down compilation (since I compile x8 times), but I don't care too
much about it.

Cheers,
Alex

-- 



signature.asc
Description: PGP signature