On 06/08/16 02:20, Ingo Molnar wrote: > > Also, unless I'm missing something it's not really 'hard' or dangerous per se > to > do that change for every architecture, just incredibly boring! ;-) > > I'm not sure how much it matters though, given other asymmetries in the > bitops API > signatures - does anyone have any preferences? >
My big concern is doing a change to another architectures which I can't test... and I will have to make assumptions about the properties of asm() in that architecture. Furthermore, if/when other architectures get support for =@cc or an equivalent, they probably want to change their stuff. >> Perhaps I'm wrong, but I'd really like to avoid the upcasting to "int" >> which isn't needed, because in my testing I find that it definitely >> encourages gcc to generate poor code. > > Yeah, absolutely. I hate 'bool' with a vengence but if 'int' generates worse > code > with modern compilers then I'm not going to argue for worse code. Would a > 'char' > return type be very weird? Another reason to not hate on "bool" so much: I have personally gotten bitten a few to many times by programmers who thought returning -1 or 2 for what was normally a 0/1 flag in some kind of exceptional case. If the variable is bool you know that that can't happen. One thing, though: we should NOT use bool as input to a system call, because coming from userspace we cannot enforce the required invariant that bits[7:1] == 0.
