[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c |
Date: |
Wed, 29 Jan 2003 18:49:46 +0100 (CET) |
Paul Eggert writes:
> > however it's not a problem for the c_* functions.
>
> I agree, but for Japanese it works only because "<yen>" happens to
> fall into the same ctype category as "\", and similarly for
> "<overbar>" and "~". Luckily for us, the other ISO 646 national
> variants are no longer used, so we don't have to worry about the fact
> that, for instance, ISO 646-DE substituted an alphabetic character for
> the non-alphabetic ASCII character "~". If c_ctype had been written
> 20 years ago, this would have been a real problem, but nowadays I
> think it's OK to ignore
I agree.
> No, I didn't know that. But don't you have to parenthesize the C code
> properly?
>
> ((x - 1) & (- x - 1)) + 1 == (x & -x)
Yes sure.
> My own favorite property in this area is much simpler. I learned it
> by attending a talk by Edsger W. Dijkstra, where he spent way too much
> time on it since he thought it was neat too. The property is that
> "==" is associative on booleans.
But this is trivial: just map the booleans { true, false } to the bits
Z/2Z = { 0, 1 }, by mapping true to 0 and false to 1 (!), then "==" is
the same as "xor" or "+", and the equality of x+(y+z) and (x+y)+z
is inherited from "+" on Z.
Bruno
- [Bug-gnulib] addition: c-ctype.h, c-ctype.c, Bruno Haible, 2003/01/27
- Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c, Paul Eggert, 2003/01/27
- Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c, Bruno Haible, 2003/01/28
- Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c, Paul Eggert, 2003/01/28
- Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c, Bruno Haible, 2003/01/28
- Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c, Paul Eggert, 2003/01/28
- Re: [Bug-gnulib] addition: c-ctype.h, c-ctype.c,
Bruno Haible <=