Hi Linus, On Mon, Jul 07, 2025 at 03:17:50PM -0700, Linus Torvalds wrote: > On Mon, 7 Jul 2025 at 14:27, Alejandro Colomar <a...@kernel.org> wrote: > > > > If the name is your main concern, we can discuss a more explicit name in > > the kernel. > > So as they say: "There are only two hard problems in computer science: > cache invalidation, naming and off-by-one errors".
Indeed. And we have two of these classes here. :) > And the *worst* model for naming is the "add random characters" (ok, I > still remember when people believed the insane "Hungarian Notation" > BS, *that* particular braindamage seems to thankfully have faded away > and was probably even worse, because it was both pointless, unreadable > _and_ caused long identifiers). To be fair, one letter is enough if you're used to the name. Everything of the form s*printf() people know that the differentiating part is that single letter between 's' and 'p', and a quick look at the function prototype usually explains the rest. More than that, and it's unnecessarily noisy to my taste. But not everyone does string work all the time, so I get why you'd be less prone to liking the name. I won't press for the name. Unless you say anything, my next revision of the series will call it sprintf_end(). > Now, we obviously tend to have the usual bike-shedding discussions > that come from naming, but my *personal* preference is to avoid the > myriad of random "does almost the same thing with different > parameters" by using generics. > > This is actually something that the kernel has done for decades, with > various odd macro games - things like "get_user()" just automatically > doing the RightThing(tm) based on the size of the argument, rather > than having N different versions for different types. In this case, I wouldn't want to go that way and reuse the name snprintf(3), because the kernel implementation of snprintf(3) is non-conforming, and both the standard and the kernel snprintf() have semantics that are importantly different than this API in terms of handling errors. I think reusing the name with slightly different semantics would be prone to bugs. Anyway, sprintf_end() should be clear enough that I don't expect much bikeshedding for the name. Feel free to revisit this in the future and merge names if you don't like it; I won't complain. :) Have a lovely night! Alex P.S.: I'm not able to sign this email. > So we actually have a fair number of "generics" in the kernel, and > while admittedly the header file contortions to implement them can > often be horrendous - the *use* cases tend to be fairly readable. > > It's not just get_user() and friends, it's things like our > type-checking min/max macros etc. Lots of small helpers that > > And while the traditional C model for this is indeed macro games with > sizeof() and other oddities, these days at least we have _Generic() to > help. > > So my personal preference would actually be to not make up new names > at all, but just have the normal names DoTheRightThing(tm) > automatically. > > But honestly, that works best when you have good data structure > abstraction - *not* when you pass just random "char *" pointers > around. It tends to help those kinds of _Generic() users, but even > without the use of _Generic() and friends, it helps static type > checking and makes things much less ambiguous even in general. > > IOW, there's never any question about "is this string the source or > the destination?" or "is this the start or the end of the buffer", if > you just have a struct with clear naming that contains the arguments. > > And while C doesn't have named arguments, it *does* have named > structure initializers, and we use them pretty religiously in the > kernel. Exactly because it helps so much both for readability and for > stability (ie it catches things when you intentionally rename members > because the semantics changed). > > Linus -- <https://www.alejandro-colomar.es/>
