[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)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]