Re[2]: Octstr support for converting to and from HTML 4 entities.

Hello List,

MHO on A couple of things:
- strcmp is (should be) Locale specific, according to POSIX.
- The difference in octstr_compare and octstr_str_compare are at least
inconsequent. They should both use either use strcmp or memcmp to
avoid confusions (my vote is for strcmp).
- The discussion about whether entities should be compared to Locale or
to byte order is more or less void. Entities do not contain
locale-specific characters by definition. Because that is why entities
are used for. At the same time an excuse, because I started this
discussion.
Background behind that: that was that I saw that octstr_str_compare
was using strcmp and the normal str_compare used memcmp. And I did not
know if there was any special reason for it. Also my the patch that I
posted first, did a byte compare on each character. So I just wanted
to point out that there was a difference.

-- Rene...


Monday, September 23, 2002, 4:32:37 PM, you wrote:

 
 


OA> -----Original Message-----
OA> From: Andreas Fink [mailto:[email protected]]
OA> Sent: Monday, September 23, 2002 4:13 PM
OA> To: Oded Arbel
OA> Cc: [email protected]
OA> Subject: Re: Octstr support for converting to and from HTML 4 entities.





OA> Oh. that was me - sorry. its no hard rule, but basicly what I meant is - don't use c strings for doing complicated stuff that the Octstr sub system handles better and more safely. do use c-string
OA> library calls for simple stuff that the library call would do better, especially if the call doesnot modify the content of the string (hence - no risk for buffer overflows). for example, when you
OA> want to compare octstrings you can use strcmp(octstr_get_cstr(.... or you can use octstr_compare(). this is the border line case IMO, where in this case I would have used the octstr_compare() as
OA> it involves fewer calls. you have already demonstrated that you can choose correctly between complexity and safety, and you can make the same decisions here. most importantly - don't take
OA> anything said by Kannel developers , especially me, as hard truth - those are simply recomendations. if we hate your code so much (not that I do) - we can change when it is in the CVS :-) 



OA> strcmp(octstr_get_cstr(... and octstr_compare() behave DIFFERENTLY. 
OA> if I remember correctly octstr_compare is case sensitive where strcmp is more or less simply comparing the bytes. 

OA> strcmp should be locale sensitive as per the POSIX standard, IIRC. it has nothing to do with case sensitivity.

OA>   I wouldnt count on it to compare on upper/lowercase and even diacritical characters. 

OA> Well - you should. on the contrary - while strcmp is (or at least should be) locale aware, octstr_compare() uses memcmp() internally, which does simple byte comparison. OTOH, octstr_str_compare()
OA> which IMO should behave no different then octstr_compare() uses strcmp() internally. 


OA> as you can see comparing strings is not always obvious. but it should be at least consistent. So if you can write a parameter in a config file in upper or lower case and it doesn't really matter,
OA> suddendly using strcmp would make the behaviour really strange.  

OA> if you want to be case insensitive, you can use stricmp() or octstr_case_compare(). since Rene uses octstr_str_compare() which internally uses the locale sensitive strcmp(), maybe we should
OA> change it to use octstr_compare() somehow so that comparison would be byte ordered (locale insensitive) and sort the entity list to match ?

OA> octstr.c is an abstraction layer. Thats what it is there for. So use it for that purpose. 
OA> and frankly, the memory checking stuff is really useful in it. I'm fixing a few dozen memory leaks by using it. It points with the finger to it all the time. Very easy to fix this way. 

OA> stdc sting.h stuff doesn't give you any of that. 

OA> That's why its always a good idea to use it. sometimes though, if you are careful, the std lib calls provide extra performance which is also important.
 
OA> --
OA> Oded Arbel
OA> m-Wise mobile solutions
OA> [email protected]
 
OA> +972-9-9581711 (116)
OA> +972-67-340014
 
OA> ::..
OA> If you don't care where you are, then you ain't lost.




-- 
Best regards,
 Rene                            mailto:[email protected]