Pierre Habouzit [off-list ref] writes:
On Mon, Sep 03, 2007 at 08:32:16AM +0000, Matthieu Moy wrote:
quoted
...
For example, it would be very tempting to compare files with
"strcmp(buf1, buf2)", but that would just fail silently when the file
contains a '\0' byte.
Indeed, OTHO doing that would be pretty silly, as embending NULs in a
strbuf is wrong, it's a _str_buf, not a random-binary-buffer. It's meant
to make the use of strings easier, not to use as generic purpose byte
buffers. Of course they can, but well, it's not what they are designed
for in the first place.
People, please realize strbuf "API" is not a serious API.
It wasn't even intended to be anything more than just a
quick-and-dirty implementation of fgets that can grow
dynamically. The other callers added by people to have it do
general string manipulations were just bolted-on, not designed.
I haven't taken a serious look at bstring nor any of the
alternatives yet, but defending strbuf as if it was designed to
be a sane API is just silly.
On Mon, Sep 03, 2007 at 09:18:01AM +0000, Junio C Hamano wrote:
Pierre Habouzit [off-list ref] writes:
quoted
On Mon, Sep 03, 2007 at 08:32:16AM +0000, Matthieu Moy wrote:
quoted
...
For example, it would be very tempting to compare files with
"strcmp(buf1, buf2)", but that would just fail silently when the file
contains a '\0' byte.
Indeed, OTHO doing that would be pretty silly, as embending NULs in a
strbuf is wrong, it's a _str_buf, not a random-binary-buffer. It's meant
to make the use of strings easier, not to use as generic purpose byte
buffers. Of course they can, but well, it's not what they are designed
for in the first place.
People, please realize strbuf "API" is not a serious API.
It wasn't even intended to be anything more than just a
quick-and-dirty implementation of fgets that can grow
dynamically. The other callers added by people to have it do
general string manipulations were just bolted-on, not designed.
I haven't taken a serious look at bstring nor any of the
alternatives yet, but defending strbuf as if it was designed to
be a sane API is just silly.
actually I was defending the "enhanced" strbuf API I was proposing
before, sorry if that was unclear.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Hi,
On Mon, 3 Sep 2007, Junio C Hamano wrote:
Pierre Habouzit [off-list ref] writes:
quoted
On Mon, Sep 03, 2007 at 08:32:16AM +0000, Matthieu Moy wrote:
quoted
...
For example, it would be very tempting to compare files with
"strcmp(buf1, buf2)", but that would just fail silently when the file
contains a '\0' byte.
Indeed, OTHO doing that would be pretty silly, as embending NULs in a
strbuf is wrong, it's a _str_buf, not a random-binary-buffer. It's meant
to make the use of strings easier, not to use as generic purpose byte
buffers. Of course they can, but well, it's not what they are designed
for in the first place.
People, please realize strbuf "API" is not a serious API.
It wasn't even intended to be anything more than just a
quick-and-dirty implementation of fgets that can grow
dynamically. The other callers added by people to have it do
general string manipulations were just bolted-on, not designed.
I haven't taken a serious look at bstring nor any of the
alternatives yet, but defending strbuf as if it was designed to
be a sane API is just silly.
Two points:
- it can be turned into an API (pretty easy, really, since it is _really_
small), and
- it is easy to hack on, because it is _not_ a full-blown cover-them-all
library. As such, we can tweak it the way _we_ want. And if that means
that we do not NUL terminate, so be it. And if that means that we turn
it into a rope structure, so be it.
IOW it might be utterly incomplete, but at least it can evolve in a manner
that we like. It does not need to be a *kaboom-here-we-have-a-big-dump*.
I know that we had something like that with LibXDiff. I was not
particularly happy with the process, but it turned out quite well, as
Davide helped us a lot.
But the diff situation is completely different from the string situation:
- we did not have _anything_ in the way of diff generation,
- it is pretty well defined what a diff generation library should do, and
- diff generation is not trivial, and it would have taken us quite a long
time to write it ourselves.
All three points are not true with string manipulation.
But code talks, and as I do not have anything presentable (yet), I'll just
shut up, until I have.
Ciao,
Dscho