Thread (3 messages) flat view 3 messages, 3 authors, 2016-06-15
  • (off-list ancestor, not in this archive)
  • Re: strbuf API · Junio C Hamano <hidden> · 2016-06-15
  • Re: strbuf API · Pierre Habouzit <hidden> · 2016-06-15
  • Re: strbuf API · Johannes Schindelin <hidden> · 2016-06-15

Re: strbuf API

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:33

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help