From: nowhere@never.at   
      
   Hi Ben,   
      
   > Thanks for your comments.  I will try to answer everyones questions   
   > within this post.   
      
   > First, to clarify, the strings will only contain alpha and numeric   
   > characters, including a single '.' char. (for now).   
      
   >> If your strings contain also numbers then a OR 0x20 would work while   
   >> AND 0xDF wont.   
      
   > Why not?  If guarenteed to only have alpha and numeric chars, an   
   > AND will work also.  Numeric chars have bit 6 cleared, while alpha   
   > chars have bit 6 set.   
      
   ??? don't we talk about bit 5 here (Ucase vs. Lcase) ?   
   If you clear bit 5 on a number ie: 0x30 it becomes a 0x20 aka Space.   
      
   and what would a dot (0x2e) become if you clear bit5 ? [==0x0e]   
      
   > Rod said:   
   >> If you say what these strings are for, there might be some   
   >> simplification for your usage.   
      
   > And Robert said:   
   >> Are the strings limited to *only* letters?  Otherwise you'll end up   
   >> comparing '[' and '{' as equal (for example).   
      
   > I am using it when comparing filenames when searching for the   
   > loader file within the specified file system.  This routine needs   
   > to be called (unchanged) no matter the file system being used.   
   >   
   > For now, string0 is a fixed value of:   
      
   >  'loader.sys',0   
      
   > string1 can be any string (alpha, numeric, or '.') from the specified   
   > file system being searched.   
      
   > Rod also said:   
   >> If this is for assembly, I'm wondering why you're using -1, 0, 1   
   >> returns.  These are good for C, but for assembly, you'd be better off   
   >> with setting processor flags for Jcc branch instruction.  Is this for   
   >> C code for Smaller C? ...  Yes, they're ASCIIZ, so very likely C code.   
      
   > It is all assembly.  However, here is the reason why I am trying to   
   > stick with some sort of standard.  I have (currently) seven file systems   
   > and/or MBR's that may call this routine.  If I make is specific to   
   > one source file, it may throw a bug in another without notice.   
      
   > I don't want to rely on something in one file and assume it in another.   
      
   > However, since I won't be using C (or calling it from C), I can   
   > change it to use something else, though I need to maintain the   
   > less-than, equal, or greater-than return values for future use.   
      
   > Zero flag, of course, for equal, and sign (or carry) flag for   
   > less-than and greater than could be an option.   
      
   > zero = clear = not equal   
   > zero = set = strings are equal   
   > carry = set = string0 < string1   
   > carry = clear = string0 > string1   
      
   > This all can be created with a single 'sub' instruction.   
      
   exact.   
      
   > wolfgang said:   
   >> But if your strings are allowed to contain anything else than A..Z,   
   > a..z, 0..9 then both (AND and OR) will fail without proper filters.   
      
   > Yes they would.  This is a thought for future code.  For example,   
   > currently I only allow   
      
   >  'loader.sys',0   
      
   > to be searched for.  However, what if I decide to use "long file names"   
   > such as what Ext2/3/4, LeanFS, etc allow.   
      
   >  'loader version 1.2.3.4[rev0]',0   
      
   > Now we have a problem.   
      
   >> you already mentioned it: replace the calls with OR 0x20,   
   >> and I wouldn't use HLL-styled return values.   
      
   > I currently use an AND 0xDF which will set the zero flag accordingly.   
   > However, if you will explain why an AND 0xDF won't work (using alpha   
   > and numeric chars only), I can modify my code accordingly.   
      
   see my above explanation about clearing bit 5.   
      
   > Again, I have numerous first stage boot/loader files, one for each   
   > file system I support, along with other sources, and only want   
   > to maintain one source file for stricmp (along with numerous other   
   > library calls).  I then want to be able to, for future filesystems   
   > and first stage code files, to rely upon this library call without   
   > having to rely on any quirks or assumptions.  A guarantee that it   
   > will return -1, 0, or +1 is a common return for such a function call.   
      
   Ok if you like it to work on the HLL way.   
      
   > All of the file systems I currently support, have enough room within   
   > the first stage code to allow a proper stricmp for any ascii char   
   > zero to 255, except for my ext2 code.  Unfortunately, ext2 only allows   
   > 512 bytes for the first stage boot code.  I either have to load   
   > any additional sectors or use only the first 512 bytes.  The problem   
   > with ext2/3/4, loading additional first stage boot code is not as   
   > easy as it may seem.   
      
   Sorry for I cant help you on Loonix-FS.   
      
   > Anyway, I am mostly just posting/commenting for the company of others,   
   > just to hear your thoughts.   
      
   > Thank you,   
   > Ben   
      
   always welcome...   
   __   
   wolfgang   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)