[PATCH] D18876: NFC: unify clang / LLVM atomic ordering

[JF Bastien via cfe-commits]

jfb added a comment.

In http://reviews.llvm.org/D18876#403119, @jyknight wrote:

> In http://reviews.llvm.org/D18876#402855, @jfb wrote:
>
> > In http://reviews.llvm.org/D18876#399934, @jyknight wrote:
> >
> > > The large amount of casting to/from integers for AtomicOrderingCABI makes me think that it probably ought not actually be converted to an enum class after all.
> >
> >
> > Untrusted user input with enums is a problem: you have to range-check before casting the int to the enum, with or without enum class, otherwise out-of-range is UB. I like it being explicit, but yeah what I had was wordy so I factored out the check.
> >
> > Casting *out* of the enum to generate constants is also wordy, but I think that's also fine. We could add a version of `ConstantInt` which takes in `is_integral_or_enum` but that seems like a lot of work for little typing? I'm happy to do that if you think it's worthwhile.
>
>
> Well, my suggestion had been to just leave it as a non-enum-class, like it was before -- with no casts to or from the enum type. I think the code as it was before was actually safe, too, wasn't it?
>
> I'm just not really sure using strong enums for the CABI type is really buying much, since the basically only point of the C ABI kind is to use it as an integer. Essentially every uses of it will be converting to/from integers, won't it?


Yup the previous code was correct because it didn't create an enum from an untrusted int and then use it, it always carried the int around and relied on the known-good enum to convert to int when needed.

> I don't really feel strongly though, so if you want to go ahead, I'm okay with that.


Yeah maybe it's a personal preference, but IMO the explicitness makes it harder to mess up :-)


http://reviews.llvm.org/D18876