That C null is an int pointer, longer than a single byte. On Wed, Jun 9, 2021 at 11:04 AM Paul Procacci <pproca...@gmail.com> wrote:
> Not sure about the 80's, my programming endeavors started in the 90's. > NUL doesn't exist in the C standard so I have no comment on it. > The C standard defines that 0 cast to the type void * is both a null > pointer and a null pointer constant. > I always have and most likely will continue using 0 over NULL rightly or > otherwise; though tend to use either/or when describing something ... as > Elizabeth pointed out. > > Potato vs Potatoe I guess. > ~Paul > > On Wed, Jun 9, 2021 at 10:20 AM yary <not....@gmail.com> wrote: > >> From my early 1980s days learning programming, ASCII CHR 0 is not null, >> it is NUL (can type it as ctrl-@) it's a control character much like the >> others. >> >> Ctrl-G BEL, it was fun putting you in file names... >> >> On Wed, Jun 9, 2021, 9:56 AM Paul Procacci <pproca...@gmail.com> wrote: >> >>> >> But yeah, the Str class in Raku is much more than a C-string. >>> >>> Got it. Thanks Elizabeth. >>> >>> On Wed, Jun 9, 2021 at 6:45 AM Elizabeth Mattijsen <l...@dijkmat.nl> >>> wrote: >>> >>>> > On 9 Jun 2021, at 06:34, Paul Procacci <pproca...@gmail.com> wrote: >>>> > >>>> > Hopefully a pretty quick question.... >>>> > >>>> > GIven the following: >>>> > >>>> > my Buf $b .= new([72, 105, 0, 32, 97, 103, 97, 105, 110, 0]); >>>> > say $b.decode; >>>> > >>>> > I would expect this to print 'Hi'. >>>> > Instead it prints 'Hi again'. >>>> > >>>> > https://docs.raku.org/type/Buf#(Blob)_method_decode >>>> > >>>> > The decode documentation for Buf only states that 'Applies an >>>> encoding to turn the blob into a Str; the encoding will be UTF-8 by >>>> default.' >>>> >>>> > >>>> > The zero (0) in that Buf should imply an end of string yet decode >>>> seems to want to decode the number of elements instead. >>>> >>>> That is an incorrect assumption carried over from C. In the Raku >>>> Programming Language, a null byte is a valid grapheme, as it is in >>>> unicode. A small change to your program: >>>> >>>> my Buf $b .= new(72, 105, 0, 32, 97, 103, 97, 105, 110, 0); >>>> .say for $b.decode.uninames; >>>> ##### >>>> LATIN CAPITAL LETTER H >>>> LATIN SMALL LETTER I >>>> <control-0000> >>>> SPACE >>>> LATIN SMALL LETTER A >>>> LATIN SMALL LETTER G >>>> LATIN SMALL LETTER A >>>> LATIN SMALL LETTER I >>>> LATIN SMALL LETTER N >>>> <control-0000> >>>> >>>> >>>> > Furthermore, If I 'say $b.decode.chars;' it counts the initial null >>>> as part of Str. >>>> > In my mind, that means Str doesn't really mean string. >>>> >>>> I don't see an initial null in your example. >>>> >>>> But yeah, the Str class in Raku is much more than a C-string. >>>> >>>> >>>> > So the question, how does one ACTUALLY decode what's in a buffer to a >>>> string where it adheres to the semantics of NULL termination for strings >>>> cleanly. >>>> >>>> If you want to include the null byte in your final strings: >>>> >>>> my @strings = $b.decode.comb(/ .*? "\0" /) >>>> >>>> would be a way. >>>> >>>> >>>> >>>> > Another question might be, should decode() follow null terminating >>>> semantics instead of number of elements in a given Buf. >>>> >>>> No. The C-string semantics are what they are. They are not the >>>> semantics used in the Raku Programming Language. >>>> >>>> >>>> >>>> Liz >>> >>> >>> >>> -- >>> __________________ >>> >>> :(){ :|:& };: >>> >> > > -- > __________________ > > :(){ :|:& };: > -- -y
