<feed xmlns='http://www.w3.org/2005/Atom'>
<title>delta/libgit2.git/tests/core/zstream.c, branch ethomson/codespaces</title>
<subtitle>github.com: libgit2/libgit2.git
</subtitle>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/'/>
<entry>
<title>str: introduce `git_str` for internal, `git_buf` is external</title>
<updated>2021-10-17T13:49:01+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2021-09-07T21:53:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=f0e693b18afbe1de37d7da5b5a8967b6c87d8e53'/>
<id>f0e693b18afbe1de37d7da5b5a8967b6c87d8e53</id>
<content type='text'>
libgit2 has two distinct requirements that were previously solved by
`git_buf`.  We require:

1. A general purpose string class that provides a number of utility APIs
   for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
   can take ownership of.

By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.

Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class.  The name also
is an homage to Junio Hamano ("gitstr").

The public API remains `git_buf`, and has a much smaller footprint.  It
is generally only used as an "out" param with strict requirements that
follow the documentation.  (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)

Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
libgit2 has two distinct requirements that were previously solved by
`git_buf`.  We require:

1. A general purpose string class that provides a number of utility APIs
   for manipulating data (eg, concatenating, truncating, etc).
2. A structure that we can use to return strings to callers that they
   can take ownership of.

By using a single class (`git_buf`) for both of these purposes, we have
confused the API to the point that refactorings are difficult and
reasoning about correctness is also difficult.

Move the utility class `git_buf` to be called `git_str`: this represents
its general purpose, as an internal string buffer class.  The name also
is an homage to Junio Hamano ("gitstr").

The public API remains `git_buf`, and has a much smaller footprint.  It
is generally only used as an "out" param with strict requirements that
follow the documentation.  (Exceptions exist for some legacy APIs to
avoid breaking callers unnecessarily.)

Utility functions exist to convert a user-specified `git_buf` to a
`git_str` so that we can call internal functions, then converting it
back again.
</pre>
</div>
</content>
</entry>
<entry>
<title>clar: include the function name</title>
<updated>2020-06-05T07:49:07+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2020-06-05T07:42:38+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=cad7a1bad40c302fef02306708f6ce6279680cb4'/>
<id>cad7a1bad40c302fef02306708f6ce6279680cb4</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>test: cast to a char the zstream test</title>
<updated>2019-01-25T22:47:35+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2019-01-20T23:53:33+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=3fba5891ef96af7c25ab333759f8d518fd22d590'/>
<id>3fba5891ef96af7c25ab333759f8d518fd22d590</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Convert usage of `git_buf_free` to new `git_buf_dispose`</title>
<updated>2018-06-10T17:34:37+00:00</updated>
<author>
<name>Patrick Steinhardt</name>
<email>ps@pks.im</email>
</author>
<published>2018-02-08T11:14:48+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=ecf4f33a4e327a91496f72816f9f02d923e5af05'/>
<id>ecf4f33a4e327a91496f72816f9f02d923e5af05</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>zstream: fail when asked to inflate garbage</title>
<updated>2016-05-26T18:01:04+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2015-07-09T23:36:53+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=b8dc2fdb92c350b786fe4cb27e9b841b794c1e86'/>
<id>b8dc2fdb92c350b786fe4cb27e9b841b794c1e86</id>
<content type='text'>
When we are provided some input buffer (with a length) to inflate,
and it contains more data than simply the deflated data, fail.
zlib will helpfully tell us when it is done reading (via Z_STREAM_END),
so if there is data leftover in the input buffer, fail lest we
continually try to inflate it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we are provided some input buffer (with a length) to inflate,
and it contains more data than simply the deflated data, fail.
zlib will helpfully tell us when it is done reading (via Z_STREAM_END),
so if there is data leftover in the input buffer, fail lest we
continually try to inflate it.
</pre>
</div>
</content>
</entry>
<entry>
<title>zstream: offer inflating, `git_zstream_inflatebuf`</title>
<updated>2016-05-26T18:01:03+00:00</updated>
<author>
<name>Edward Thomson</name>
<email>ethomson@edwardthomson.com</email>
</author>
<published>2015-06-17T15:07:34+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=b88f1713d01e5cca5a296d564ae094dd8bc6a1f2'/>
<id>b88f1713d01e5cca5a296d564ae094dd8bc6a1f2</id>
<content type='text'>
Introduce `git_zstream_inflatebuf` for simple uses.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce `git_zstream_inflatebuf` for simple uses.
</pre>
</div>
</content>
</entry>
<entry>
<title>Expand zstream tests and fix off-by-one error</title>
<updated>2014-01-30T18:00:00+00:00</updated>
<author>
<name>Russell Belfer</name>
<email>rb@github.com</email>
</author>
<published>2014-01-30T17:59:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=8606f33beadf5df48b36a64359c99d50aeb0f496'/>
<id>8606f33beadf5df48b36a64359c99d50aeb0f496</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Reorganize zstream API and fix wrap problems</title>
<updated>2014-01-30T17:59:59+00:00</updated>
<author>
<name>Russell Belfer</name>
<email>rb@github.com</email>
</author>
<published>2014-01-29T23:02:35+00:00</published>
<link rel='alternate' type='text/html' href='http://git.baserock.org/cgit/delta/libgit2.git/commit/?id=d9b04d78a396f771eada206b726ad6e8259a19b8'/>
<id>d9b04d78a396f771eada206b726ad6e8259a19b8</id>
<content type='text'>
There were some confusing issues mixing up the number of bytes
written to the zstream output buffer with the number of bytes
consumed from the zstream input.  This reorganizes the zstream
API and makes it easier to deflate an arbitrarily large input
while still using a fixed size output.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There were some confusing issues mixing up the number of bytes
written to the zstream output buffer with the number of bytes
consumed from the zstream input.  This reorganizes the zstream
API and makes it easier to deflate an arbitrarily large input
while still using a fixed size output.
</pre>
</div>
</content>
</entry>
</feed>
