There are many reasons it might be inconvenient for foo to pass that data to quux. Perhaps it’s actually quux that called foo rather than the other way around (in other words, foo is passing ownership through its return value rather than through a function argument), in which case C makes it easier to return one value than two. Or perhaps there’s just a lot of existing logic that passes owned strings around without an accompanying size parameter, which is perfectly safe to do if you’re not planning to ever mutate them.
Of course you could easily design your codebase to not have that issue, if you’re writing it from scratch. But that’s not the question.
i agree that parts of the code that are not changing the length of the string can use it safely without knowing the buffer size
it's been easy to return a struct by value in c for over 30 years, though in very early versions of c, structs in rvalue context implicitly decayed to pointers, like arrays. it's been efficient for about 20 years
so it's not easier to return one value than two if you've already defined the struct type, which is presumably the case here
there's people who avoid it because they're imitating c code from the 01980s (or, charitably, performance-sensitive c code from the 01990s), or because they're using some horrible abomination like common lisp's cffi, but that's really quite marginal
and even if you didn't originally design your codebase that way, you can certainly fix the design. it'll probably even make it easier to understand and maintain, because you're always passing around a stralloc or whatever, instead of sometimes passing around a stralloc and other times passing around a raw buffer pointer
Your personal coding preferences and discipline will switch the jobs together with you. The new hires on the project you left behind are going to have their own perspective (likely very wrong from your POV) on how things should be done.
If it's an open source project, idiosyncratic code will only increase friction for contribution for little practical gain.
broadly i agree except for your last point. but i am unclear on how this relates to the thread, other than explaining why many projects fail to even approach the quality demonstrated in wellons's blog
Of course you could easily design your codebase to not have that issue, if you’re writing it from scratch. But that’s not the question.