When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.
On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote:
When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.
C and C++ have different conventions for data types. dIsspace() avoids problems in C code on platforms with a signed char default. C++ is inmune. OTOH, it looks weird to have both calls in the code. I'd happily use dIsspace() all over if the compiler optimizes the extra cast away. -- Cheers Jorge.-
On Sun, Jul 26, 2009 at 12:27:05PM -0400, Jorge Arellano Cid wrote:
On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote:
When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.
C and C++ have different conventions for data types. dIsspace() avoids problems in C code on platforms with a signed char default. C++ is inmune.
The results for C++ are not different as far as ctype(3) are concerned.
OTOH, it looks weird to have both calls in the code. I'd happily use dIsspace() all over if the compiler optimizes the extra cast away.
The cast is a nop on every architecture that matters. That is not the answer you might get from comp.lang.c though :) Joerg
On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote:
On Sun, Jul 26, 2009 at 12:27:05PM -0400, Jorge Arellano Cid wrote:
On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote:
When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.
C and C++ have different conventions for data types. dIsspace() avoids problems in C code on platforms with a signed char default. C++ is inmune.
The results for C++ are not different as far as ctype(3) are concerned.
It looks like it's the compiler the one that decides [1]. When porting dillo to minix3 I had this problem.
OTOH, it looks weird to have both calls in the code. I'd happily use dIsspace() all over if the compiler optimizes the extra cast away.
The cast is a nop on every architecture that matters. That is not the answer you might get from comp.lang.c though :)
Good, then we can use dIsspace all over the place. [1] http://home.att.net/~jackklein/c/inttypes.html -- Cheers Jorge.-
On Mon, Jul 27, 2009 at 02:16:53PM +0000, corvid wrote:
Jorge wrote:
When porting dillo to minix3 I had this problem.
So it works? I don't see it in Compatibility.html
Minix3 doesn't have Unix sockets nor pthreads yet, so all the DPI framework is not of the party. The main program (dillo itself) works very well on rendering and UI (flawless in my local testing). I don't have a network card supported by minix so they're testing how it works on the real Web. Once I get an official OK, it surely deserves a mention in Compatibility.html. -- Cheers Jorge.-
On Mon, Jul 27, 2009 at 10:02:28AM -0400, Jorge Arellano Cid wrote:
On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote:
The results for C++ are not different as far as ctype(3) are concerned.
It looks like it's the compiler the one that decides [1]. When porting dillo to minix3 I had this problem.
Yes, what I said is that it is irrelevant whether you have C or C++ for this. The argument for ctype(3) macros must always be either EOF or 0..255. At least on NetBSD you will also get a compiler warning when using (signed) char. Joerg
participants (3)
-
corvid＠lavabit.com -
jcid＠dillo.org -
joerg.sonnenberger＠web.de