On Mon, May 11, 2020 at 11:24 AM Linus Torvalds <torva...@linux-foundation.org> wrote: > > On Mon, May 11, 2020 at 11:12 AM Linus Torvalds > <torva...@linux-foundation.org> wrote: > > > > Would using "__builtin_choose_expr()" be able to avoid this whole issue? > > We actually have a fair amount of "pick expression based on size", so > with a few helper macros we could make the code look better than the > case statements too. > > Something (ENTIRELY UNTESTED!) like the attached patch, perhaps? > > NOTE! I only converted one single use to that "pick_size_xyz()" model. > If this actually works for clang too, we could do the others. > > I guess I should just test it, since I have that clang tree.
Interesting approach. Researching __builtin_choose_expr, it looks like it was cited as prior art for C11's _Generic keyword. http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1404.htm I'm kind of tempted now to play with _Generic and see if that makes a difference, though I'm not hopeful. Without checking, I don't know if that will produce warnings with `-std=gnu89`. ... I'm playing around with _Generic now to see if that's a possible solution, but it looks like it can't be used for selecting inline asm constraint strings. But maybe there's another way to use _Generic here. TODO: more testing. I don't quite understand the use of GNU C statement expressions in pick_type_statement, though I'm guessing the return value is important somewhere. Maybe just looking at the preprocessed source would make it clearer. > "why do we cast to unsigned long and then to char, > when we just checked that the size of the type is 1"? Deja vu. I don't remember who I discussed that with, maybe Arnd, but that was something else I had asked at some point. I must have forgotten to look into it more before sending the patch. Can likely drop that at least. -- Thanks, ~Nick Desaulniers
