Re: Handling C2Y zero-length operations on null pointers

[Chris Bazley via Gcc]

Thank you, Alex.

I agree this was a mistake.

>From experience, there is only one robust interface design when it comes to 
>null pointer arguments: either a function handles them, or it doesn't. Whether 
>or not it handles them should have nothing to do with the value of other 
>parameters. This is also how Python's type system works.

I have no objection to the long-established (if it ain't broken, don't fix it) 
memcpy interface being upgraded to handle null pointers. The cost in CPU cycles 
and code size is probably negligible.

What I *do* object to is a halfway house solution where memcpy only handles 
null pointers contingent on the value of some other parameter. This is hard to 
document, hard to teach static analysis tools, and hard to verify when reading 
calling code.

I do not think it serves anyone.

Best regards,
Chris

From: Alejandro Colomar
Sent: Sunday, December 01, 2024 17:24
To: qing.z...@oracle.com
Cc: f...@deneb.enyo.de; gcc@gcc.gnu.org; ja...@redhat.com; josmy...@redhat.com; 
libc-al...@sourceware.org; uec...@tugraz.at; Chris Bazley
Subject: Re: Handling C2Y zero-length operations on null pointers


Hi,

I had a discussion about this with another WG14 member when this was
voted in.  We both voted against, because this is nefarious for static
analysis.

However, I think this can be though to resemble how 'const' works in the
standard:

    const char cbuf[10];

    memcpy((char *)cbuf, "", 0);

The code above is legal even if it is passing a const pointer where a
non-const one is expected.  This is because memcpy(3) will not write to
it.

Nevertheless, if one does

    memcpy(NULL, "", 0);

without a cast, the compiler will still diagnose.  This is important,
because if we would remove the diagnostics, it would be a footgun.

Similarly, we should allow null pointers (just like const pointers), in
the sense that there's no Undefined Behavior.  BUT there should be a
diagnostic.  Passing NULL is bad, and if one project wants to pass it,
it should do so with whatever compiler shenanigans to disable the
diagnostic (a cast, or a pragma, or whatever, not my problem).  In my
code, I want to see a diagnostic if I pass NULL to it, because in my
dialect (and in every C language before C2y), a null pointer is an
invalid pointer, and that distinction makes the code more robust.

I would either transform [[gnu::nonnull]] to be only about diagnostics
and not optimizations, or maybe add a _Optional qualifier that would
be used for this.

TL;DR:  Removing UB is nice, but removing diagnostics is NOT nice.

Have a lovely day!
Alex

P.S.:  I think it was a big mistake to vote this into C2y, and I voted
against.

-- 

gcc-12-20241212 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20241212 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20241212/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-12 revision 62c1d98b870f84bd511deba7b93e8c49e38f4335

You'll find:

 gcc-12-20241212.tar.xz   Complete GCC

  SHA256=e090628185baa62d03a4b183dbeaccdd7bfc67264a01ed9f52fb057b8faf54c0
  SHA1=f9c3cd758eccb64b9fa012b5cef5a2018807a43c

Diffs from 12-20241205 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Sourceware Open Office Friday, Dec 13, 16:00 UTC

[Mark Wielaard]

Friday Dec 13, 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 Dec 13 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. For other ways to participate see
https://sourceware.org/mission.html#organization

Discussion topics:

Come with any core toolchain and developer tools infrastructure
questions you have and we (hopefully) provide answers.

Adding new patchwork projects? Updating CI jobs, autoregen scripts?
Documentation snapshots? Cyber Security!
https://sourceware.org/cyber-security-faq.html

The forge experiment? We launched https://forge.sourceware.org with a
Forgejo v9 setup. The whole setup/config can be found in
https://sourceware.org/cgit/forge

There is a mailinglist https://sourceware.org/mailman/listinfo/forge
And a wiki page https://gcc.gnu.org/wiki/ForgeExperiment