[PATCH] D142388: [clang] Add builtin_nondeterministic_value

Richard Smith - zygoloid via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jun 12 14:09:02 PDT 2023


rsmith added a comment.

In D142388#4414375 <https://reviews.llvm.org/D142388#4414375>, @aaron.ballman wrote:

> In D142388#4412521 <https://reviews.llvm.org/D142388#4412521>, @rsmith wrote:
>
>> I have a concern with the name of this builtin. People are going to assume it produces a nondeterministic value, and use it for seeding random number generators and similar, and will be surprised when the value produced is actually deterministic, and, worse, might leak information on the stack that was left behind by some previous function call. Can we give this a name that doesn't suggest that it produces its value nondeterministically?
>
> That's a fair point; do you have a suggestion for a name? (I had suggested `__builtin_unspecified_value()` but perhaps that is too focused on the term of art.)

If this means exactly what C++ means by "unspecified value" I'm OK with that, but I don't think it does with the current design; `__builtin_???(bool)` can seemingly return `std::bit_cast<bool>('x')`, which is not an unspecified value of type `bool` in C++-land (because it's not a value of type `bool` at all). On that subject: can we restrict this to types where every object representation is valid, and rule out `bool` and (at least some) enumerations, as well as any `_BitInt(N)`s with no unused bits? Either that, or mask off the "bad" bits so that it actually produces valid values? Allowing type arguments for which any use of the builtin is just immediately UB doesn't seem like a good idea.

I don't like `__builtin_undefined_value` because very commonly "undefined" is used to mean something else, in ways that show up in close proximity to this builtin.

`__builtin_arbitrary_value` works a bit better for me, but is still quite wrong / misleading, because the value is *not* arbitrary. With either that or `__builtin_nondeterminstic_value`, I worry that an old and famous crypto bug will be reintroduced:

  int my_random_number = __builtin_nondeterministic_value();
  my_random_number ^= rand();
  my_random_number ^= other_junk;

... where I would expect and //hope// that LLVM will optimize the resulting value of `my_random_number` to 0 by picking the exact right "nondeterminstic" value every time :)

I think `__builtin_any_value` works pretty well, and emphasizes that this can really return any value. I'd also be OK with `__builtin_convenient_value`, to emphasize that the compiler will pick something that's convenient for it, but I prefer `__builtin_any_value`.



================
Comment at: clang/docs/LanguageExtensions.rst:3087
+
+``__builtin_nondeterministic_value`` returns a valid nondeterministic value of the same type as the provided argument.
+
----------------
xbolva00 wrote:
> This text really sells this new builtin as a random value generator..
How about something more like this:

> ``__builtin_any_value`` returns an arbitrary value of the same type as the provided argument.
>
> [...]
>
> **Description**:
>
> Each call to ``__builtin_any_value`` returns an arbitrary value of the type given by the argument. The returned value will be chosen in a way that is convenient for the compiler, and may for example be a value left behind in a register or on the stack from a previous operation, or a value that causes a later calculation to always produce the same result. This function will not necessarily return a meaningful value if there are bit-patterns for the given type that do not correspond to meaningful values.

(I really want this to also not say it will produce a "valid value", because the valid values for a type are not in general known to the frontend. For a pointer, for example, this can return literally any bit pattern, and most of those will not be valid in any meaningful sense.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D142388/new/

https://reviews.llvm.org/D142388



More information about the cfe-commits mailing list