Hi, Neil Jerram <n...@ossau.uklinux.net> 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'.
