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 >> >> >> >> -- >> __________________ >> >> :(){ :|:& };: >> > -- __________________ :(){ :|:& };:
