Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:Practically speaking, unless one is targeting a machine that uses EBCDIC or some other nonstandard character set, better advised to mostly ignore it, as ASCII has made a decisive win here...On Mon, 03 Aug 2026 14:47:21 +0000, Lew Pitcher wrote:Unless you are payed specifically to do so I see no reason to support
>On Sun, 02 Aug 2026 14:17:45 +0000, Kenny McCormack wrote:[snip]
>First off, I know the "standards" answer is "Either is correct; you have no>
right to complain about anything", but I am not interested in the
"standards" answer. If this is all you can do, then just click Next and go
on.
>
I'm interested in the "why" of why implementations might prefer one or the
other.
Consider the effects of the integer promotion rules on a system with an 8-bit
execution characterset (CHAR_BIT == 8) that has significant characters in the
0x80 through 0xff range[1], and how it affects the return results of functions
like getchar(), getc(), and fgetc().[1] Not as hypothetical as you might think; Some of the earliest C compilers>
(and current compilers as well) targetted the IBM EBCDIC systems, where much
of the basic execution characterset resides between 0x80 and 0xff, with the
numeric characters residing between 0xf0 and 0xf9. A signed <<char>> would
not work here.
For what it's worth, this was also the reason (prior to Unicode) that C
did not specify that alphabetic characters would have a contiguous sequence
in the execution characterset. In EBCDIC, the alphabetics group a-i, j-r, s-z
and A-I, J-R, S-Z, with various other characters (both assigned and unassigned)
between the groupings.
EBCDIC. Of course, IBM have enough influence to keep C standard
as it is regarding character set, but it does not mean that anybody
else should take is seriously.
Well, and UTF-8...
Had in my projects partly adopted Unicode, but not without fudging.
Basic character-set mostly limited to a few blocks:
Latin-1 range;
Also went and added Greek and Cyrillic characters and similar.
Except 0600..07FF: Reclaimed / Reused in 8x8 console fonts.
Most characters in this range can't be represented in 8x8 pixels.
Was more useful to use 0600..06FF for 00..FF dense hexadecimal.
0..9, A..F: Can be represented nicely in 4x8 pixels.
In some cases, it is nice to be able to display twice the hexadecimal in half the space (can also be used for decimal by treating it as BCD).
Also for reasons was nicer if it could fit in the UTF-8 2-byte range.
In this case, 0700..07FF can be used for some patterns related to UI drawing and representing images via color-cells.
Say, for example (6 bits):
Vsgn,Hsgn,Vfrq2,Hfrq2
Which effectively specifies a sine-wave pattern at 1 of 4 frequencies with a sign; Both horizontal and vertical.
This can be used to generate a series of 64 patterns that are useful in approximating images as color-cells.
Well, then some rounded curves and dithered gradient patterns (for more useful image approximation); and some basic tilesets for UI elements.
Well, some of these can be useful if one is storing graphics data in a form like, say:
1b: Escape (0=Normal, 1=Skip/RLE/etc)
7b: Cell-Index
4b: ColorA, 16-color / RGBI
4b: ColorB: 16-color / RGBI
Skip might be used for blocks that are skipped over;
RLE for blocks repeating the same pattern or a flat-color region.
...
Though, not exactly high fidelity; but when it works OK, may be hard to beat (and can reuse text-console mechanics).
...
Les messages affichés proviennent d'usenet.