Re: scm_to_locale_stringbuf

[Ludovic Courtès]

Hi,

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.

Thanks,
Ludo'.