This is an archive of the discontinued LLVM Phabricator instance.

NFC: unify clang / LLVM atomic ordering
ClosedPublic

Authored by jfb on Apr 7 2016, 3:47 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

jfb updated this revision to Diff 52966.Apr 7 2016, 3:47 PM
jfb retitled this revision from to NFC: unify clang / LLVM atomic ordering.
jfb updated this object.
jfb added reviewers: jyknight, reames.
jfb added a subscriber: cfe-commits.
jyknight edited edge metadata.Apr 13 2016, 9:20 AM

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.

jfb updated this revision to Diff 53931.Apr 15 2016, 12:21 PM
jfb edited edge metadata.
  • Use validity checks, reduce casting while still avoiding UB on out-of-range enum values.
jfb added a comment.Apr 15 2016, 1:07 PM

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.

In D18876#402855, @jfb 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?

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

jfb added a comment.Apr 15 2016, 4:47 PM
In D18876#402855, @jfb 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 :-)

This revision was automatically updated to reflect the committed changes.