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.
