[llvm-dev] Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")

Chandler Carruth via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 25 23:00:38 PST 2016


On Thu, Feb 25, 2016 at 10:40 PM Justin Bogner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Sanjoy Das via llvm-dev <llvm-dev at lists.llvm.org> writes:
> > On Thu, Feb 25, 2016 at 6:35 PM, Duncan P. N. Exon Smith
> > <dexonsmith at apple.com> wrote:
> >>>  // In C
> >>>  void foo() {
> >>>    int c;
> >>>    if (c) print("X");
> >>>    escape(&c);  // escape is an empty function
> >>>  }
> >>>
> >>> which I think is not UB in C (is it?), but will boil down to the kind
> >>> of IR above.
> >>
> >> I'm pretty sure the `if (c)` is UB because it's branching on an
> uninitialized
> >> value, which could have a trap representation.
> >
> > I am *way* out of my depth here, but what if 'c' was an 'unsigned
> > char' (and not an 'int')?  Wouldn't that prevent UB, since it is
> > escaped (cannot be a register variable), and is an 'unsigned char'
> > (doesn't have a trap representation)?
>
> Nah, C's pretty explicit that using uninitialized locals is undefined
> behaviour, regardless of type. From C11 J.2:
>
>   The value of an object with automatic storage duration is used while
>   it is indeterminate (6.2.4, 6.7.9, 6.8).
>
> It's also stated in 6.2.4 that "the initial value of the object is
> indeterminate."
>

Reading an indeterminate value isn't UB in C. Even branching on it isn't.


> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160226/803efb77/attachment.html>


More information about the llvm-dev mailing list