Simon Josefsson wrote:
> I think this is a useful contribution,
Thanks.
> however I see two deal-breakers
> for having it in gnulib -- both related to use in libraries. I think
> string helpers types/functions like this is useful not only in
> applications but also in libraries. Thus:
>
> 1)
Paul Eggert wrote:
> > I'll add a comment regarding printf with the "%.*s" directive.
>
> That works only if the string lacks NULs
Ouch, indeed.
> and its length fits into int,
> and one must also convert the idx_t length to int (e.g., via a cast
> which I find tricky).
I've now documented
Bruno Haible writes:
> struct
> {
> size_t nbytes;
> char * data;
> }
>
> I propose to add a module that adds such a type, together with elementary
> functions that work on them.
I think this is a useful contribution, however I see two deal-breakers
for having it in gnulib -- both
On 2023-03-25 04:49, Bruno Haible wrote:
I'll add a comment regarding printf with the "%.*s" directive.
That works only if the string lacks NULs and its length fits into int,
and one must also convert the idx_t length to int (e.g., via a cast
which I find tricky). Although these limitations
Hello!
I frequently use ad-hoc code for this, however in library code, in
which xmalloc is not much used.
I learn new gnulib things primarily from the manual. Do you plan to
document it there?
Le vendredi 24 mars 2023 à 22:50 +0100, Bruno Haible a écrit :
> /* Return a copy of string S, as a
Vivien Kraus wrote:
> I frequently use ad-hoc code for this, however in library code, in
> which xmalloc is not much used.
Good point. I'll need to duplicate the interface of the memory
allocating functions: one with 'x', that use xmalloc, and one without
'x', for use in libraries.
> I learn new
Le vendredi 24 mars 2023 à 19:20 -0400, Jeffrey Walton a écrit :
> The type that I'm proposing does not have NUL byte appended to the
> data
> > always and automatically, because I think it is more important to
> > have a
> > string_desc_substring function that does not cause memory
> >
Paul Eggert wrote:
> >struct
> >{
> > size_t nbytes;
> > char * data;
> >}
>
> One minor comment: use idx_t instead of size_t, for the usual reasons.
Right, done. Thanks for the reminder.
> Also it might be a bit more efficient to put the pointer first.
On some CPUs
Jeffrey Walton wrote:
> A natural thing to want
> to do is print a string, and C-based routines usually expect a
> terminating NULL.
I'll add a comment regarding printf with the "%.*s" directive.
> Also, if you initialize the struct, then the allocated string will
> likely include a terminating
On Fri, Mar 24, 2023 at 5:50 PM Bruno Haible wrote:
>
> In most application areas, it is not a problem if strings cannot contain NUL
> bytes, and thus the C type 'char *' with its NUL terminator is well usable.
>
> In areas where strings with embedded NUL bytes need to be handled, the common
>
On 2023-03-24 14:50, Bruno Haible wrote:
struct
{
size_t nbytes;
char * data;
}
One minor comment: use idx_t instead of size_t, for the usual reasons.
Also it might be a bit more efficient to put the pointer first.
In most application areas, it is not a problem if strings cannot contain NUL
bytes, and thus the C type 'char *' with its NUL terminator is well usable.
In areas where strings with embedded NUL bytes need to be handled, the common
approach is to use a 'char * data' pointer together with a 'size_t
12 matches
Mail list logo
