Ok Seb, so you agree that we can use null strings for the string lib only? As I said before, we don't waste a byte because a string can either end with "null character" or the actual end of the string which is count().
Matt. On May 31, 2:27 pm, Sebastien Lelong <[email protected]> wrote: > 2011/5/31 mattschinkel <[email protected]> > > > A null terminated string could also end at the end of the array, > > therefore not wasting a byte. > > It's always wasting a byte (NULL char) if you don't need it, this is what I > mean. In C, all strings are NULL terminated (C gurus will correct me if I'm > wrong): > > char str[] = "seb" > > is coded, behind the scene, as "seb\0". That's why all functions acting on > strings deals with NULL char. > > But in Jal, strings aren't NULL terminated (maybe this is related to > dynamic string arrays...): > > const byte str[] = "seb" really uses 3 bytes. > > Anyway... > > > > > Not using null terminated strings can result in loss of precious > > cycles. What was the reason you used null terminated strings? You are > > you wasting a byte? > > I'm using NULL terminated string because content is actually somewhere in a > buffer (100 bytes) and there's no information about how long it is. > > const byte str[] = "seb", count(str) will report 3, you know how long it is. > > In my 100 bytes buffer, if I'm dumping a 3-chars string ("seb"), it will be > coded as "seb\0", then I can scan buffer until end of string (NULL). I'm > using as a sort of dynamic strings. > > > Of course the user has his own choice, but I think we need a standard > > for the strings lib. > > Sure for the string lib, not for the strings themselves... Imagine all code > you'd have to modify to add NULL char at the end, for nothing most of the > time as strings are constant and compiler knows how long they are. > NULL/not-NULL strings are both two useful ways to deal with strings, it just > depends on the context you're using them. > > well, I hope this makes sense :) > > Cheers, > Seb > > > > > > > On May 31, 1:59 pm, Sebastien Lelong <[email protected]> > > wrote: > > > hi matt, > > > we should really *not* use null terminated strings everywhere as it > > > just wastes one precious byte for each string. please keep both > > > functions. > > > > i'm using null terminated strings in minix to parse commandline and > > > implement a REPl. I declare a buffer (say 100 bytes) and dump chars > > > from user. this means i don't necessarimy use all 100 bytes an thus > > > needs a way to detect end of string. > > > > cheers > > > seb > > > > -- > > > Sébastien Lelong > > > > Le 31 mai 2011 à 19:38, mattschinkel <[email protected]> a > > > écrit : > > > > > It seems that we don't need both strcmp() and string_compare(). Both > > > > should give back the same result. If we decide to use null terminated > > > > strings, we should use your procedure only. > > > > > Matt. > > > > > On May 31, 3:19 am, mattschinkel <[email protected]> wrote: > > > >> It was not in 0.6 so please remove it from 0.7, If it's ok with you. > > > > >> I don't think it will break anything. Please check. > > > > >> Matt. > > > > >> On May 31, 1:38 am, Sebastien Lelong <[email protected]> > > > >> wrote: > > > > >>> Hi Matt, > > > > >>> Sorry I couldn't find time... Maybe this WE, I'm not sure. If not, > > > >>> I can put > > > >>> a "temporary" notice claiming this will change. Was it release in > > > >>> 0.6 ? If > > > >>> no, we could remove it... > > > > >>> Cheers, > > > >>> Seb > > > > >>> 2011/5/31 mattschinkel <[email protected]> > > > > >>>>> OK, I'll modify this. > > > > >>>>> Cheers, > > > >>>>> Seb > > > > >>>> I noticed that the procedure names have still not been changed. > > > >>>> Can we > > > >>>> either fix this or remove strings.jal from torelease? Maybe we > > > >>>> should > > > >>>> review this library more before releasing. > > > > >>>> The only library of mine that uses this is networking, and it is > > > >>>> not > > > >>>> released. > > > > >>>> Matt. > > > > >>>> -- > > > >>>> You received this message because you are subscribed to the > > > >>>> Google Groups > > > >>>> "jallib" group. > > > >>>> To post to this group, send email to [email protected]. > > > >>>> To unsubscribe from this group, send email to > > > >>>> [email protected]. > > > >>>> For more options, visit this group at > > > >>>>http://groups.google.com/group/jallib?hl=en. > > > > >>> -- > > > >>> Sébastien Lelong > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "jallib" group. > > > > To post to this group, send email to [email protected]. > > > > To unsubscribe from this group, send email to > > [email protected] > > > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/jallib?hl=en > > > > . > > > -- > > You received this message because you are subscribed to the Google Groups > > "jallib" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > >http://groups.google.com/group/jallib?hl=en. > > -- > Sébastien Lelong -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
