On Tue, Sep 15, 2015 at 6:45 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
>
> Linus, This patch changes a lot of u32s into bools in structures.
> What's your take on that?
So in general, I'd tend to prefer "bool" to be used primarily as a
return value for functions, but I have to say, in the case of
something that is explicitly called "debugfs_create_bool()" it kind of
makes sense to actually take a bool pointer.
In structures, it depends a bit on usage. If the intent is to pack
things better, I tend to prefer using "char" etc that is explicitly a
byte. Or just use explicit bits in an "unsigned int flags" or
something. Because while "bool" is _typically_ one byte, but it's very
very explicitly documented to not be guaranteed that way, and there
are legacy models where "bool" ends up being "int".
But in this case, the use of "bool" is not about packing or anything
like that, it is more about the logical data type for
"debugfs_create_bool()", and so I don't mind "bool" in this context
even in structures.
But exactly because of the whole ambiguoity about "bool", what I do
*not* want to see in any way is "bool" in structures that are exported
to user space. That's when we want primarily those explicitly sized
types like "u32" etc. We should generally try to avoid even things
like "int" in those kinds of structures, and bool is even _less_ well
defined than "int" is.
But that user interface issue doesn't seem to be the case here, an I
can't say that I mind the patch. It looks fairly sane.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>