On 9/8/19 1:58 PM, Bruno Haible wrote:
Well, then we need variants of the *printf functions that return an 'ssize_t'
instead of an 'int'.
Do you happen to know the opinion of the glibc people on this topic?
Sorry, no. I imagine it's come up.
I would suggest ptrdiff_t rather than ssize_t, as t
Paul Eggert wrote:
> The GNU coding standards say to avoid arbitrary limits, and
> on 64-bit platforms we should avoid arbitrary 32-bit limits on the lengths of
> strings.
Well, then we need variants of the *printf functions that return an 'ssize_t'
instead of an 'int'.
Do you happen to know th
On 9/8/19 10:08 AM, Bruno Haible wrote:
What do you mean by "asprintf mishandles large buffers"? The fact that an error
occurs if the result is longer than INT_MAX characters? Really, we have data
larger than 2 GB in many places, but *strings* larger than 2 GB?
Sure, in Emacs:
(length (make-st
On Sun, Sep 8, 2019 at 10:08 AM Bruno Haible wrote:
> So, what we would need is are functions
>
>char * substring (const char *string, size_t length);
>char * concatenated_string2 (const char *string1, size_t length1,
> const char *string2, size_t length2);
Jonas Termansen wrote:
> > Buffer allocation and string production
> > should not be decoupled as it leads to bugs. (Modern languages, such as
> > the one I develop at work, does simply not have these problems.) In C,
> > strdup should be used instead of strlen+malloc+strcpy/memcpy because
> > it's
