Hi Tiago,

I'd agree that null-terminated strings have been a common source of bugs
and safety issues. My linter yells at me every time I write strlen.

> any interface going forward would be better off not having the assumption
of null terminated

I'd agree and I think my co-authors would too. We touched on this in
section 5 of the paper. The problem is, for the foreseeable future, there
will always be interfaces that take null-terminated strings (at the very
least operating system calls and legacy libraries). As it stands, there is
C++ code doing the very unsafe and bug-prone thing of calling .data() on a
std::string_view and passing that to APIs taking null-terminated C strings.
While I'd agree with the general principle that null terminated strings
shouldn't be used, I do also strongly believe this paper improves the
status quo in cases where they are, for the time being, unavoidable.

Happy to discuss more in the meeting but I wanted to send a brief reply
here ahead of time.

Cheers,
Jeremy

On Wed, Apr 9, 2025 at 7:28 AM Tiago Freire <tmiguelf_at_[hidden]> wrote:

> I would like to participate in this meeting.
> But if that's not possible I would like to share my concerns here.
>
> I agree with the sentiment on char_traits, I came to the same conclusion
> (while doing separate work) that it's inclusion has some fatal flaws that
> do more harm than good, and that if we can we should avoid it.
>
> However, I don't see zstring_view as a requirement for std::arguments,
> even though the OS may present this (as an implementation detail) as null
> terminated string we don't actually need to provide that guarantee to make
> it coherent.
> To add to that, it is my genuine belief that null terminated strings as a
> practice has been responsible for the vast majority of security
> vulnerabilities and memory safety problems as well as other miscellaneous
> inefficiencies. It's one of the key causes that make languages like C and
> C++ to have such a bad reputation.
> If I was given the opportunity to go back in time and eliminate something
> from the history of computing, this would have been it.
> The reasons for that is a bit too large to explain on this email.
> But suffice to say that I don't support the use of it in principle. And
> that any interface going forward would be better off not having the
> assumption of null terminated.
>
> Just my 2 cents.
>
>
>
> ------------------------------
> *From:* SG16 <sg16-bounces_at_[hidden]> on behalf of Corentin Jabot
> via SG16 <sg16_at_[hidden]>
> *Sent:* Wednesday, April 9, 2025 10:58:54 AM
> *To:* sg16_at_[hidden] <sg16_at_[hidden]>
> *Cc:* Corentin Jabot <corentinjabot_at_[hidden]>; Jeremy Rifkin <
> jeremy_at_[hidden]>; Peter Bindels <dascandy_at_[hidden]>; Hana Dusíková <
> hanicka_at_[hidden]>; Tom Honermann <tom_at_[hidden]>
> *Subject:* Re: [isocpp-sg16] Agenda for the 2025-04-09 SG16 meeting
>
> A few pre-meeting comments.
>
> I think the agenda should be swapped: It is _much_ saner to work on
> std::arguments if we can admit the existence of zstring_view - to the
> extent I'd consider zstring_view a requirement for std::arguments.
>
> On zstring_view: Can anyone provide justification for char_traits beside
> "monkey see, monkey do"? I would like us to stop perpetuating past
> misguidances in perpetuity and just not have that trait in the interface of
> zstring_view.
> Sure, it's inconsistent, but we are learning. It is not useful, and it's
> easier to not add it than to remove it (to the extent that not removing it
> is not likely to be ever possible)
>
> Besides that, I have no SG16 concern on this paper, so ship it.
> Note that the reflection people currently seem to be keen on shipping
> string_view-based interfaces (which is fine, really, there is no need for
> null termination in reflection-based interface)
>
> --
>
> std::arguments:
>
> I'm still very much opposed to the design from an SG16 perspective (even
> if I hope the paper ultimately makes progress for C++29)
> This is trying to shove ad-hoc conversions between encodings into an
> interface that ought to be a bag of bytes. We should have these concerns
> separated.
> (and we certainly do not want to have support for u8,u16, and u32 in the
> same interface, let alone path)
>
> The previous poll reflects this, and the paper is not explicit about the
> motivation for not following guidance.
> In particular, the paper mentions WMain, but this is non-standard - Note
> that I would not be opposed to something like warguments being
> conditionally available on these platforms - it certainly would be a more
> elegant solution to that problem.
>
> But from a standard perspective, I think we ought to assume main() has
> been called, and that by definition, mains arguments are in the environment
> encoding (or not text).
>
> Cheers
>
>
>
> On Wed, Apr 9, 2025 at 6:06 AM Tom Honermann via SG16 <
> sg16_at_[hidden]> wrote:
>
> SG16 will hold a meeting *today*, Wednesday, April 9th, at 19:30 UTC (timezone
> conversion
> <https://www.timeanddate.com/worldclock/converter.html?iso=20250409T193000&p1=1440&p2=tz_pdt&p3=tz_mdt&p4=tz_cdt&p5=tz_edt&p6=tz_cest>
> ).
>
> *For those in Europe, please note that daylight savings time has begun, so
> this meeting will begin one hour later relative to the last meeting.*
>
> If you need a .ics file to import into your calendar, you can download it
> here
> <https://documents.isocpp.org/remote.php/dav/public-calendars/R7imgS2LJD9xfeWN/94A3D3A0-70B9-4847-935F-9453DB2BB216.ics?export>
> .
>
> The agenda follows.
>
> - D3474R1: std::arguments
> <https://jeremy-rifkin.github.io/proposals/drafts/cpp/D3474R1.html>.
> - P3655R0: std::zstring_view <https://wg21.link/p3655r0>.
>
> *D3474R1* comes to us courtesy of Jeremy Rifkin and seeks to provide a
> modern interface to access program arguments (also known as command line
> options). The design exposes the program arguments as a contiguous sequence
> of elements of type std::argument via std::span. The members of
> std::argument closely parallel those of std::filesystem::path and provide
> conversion to char, wchar_t, char8_t, char16_t, and char32_t representations.
> An additional path() member enables conversion directly to
> std::filesystem::path thereby allowing the implementation to correctly
> transcode a program argument to a correctly encoded file path for the
> platform. Raw access to the program arguments is provided by native(),
> native_string(), and c_str() members. Access to the program options is
> read-only and provided by a std::arguments() function. Since memory
> allocation might be required, allocator support is also provided. The
> primary concern for SG16 is, of course, matters of encoding. The encoding
> of program arguments, at least for POSIX platforms, usually corresponds to
> the encoding corresponding to std::text_encoding::environment() (which
> may differ from the current C and C++ locales). We should discuss
> implementation concerns, including any locale related ones. Given our
> collective expertise in how program arguments are provided by
> implementations and used by programmers, we may want to identify a list of
> considerations for LEWG to keep in mind for their design review and/or
> suggest changes that aren't necessarily related to core SG16 concerns.
>
> *P3655R0* also has Jeremy's name on it, but accompanied by the familiar
> names of Peter Bindels and Hana Dusíková. It seeks to standardize a variant
> of std::string_view that offers a null termination guarantee. This is not
> the first paper to propose such a type; nor the second, nor the third!
> Given the history of papers (see section 3 in the paper) that stalled for
> one reason or another, the motivation for SG16 review is to provide a
> (hopefully strong) recommendation to LEWG (one way or the other) regarding
> the utility of the proposed type from a group of text experts.
>
> Tom.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
>
>