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: Pierre Habouzit <hidden>
Date: 2016-06-15 22:43:33

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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help