Re: [Bug-gnulib] addition: linebreak.h, linebreak.c

[Bruno Haible]

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