pspp-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pre-lexer-2 1/4] command: Factor command name matching out of comma


From: Ben Pfaff
Subject: Re: [pre-lexer-2 1/4] command: Factor command name matching out of command.c.
Date: Sun, 26 Sep 2010 06:46:34 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

John Darrington <address@hidden> writes:

> On Sat, Sep 25, 2010 at 12:23:48PM -0700, Ben Pfaff wrote:
>      libunistring uses uint8_t (unsigned char) for UTF-8.  That's the
>      same as what PSPP uses currently for "union value".  I'm inclined
>      to do this:
>      
>              * Use uint8_t for UTF-8, via libunistring.
>      
>              * Use char for multibyte strings in the current locale.
>      
>              * Change "union value" to use signed char, in place of
>                its current use of unsigned char.
>      
>      Then we'll be able to cleanly distinguish each of these types
>      (char vs. unsigned char vs. signed char) and get some help from
>      the compiler.
>
> How is "char" different from "signed char" ?  The compiler automatically
> assumes a type is signed if no qualifier is specified.

"char" is special.  There are three distinct character types:
char, signed char, and unsigned char.  As a demo, compile this:

    int foo(void)
    {
      char c;
      signed char sc;
      unsigned char uc;
      &c == &sc;
      &c == &uc;
      &sc == &uc;
    }

and you'll get these warnings:

    tmp.c: In function ‘foo’:
    tmp.c:6: warning: comparison of distinct pointer types lacks a cast
    tmp.c:6: warning: statement with no effect
    tmp.c:7: warning: comparison of distinct pointer types lacks a cast
    tmp.c:7: warning: statement with no effect
    tmp.c:8: warning: comparison of distinct pointer types lacks a cast
    tmp.c:8: warning: statement with no effect
    tmp.c:9: warning: control reaches end of non-void function

> Also, the Gtk/Glib functions use plain char for UTF8 strings,
> so we would need a lot of casts between the two in the gui
> code.  If libuistring has decided to use the convention the
> other way around, that is unfortunate.

Hmm.
-- 
Ben Pfaff 
http://benpfaff.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]