[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnulib] addition: linebreak.h, linebreak.c
From: |
Bruno Haible |
Subject: |
Re: [Bug-gnulib] addition: linebreak.h, linebreak.c |
Date: |
Tue, 8 Apr 2003 22:40:10 +0200 (CEST) |
Paul Eggert writes:
> That depends on what you mean by "usable", but on some larger
> word-oriented systems 'unsigned int' is 64 bits, so one cannot assume
> that it stores only 32-bit values.
Yes I know this. I hope all of my code works when 'int' has more than
32 bits.
FRom my reading of the libX11 sources, I was under the impression
that 'short' is 16 bits on Cray and that therefore there is no
exactly-32-bits type there.
> Different Cray hardware implementations have different
> assumptions, and one can find currently-used Cray hosts where unsigned
> short is 16, 32, and 64 bits.
Oh gee. What a mess :-(
> > I don't want to change the header file (-> and have everyone
> > recompile its code) once a new encoding has to be added.
>
> I don't see why recompilation would be needed, if the encoding is
> represented as (say) an integer. Yes, the function to convert an
> encoding from string to integer would need to be updated and
> recompiled
Ok, I see you mean to hide the actual integer definitions in the .c
file. That'd be an interesting speed improvement. Thanks.
I have the code actually already in gettext's po-charset.c; I'll see
how to migrate it to linebreak.c.
> > > I was confused by the prefixes u8, u16, and u32. At first I thought
> > > they meant "unsigned integer of width 8 bits", etc.
> > > How about changing the prefixes to utf8, utf16, and ucs4, respectively?
> >
> > It'd possible, but what's the gain?
>
> To avoid confusion with prefixes that are already widely used with the
> meaning that I intuitively ascribed to them.
I claim that I use the prefixes in the same meaning. (Putting aside
Crayisms where 'uint32_t' isn't 32-bit.)
> Those are valid assumptions, but I was concerned about the opposite
> direction, e.g. the Cray T3E where 'unsigned short' is the only 32-bit
> unsigned integer type. On such a host, one should use 'unsigned
> short' to represent long strings of 32-bit quantities.
On such a machine, the use of 'unsigned int' for 32-bit integers
wouldn't make a package break. It would just consume more memory than
absolutely necessary. I'm reluctant to use #ifdefs for this case.
gettext already uses a type 'nls_uint32' for 32-bit integers where it
matters (namely writing to a file), and this #ifdef was too hairy for
MIPS in n32 and/or 64-bit mode...
> Cray tends to be the most extreme porting case here, among actively
> used hosts. Different Cray hardware implementations have different
> assumptions, and one can find currently-used Cray hosts where unsigned
> short is 16, 32, and 64 bits. For example, the newest model, the Cray
> X1, does have a 16-bit short, but it is quite slow, so the usual
> typedefs for it are "typedef short int_least16_t;" and "typedef int
> int_fast16_t;".
Does Cray provides an <inttypes.h> or <stdint.h> with this contents,
or do C programmers have to do this typedef by themselves?
Bruno