[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