[barcode] Patch to get output in strings

[Cloyce D. Spradling]

On Sun, Nov 11, 2001 at 08:30:14PM +0100, Alessandro Rubini wrote:

: Yes, that's something that was already suggested. I'll look at your patch
: and consider inclusion, but I'll delay it a while.

Thanks.

: > This of course introduces a dependency on snprintf and also on realloc.

: I had to remove one snprintf because one the Unixen people was using
: didn't have it. I'm fairly reluctant to provide a replacement (too
: time required to look for one and integrate in the autoconf mechanism)

IIRC, samba has one that's nicely done.  If it's a desired thing (i.e. would
be used elsewhere if it were present) I'd be happy to integrate it.

: What about a function that uses a caller-provided string? Than it's
: the application's reponsibility to do buffer management.

I thought about that, and that *would* simplify the code in the library
quite a lot.  The reason I didn't do it, though, was because I didn't think
it was reasonable to expect the user to guess at how large a buffer would
be large enough, especially given the consequences should he guess
incorrectly.  I suppose now that we've got machines with megabytes and
megabytes of RAM, allocating a 128kB area to hold the string wouldn't be
*too* wasteful, measured as a percentage of system resources.  But wasting
127kB doesn't seem like a good thing to me.  (Even wasting 3 or 7kB of the
single page that would actually be allocated seems a little wrong. :)

: Otherwise,
: the caller can provide a printf-like callback (using a different
: library call). The internal print-to-provided-buffer would be
: implemented using the print-using-callback implementation.

That's a nifty idea!

I like the callback idea a lot... it'd be pretty easy to handle for the
library part.  Maybe I'll give that a shot later.

--
Cloyce