Date: Thu, 5 Feb 2026 01:14:56 +0100
Hi Henry,
On 2026-02-04T17:47:51-0600, Henry Miller wrote:
>
>
> On Wed, Feb 4, 2026, at 16:53, Alejandro Colomar via Std-Proposals wrote:
> > Hi,
> >
> > On 2026-02-04T22:41:29+0000, Ell via Std-Proposals wrote:
> >> On Wednesday, February 4th, 2026 at 10:23 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >>
>
> >> > How would that internal string get embedded NUL characters?
> >> >
> >> > So I don't see how having the size be correct for `strlen` instead of
> >> > respecting the size it is given is a problem here.
> >>
> >>
> >> The problem isn't not respecting the size, it's deciding what the
> >> implications of saying that cstring_view can't have embedded nulls are
> >> in practice.
> >
> > Reminder: ISO C defines what is a string, and it disallows embedded
> > nulls.
>
> That isn't quite right - the string itself of course cannot have
> embedded nulls. However there often are bytes after the first null
> that are illegal to read (though I doubt the standard has this
> wording) but legal to write.
You're talking about a buffer that contains a string. What goes after
the string is not part of it. The string ends in the first null byte.
> Functions like strncpy will often write to those extra bytes and
> change the length of the string.
strncpy(3) is not a string API. It is a function to deal with
fixed-witdh character arrays, such as those in utmp(5) members, or in
some other data formats such as tar(1).
The name might confuse programmers to think it's a string API, but
that's a historical accident.
strncpy(3) does NOT produce a string.
Have a lovely night!
Alex
> It is important that c/zstring_view have a length that indicates how many bytes total can be written to, perhaps with a note that all bytes after the first null are unspecified.
>
> Thus the open question is should c/zstring_view have two length functions, one that gives the length of the string, and one that gives the length of the underling buffer? I'm not a C programmer so I will just say we need to ask them what is useful.
On 2026-02-04T17:47:51-0600, Henry Miller wrote:
>
>
> On Wed, Feb 4, 2026, at 16:53, Alejandro Colomar via Std-Proposals wrote:
> > Hi,
> >
> > On 2026-02-04T22:41:29+0000, Ell via Std-Proposals wrote:
> >> On Wednesday, February 4th, 2026 at 10:23 PM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >>
>
> >> > How would that internal string get embedded NUL characters?
> >> >
> >> > So I don't see how having the size be correct for `strlen` instead of
> >> > respecting the size it is given is a problem here.
> >>
> >>
> >> The problem isn't not respecting the size, it's deciding what the
> >> implications of saying that cstring_view can't have embedded nulls are
> >> in practice.
> >
> > Reminder: ISO C defines what is a string, and it disallows embedded
> > nulls.
>
> That isn't quite right - the string itself of course cannot have
> embedded nulls. However there often are bytes after the first null
> that are illegal to read (though I doubt the standard has this
> wording) but legal to write.
You're talking about a buffer that contains a string. What goes after
the string is not part of it. The string ends in the first null byte.
> Functions like strncpy will often write to those extra bytes and
> change the length of the string.
strncpy(3) is not a string API. It is a function to deal with
fixed-witdh character arrays, such as those in utmp(5) members, or in
some other data formats such as tar(1).
The name might confuse programmers to think it's a string API, but
that's a historical accident.
strncpy(3) does NOT produce a string.
Have a lovely night!
Alex
> It is important that c/zstring_view have a length that indicates how many bytes total can be written to, perhaps with a note that all bytes after the first null are unspecified.
>
> Thus the open question is should c/zstring_view have two length functions, one that gives the length of the string, and one that gives the length of the underling buffer? I'm not a C programmer so I will just say we need to ask them what is useful.
-- <https://www.alejandro-colomar.es>
Received on 2026-02-05 00:15:06