>> That C null is an int pointer, longer than a single byte. Yep, no arguments there. ;)
On Wed, Jun 9, 2021 at 11:06 AM yary <not....@gmail.com> wrote: > 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 > -- __________________ :(){ :|:& };:
