Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Question on a C++ string Date: Sun, 29 Dec 2019 13:57:24 -0800 Organization: None to speak of Lines: 29 Message-ID: <87zhfapzgb.fsf@nosuchdomain.example.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="e3b117bf55650e4ec854fd7e333c3408"; logging-data="29472"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/GTl/MrK3WmelDGr8AK3JJ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:q++7if5iXSWY7ac58Z0p6bA7a5E= sha1:A0P+q5TeT2nsxElRj9tEgr3CADk= Xref: csiph.com comp.lang.c++:70789 T writes: [...] > I figured out through experimentation that Native Call > automatically add the chr(0) on to the end of a CString. > > And that sending Native Call a zero gets automatically > changed into a NULL. Hmmm, I wonder what happens > if you really what a numerical zero. That will be a > test for another day. > > Thank you all for all the wonderful help! You're talking about Raku/Perl6, right? Things you find out through experimentation aren't always reliable. It's possible that the Raku native call interface (which I haven't looked at) doesn't distinguish between a numerical zero and a null pointer. If that's the case, it could work with any C++ implementation that represents a null pointer as all-bits-zero. That's likely to be all existing C++ implementations, or at least all C++ implementations that Raku might interface with. It's not guaranteed by the C++ standard, though. A literal 0 is a *null pointer constant*, but that doesn't imply that a *null pointer* is represented as all-bits-zero. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com [Note updated email address] Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */