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.
