[LLVMdev] [cfe-dev] RFC: Adding attribute(nonnull) to things in libc++
Marshall Clow
mclow.lists at gmail.com
Tue Jun 2 07:08:15 PDT 2015
On Tue, Jun 2, 2015 at 2:12 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> 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.
>
Heh. There are no "invalid implementations" of undefined behavior.
The reason I proposed this change was to allow UBSAN to detect undefined
behavior, and report it to users - rather than having their code
(potentially) fail in hard-to-diagnose ways when they change *something*
(refactor code, change compilers, change optimization level, etc).
-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150602/c16804c2/attachment.html>
More information about the llvm-dev
mailing list