[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thu, 05 Feb 2009 23:26:26 +0100
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)
Neil Jerram <address@hidden> writes:
> I think the key thing is that scm_to_locale_stringbuf () will return
> 2. This tells the caller that BUF wasn't big enough. Beyond that, we
> shouldn't do something obviously misleading, but I don't think it
> matters very much what we choose to do.
Agreed. The caller is already able to determine that something's wrong
if the return value is larger than MAX_LEN.
> I guess there could be a scenario where the caller has a fixed size
> buffer, and just wants to copy in as much of an arbitrary string as
> will fit, and then use that possibly truncated string somehow.
> Depending on the API that the string is being passed on to, any of the
> following could be most useful:
> - padding the unused bytes of BUF with \0 (or some other value)
> - adding a single \0 (or other value) in the first unused byte
> - returning a pointer (or offset in bytes) to the first unused byte
> - returning the number of characters written.
> Returning both <number of chars written> and <number of bytes used>
> would allow the caller to do any of those efficiently, so perhaps we
> should do that?
I would say returning both "number of bytes needed for the full string"
(as is the case) plus "number of bytes actually written" (which may be
smaller than MAX_LEN in the case of multi-byte encoding). This would be
an addition to the API, IMO, while `scm_to_locale_stringbuf ()' would
keep behaving as described, with the limitations you outline above.