llvm dev - Jun 2015 - [LLVMdev] [cfe-dev] RFC: Adding attribute(nonnull) to things in libc++

On Mon, Jun 01, 2015 at 09:57:17AM -0700, Reid Kleckner
wrote:
> Why should memset / memcpy be attribute nonnull? Is there standardese that
> supports that?
The generic entry text of the standard section. IMO this is a standard
bug and someone should *please* get it fixed. It is ridiculous that zero
sized operations are considered UB.

Joerg

On Mon, Jun 1, 2015 at 10:35 AM, Joerg Sonnenberger <joerg at
britannica.bec.de
> wrote:
> On Mon, Jun 01, 2015 at 09:57:17AM -0700, Reid Kleckner wrote:
> > Why should memset / memcpy be attribute nonnull? Is there standardese
> that
> > supports that?
>
> The generic entry text of the standard section. IMO this is a standard
> bug and someone should *please* get it fixed. It is ridiculous that zero
> sized operations are considered UB.
>
That would require a change to the C standard, and, as far as I know, there
are no current plans to issue a revised C standard.

I *suppose* that we could change it in the C++ standard, but I doubt that
there would be any support on the committee for making std::memcpy
different from ::memcpy.

-- Marshall

P.S.   recent gcc (at least 4.8.x and later) make optimizations based on
this UB (i.e, if you pass a pointer to memcpy, then it can't be NULL).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150601/e42de28a/attachment.html>

On Mon, Jun 01, 2015 at 10:52:20AM -0700, Marshall Clow
wrote:
> On Mon, Jun 1, 2015 at 10:35 AM, Joerg Sonnenberger <joerg at
britannica.bec.de
> > wrote:
> 
> > On Mon, Jun 01, 2015 at 09:57:17AM -0700, Reid Kleckner wrote:
> > > Why should memset / memcpy be attribute nonnull? Is there
standardese
> > that
> > > supports that?
> >
> > The generic entry text of the standard section. IMO this is a standard
> > bug and someone should *please* get it fixed. It is ridiculous that
zero
> > sized operations are considered UB.
> >
> 
> That would require a change to the C standard, and, as far as I know, there
> are no current plans to issue a revised C standard.
Well, a good start would be to get a position on whether this
interpretation is intentional. Especially given GCC's aggressive
exploitation. It doesn't make sense to me as there doesn't seem to be a
way that "if len is 0, the pointer must be not-null" can improve an
implementation on any system where memory operations can trap.

Joerg

On Mon, Jun 01, 2015 at 10:52:20AM -0700, Marshall Clow
wrote:
> P.S.   recent gcc (at least 4.8.x and later) make optimizations based on
> this UB (i.e, if you pass a pointer to memcpy, then it can't be NULL).
BTW, this seems to be more an issue with glibc adding the tagging and
not behavior of GCC itself.

Joerg

On 1 Jun 2015, at 18:52, Marshall Clow <mclow.lists at gmail.com>
wrote:
> 
>> The generic entry text of the standard section. IMO this is a standard
>> bug and someone should *please* get it fixed. It is ridiculous that
zero
>> sized operations are considered UB.
> 
> That would require a change to the C standard, and, as far as I know, there
are no current plans to issue a revised C standard.
Not necessarily.  Other standards, such as POSIX, are free to define behaviour
that is undefined or implementation defined in C.  POSIX mandates that a char is
exactly 8 bits, for example, which is IB in C.  The goal of UB is to give
freedom to implementors.  Saying that NULL arguments to memcpy are UB does not
mean that we are compelled to disallow them, it just means that:

- We don’t have to accept them.
- We don’t have to be consistent in whether we accept or reject them.
- We can choose to do whatever makes implementation easiest.

If the easiest thing is to permit them as long as the length is zero (it seems
to be), then that’s a perfectly valid implementation of undefined behaviour.

It is also undefined behaviour whether pointer comparisons between different
objects are stable, but for the most part they are (and a lot of code would
break if they weren’t), because implementers have decided that this is the
easiest implementation of this particular bit of UB.

David