Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: getline() problem Date: Sat, 23 Apr 2022 18:24:24 -0700 Organization: None to speak of Lines: 24 Message-ID: <875ymzclyv.fsf@nosuchdomain.example.com> References: <30821cca-aba2-4df3-9109-28f302fd1e26n@googlegroups.com> <87v8uzz6rz.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="de37a51cdfcc9bf522499568c2f037fc"; logging-data="7625"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18DUWp0eBBS53Z4rBw8iUAj" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:8th7bnDYsMl/qY7wTMyxrpJV5XI= sha1:PpfB91dfHwEwS6rGfoACpeCGN8Y= Xref: csiph.com comp.lang.c++:83696 Ben writes: > Malcolm McLean writes: > >> Nul bytes will break most text-based reading functions, because they return >> text as C strings, and C strings are Nul-terminated. However std::strings can >> have embedded nuls without special processing. You just have to be careful >> not to pass them to any function that coverts them to C strings. In practice >> that probably means taking action against the nuls at an early stage. > > This is comp.lang.c++ not comp.lang.c! Yes, of course. To be fair, C++ includes most of the C standard library by reference, and if you have a std::string containing a null character, you have to be careful what you do with it. And C++ string literals still represent C-style strings. For example, this will print "3": std::cout << std::string("abc\0def").size() << "\n"; -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */