Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Oct 5, 2007, 16:43 UTC
Message-ID: <alpine.LFD.0.999.0710050933330.23684@woody.linux-foundation.org>
In-Reply-To: <20071005162139.GC31413@uranus.ravnborg.org>

On Fri, 5 Oct 2007, Sam Ravnborg wrote:

> 
> Took a short look at strbuf.h after seeing the above code.
> And I was suprised to see that all strbuf users were exposed to
> the strbuf structure.

Well, they *have* to. We want people to declare their strbufs as automatic or static structures, and using a opaque struct pointer is *not* an option (like "FILE" is doing in stdio.h).

> Following patch would at least make sure noone fiddle with strbuf internals.

No, following patch is fundamentally broken - it's not even a good starting point. It's bad, bad, bad.

It's also broken in another way: we want it to be really easy to use strbuf's as normal C strings.

Yes, many (totally idiotic and broken) interfaces think it's so important to "protect" their internal data structures that you have a "string_to_c()" helper function for that. That may be "good abstraction", but it's totally idiotic, because it results in horrible source code!

Tell me which is more readable:

	printf("Hello %s\n", sb->buf);

or

	printf("Hello %s\n", strbuf_to_c(sb));

and I claim that anybody who claims that the latter is "more readable" is full of shit, and has an agenda to push, so it's "more agenda-friendly" rather than readable!

So having "sb->buf" and "sb->len" be visible to users is a *good* thing. Otherwise you end up having to create millions of idiotic small helper functions, rather than just use the standard ones.

			Linus