IMO, the lesser of string length and a terminating zero should relevant. Jallib libraries should support this in any combination.
Joep 2011/5/31 Sebastien Lelong <[email protected]>: > so, what if you want to compare these two strings if you decide all strings > should be NULL terminated ? > const byte str[] = "seb" > const byte str[] = "matt" > (I'm just saying you can't stick to one or another logic, both make sense) > Cheers, > seb > 2011/5/31 mattschinkel <[email protected]> >> >> Of course we have to change the logic, this is what I am suggesting :) >> >> Matt. >> >> On May 31, 2:37 pm, Sebastien Lelong <[email protected]> >> wrote: >> > 2011/5/31 mattschinkel <[email protected]> >> > >> > > Ok Seb, so you agree that we can use null strings for the string lib >> > > only? >> > >> > What if I want to compare these two strings with your function >> > (string_compate_case): >> > >> > const byte name1[] = "seb" >> > const byte name2[] = "matt" >> > >> > I won't be able to do this anymore, right ? >> > >> > > 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(). >> > >> > yes, but the logic to deal with both ways is different. Consider the >> > following generic string, floating in the air...: >> > >> > generic_string >> > >> > (yes, you don't know the definition). How do you know how to compare it >> > ? >> > >> > ... am I missing something ? >> > >> > Seb >> > >> > >> > >> > >> > >> > > 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. >> > >> > -- >> > 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. >> > > > > -- > 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. > -- 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.
