Richard Sandiford writes:
> Sam James writes:
>> Richard Sandiford writes:
>>
>>> Sam James via Gcc writes:
Hi!
This comes up in #gcc on IRC every so often, so finally
writing an RFC.
>>> [...]
TL;DR: The proposal is:
1) MAINTAINERS should list a field c
Hi Paul,
On Sun, Jul 07, 2024 at 07:30:43PM GMT, Paul Eggert wrote:
> On 7/7/24 14:42, Alejandro Colomar wrote:
> > On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote:
> > > Also, “global variables” is not
> > > right here. The C standard allows strtol, for example, to read and write
> > >
Snapshot gcc-15-20240707 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/15-20240707/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 15 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Sam James writes:
> Richard Sandiford writes:
>
>> Sam James via Gcc writes:
>>> Hi!
>>>
>>> This comes up in #gcc on IRC every so often, so finally
>>> writing an RFC.
>>>
>> [...]
>>> TL;DR: The proposal is:
>>>
>>> 1) MAINTAINERS should list a field containing either the gcc.gnu.org
>>> email
On 7/7/24 14:42, Alejandro Colomar wrote:
On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote:
Also, “global variables” is not
right here. The C standard allows strtol, for example, to read and write an
internal static cache. (Yes, that would be weird, but it’s allowed.)
That's not part
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
Best regards,
Dan
Technical Director - Enabling Mission Capability at Scale
Principal Member of the Technical Staff
Software Engineerin
Hi Martin,
On Sun, Jul 07, 2024 at 02:21:17PM GMT, Martin Uecker wrote:
> Am Sonntag, dem 07.07.2024 um 13:07 +0200 schrieb Alejandro Colomar via Gcc:
> > Which is actually having perfect information, regardless of 'restrict'
> > on nptr. :-)
>
> Yes, but my point is that even with "restrict" a
Hi Paul,
On Sun, Jul 07, 2024 at 12:42:51PM GMT, Paul Eggert wrote:
> On 7/7/24 03:58, Alejandro Colomar wrote:
>
> > I've incorporated feedback, and here's a new revision, let's call it
> > v0.2, of the draft for a WG14 paper.
> Although I have not followed the email discussion closely, I read v
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
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?
H. I think you're correct. I'll incorpo
On 7/7/24 03:58, Alejandro Colomar wrote:
I've incorporated feedback, and here's a new revision, let's call it
v0.2, of the draft for a WG14 paper.
Although I have not followed the email discussion closely, I read v0.2
and think that as stated there is little chance that its proposal will
be a
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?
You also need to discuss backwards compatibility. Changing
the type of those functions can break valid programs. You would
need
12 matches
Mail list logo
