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.
