l...@gnu.org (Ludovic Courtès) writes:
> 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
Hi,
Neil Jerram 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 call
Hi Mike,
Thanks for explaining...
Mike Gran writes:
> Right now, the internal coding of strings is an unspecified 8-bit
> encoding, and is assumed to be compatible with the locale in which it
> is being run.
>
> So if I have a guile string with some 8-bit character that is between
> 128 and 255
> From: Neil Jerram n...@ossau.uklinux.net
> I'm afraid I don't understand the problem, on two counts.
>
> 1. The doc (in the manual) says that scm_to_locale_stringbuf doesn't
> add a terminating \0. So presumably any \0s present must be padding.
>
> 2. The doc also says that if scm_to_locale_s
Mike Gran writes:
> Hi,
>
> The description for scm_to_locale_stringbuf doesn't specify
> what happens when the final multibyte character doesn't fit
> in the provided string buffer.
>
> size_t scm_to_locale_stringbuf (SCM str, char *buf, size_t max_len)
>
> Say the locale is UTF-8, and the last
