[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_to_locale_stringbuf
From: |
Ludovic Courtès |
Subject: |
Re: scm_to_locale_stringbuf |
Date: |
Thu, 05 Feb 2009 23:26:26 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
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'.