- It is implementation-dependent if plain `char' signed or not.
- C standard defines three *distinct* types: char, signed char,
and unsigned char.
- Assuming that char is always unsigned or signed can lead to
compile-time and run-time errors.
You can also use int8_t, but then it would be less obvious for developers
to never assume that char is always unsigned (or always signed).
Conflicts:
components/esm/loadcell.hpp
The data type is specified as char but the literals are unsigned char. This
results in 798 truncation warnings in vs2010. The literals were converted
with a simple python script to signed char while taking two's complement and
the overflow into account.
Also tested on Ubuntu 12.04 with gcc 4.6.
Added explicit cast to char, without that gcc 4.7 (with default settings)
is showing a lot of:
narrowing conversion of ‘...’ from ‘int’ to ‘char’ inside { } is ill-formed in C++11 [-Wnarrowing]
warnings.
Added new command line option: "encoding" which allow to
change font encoding used in game messages.
Currently there are three evailable encodings:
win1250 - Central and Eastern European (languages
that use Latin script, such as Polish,
Czech, Slovak, Hungarian, Slovene, Bosnian,
Croatian, Serbian (Latin script),
Romanian and Albanian)
win1251 - languages that use the Cyrillic alphabet
such as Russian, Bulgarian, Serbian Cyrillic
and others
win1252 - Western European (Latin) - default
Signed-off-by: Lukasz Gromanowski <lgromanowski@gmail.com>
Added namespace around generated win_1252 table.
Added generation of header guard and ToUTF8 namespace in gen_iconv.
Small corrections in Makefile.
Signed-off-by: Lukasz Gromanowski <lgromanowski@gmail.com>
scrawl
Douglas Mencken
Michael Mc Donnell
Lukasz Gromanowski
Nicolay Korslund