November 2011 - Dillo-dev - lists.mailman3.com

is* character classification

by corvid＠lavabit.com

I was just looking at how the is* functions treat characters with the high bit set. If I set LC_CTYPE to en_US, 0xC0 is alpha, but it understandably isn't in en_US.UTF-8. So I found my way to /usr/share/i18n/locales/ en_US -> en_GB -> i18n And found that: upper 41-5A, C0-D6, D8-DE lower 61-7A, B5, DF-F6, F8-FF alpha 41-5A, 61-7A, AA, B5, BA, C0-D6, D8-F6, F8-FF digit 30-39 space 09-0D, 20 cntrl 00-1F, 7F-9F punct 21-2F, 3A-40, 5B-60, 7B-7E, A0-A9, AB-B4, B6-B9, BB-BF, D7, F7 graph 21-7E, A0-FF print 20-7E, A0-FF xdigit 30-39, 41-46, 61-66 blank 9, 20 In dillo: isupper not used islower not used isalpha cssparser, html isdigit doesn't matter isalnum cssparser, html, datauri, downloads, dlib.h dIsalnum url isspace cssparser, html, keys, dlib.h, findtext.hh dIsspace colors, src/cookies, misc, dpi/cookies, file, ftp, dlib iscntrl keys, auth, misc ispunct textblock isgraph not used isprint dlib isxdigit doesn't matter isblank not used isascii not used I'm not sure that any real harm is done in these cases, but it might not be a bad idea to check that it's ascii when we only want ascii.

Nov. 9, 2011

tests that should not be case-sensitive

by corvid＠lavabit.com

I don't want to do anything about this until we get the big patch committed, but I just looked through the str(n)cmp calls in dillo, and I found: - a bunch of cases where we test url strings with the scheme included. - hostname tests in dns.c. I don't know that code at all, though. Is there any reason why it has to treat the hostnames that way? - generic font-family names in styleengine.cc. CSS 2.1 says: "All CSS syntax is case-insensitive within the ASCII range (i.e., [a-z] and [A-Z] are equivalent), except for parts that are not under the control of CSS. For example, the case-sensitivity of values of the HTML attributes "id" and "class", of font names, and of URIs lies outside the scope of this specification. Note in particular that element names are case-insensitive in HTML, but case-sensitive in XML." ...although I know "@charset" has to be lowercase, so this might not be the ultimate answer, but I didn't see anything suggesting otherwise.

Nov. 9, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > So all uppercase macros then or just not trying to inline and use a > normal function. Here's what I have now: http://www.dillo.org/test/ascii_strcasecmp3.diff

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Tue, Nov 08, 2011 at 08:15:57PM +0000, corvid wrote: > Johannes wrote: > > On Tue, Nov 08, 2011 at 05:42:26PM +0000, corvid wrote: > > > I think I'll go with D_ASCII_TOUPPER because the argument gets > > > evaluated more than once, and we don't want nasty surprises. > > > > Hm, not sure what you mean. An inline function should behave just as > > a normal function that's the nice thing about them. > > If I'm in dlib.h and it's C90, can I use inline? I was under the > impression that I couldn't. Argh, I knew there was a catch :-) So all uppercase macros then or just not trying to inline and use a normal function. Cheers, Johannes

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Johannes wrote: > On Tue, Nov 08, 2011 at 05:42:26PM +0000, corvid wrote: > > I think I'll go with D_ASCII_TOUPPER because the argument gets > > evaluated more than once, and we don't want nasty surprises. > > Hm, not sure what you mean. An inline function should behave just as > a normal function that's the nice thing about them. If I'm in dlib.h and it's C90, can I use inline? I was under the impression that I couldn't.

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Tue, Nov 08, 2011 at 05:42:26PM +0000, corvid wrote: > Jorge wrote: > > On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > > > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > I'd just go with the approach in your first patch. > > > > > > > > All right then. Do you have any thoughts on what function names > > > > would be least unwieldy / most descriptive / best fitting in > > > > with their surroundings? > > > > > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > > > > > Let's see what others do: > > > > > > * KDE: kAsciiToUpper() [1] > > > * glib: g_ascii_toupper() [2] > > > * ffmpeg: av_toupper() [3] > > > * libevent: evutil_ascii_strcasecmp() [4] > > > > > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. > > > > +1 > > I think I'll go with D_ASCII_TOUPPER because the argument gets > evaluated more than once, and we don't want nasty surprises. Hm, not sure what you mean. An inline function should behave just as a normal function that's the nice thing about them. Let's test: #include <stdio.h> static inline int test(int i) { return i > 0 ? i - 1 : i; } #define TEST(i) ((i) > 0 ? (i) - 1 : (i)) int main (int argc, char **argv) { int i = atoi(argv[1]); int j = atoi(argv[1]); printf("%d\n", test(i++)); printf("%d\n", TEST(j++)); } ./inline 2 1 2 Cheers, Johannes

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

And *sigh* dStristr -> dStriAsciiStr, which seems more readable than dStrAsciiIStr.

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by corvid＠lavabit.com

Jorge wrote: > On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > > Johannes wrote: > > > > I'd just go with the approach in your first patch. > > > > > > All right then. Do you have any thoughts on what function names > > > would be least unwieldy / most descriptive / best fitting in > > > with their surroundings? > > > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > > > Let's see what others do: > > > > * KDE: kAsciiToUpper() [1] > > * glib: g_ascii_toupper() [2] > > * ffmpeg: av_toupper() [3] > > * libevent: evutil_ascii_strcasecmp() [4] > > > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. > > +1 I think I'll go with D_ASCII_TOUPPER because the argument gets evaluated more than once, and we don't want nasty surprises. (I'm tempted to say "Or ASCII_TOUPPER?", but it'd be nice for the whole topic to come to an end, wouldn't it? :)

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by jcid＠dillo.org

On Mon, Nov 07, 2011 at 10:25:39PM +0100, Johannes Hofmann wrote: > On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > > Johannes wrote: > > > I'd just go with the approach in your first patch. > > > > All right then. Do you have any thoughts on what function names > > would be least unwieldy / most descriptive / best fitting in > > with their surroundings? > > > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). > > Let's see what others do: > > * KDE: kAsciiToUpper() [1] > * glib: g_ascii_toupper() [2] > * ffmpeg: av_toupper() [3] > * libevent: evutil_ascii_strcasecmp() [4] > > So dAsciiToupper() and dStrAsciiCasecmp() look good to me. +1 -- Cheers Jorge.-

Nov. 8, 2011

ascii string comparison [Re: use C locale for LC_CTYPE]

by Johannes.Hofmann＠gmx.de

On Sun, Nov 06, 2011 at 08:19:07PM +0000, corvid wrote: > Johannes wrote: > > I'd just go with the approach in your first patch. > > All right then. Do you have any thoughts on what function names > would be least unwieldy / most descriptive / best fitting in > with their surroundings? > > I'm thinking maybe dAsciiToupper() and dStrAsciiCasecmp(). Let's see what others do: * KDE: kAsciiToUpper() [1] * glib: g_ascii_toupper() [2] * ffmpeg: av_toupper() [3] * libevent: evutil_ascii_strcasecmp() [4] So dAsciiToupper() and dStrAsciiCasecmp() look good to me. Cheers, Johannes [1] http://api.kde.org/4.x-api/kdelibs-apidocs/kdecore/html/kascii_8h.html [2] http://developer.gnome.org/glib/2.28/glib-String-Utility-Functions.html [3] http://permalink.gmane.org/gmane.comp.video.ffmpeg.cvs/43420 [4] http://www.wangafu.net/~nickm/libevent-2.0/doxygen/html/util_8h.html

Nov. 7, 2011