Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!samsung!think!yale!cmcl2!uupsi!sunic!maxim!prc From: prc@erbe.se (Robert Claeson) Newsgroups: comp.sources.d Subject: Re: Why does 'stevie' mask the 8th bit ? Message-ID: <1196@maxim.erbe.se> Date: 29 Mar 90 16:23:58 GMT References: <1577@krafla.rhi.hi.is> <3250@tutor.tut.fi> Organization: ERBE DATA AB, Jarfalla, Sweden Lines: 80 In article <3250@tutor.tut.fi>, jt19840@tut.fi (Tuomi Jyrki Juhani) writes: > Well, this certainly isn't the case with IBM-PC implementation, as the upper > 128 chars are clearly defined as line drawing, international alphabet, and > other special characters. I also assume (could be wrong, though) that ST, > and Amiga have similar facilities. Yes, and the Macintosh. The Mac character set is not completely unlike ISO 8859, and Microsoft Windows and OS/2 Presentation Manager's "ANSI" character set is more or less identical to ISO 8859-1 ("Latin 1"). > I really wonder about the *most* systems in Sean's posting. How many did > you count :-? I could also say, that *most* systems I have been using, > allow eight bit characters, like PC compatibles, MACs, DEC VAXen, etc. > And they are running the same s/w as in the US :-) Don't forget just about any Xenix and UNIX System V system. > >7 bits is a very established way of doing things. Doing what? At least not around here. > Very true, things are changing, however. There is an international standard > for eight-bit characters (ISO Latin-1), and e.g. DEC has had eight-bit > characters in their systems for years (different from ISO :-( ). DEC MCS is based on an early draft of ISO 8859-1. About 6 or so characters differ, none of them alphabetic (if my memory serves me right). No big deal. We use ISO 8859-1 and DEC MCS interchangeably here (just as an UK site would use ASCII and the UK national version of ISO 646 interchangeably). > Someone else probably knows more about how busily Unix vendors are > (or are not) incorporating 8-bit character support in their systems. AT&T, Bull, Sun, HP, Encore, DG, Unisys etc are all incorporating or are already supporting 8 bit character sets with simultaneous support for multiple character sets of various widths. It is quite easy to do with AT&T's "streams" facilities, in fact. AT&T sells such products in 16- and 32-bit (character width, not the word size of the computer) environments. BSD 4.2 has no support for 8-bit character sets (it can't even input them without giving up s/w flow control and the canonical facilities). BSD 4.3 can accept 8-bit characters by the use of the pass8 flag to stty. On the system I use, the date command prints the date in Swedish (my language of choice) with 8-bit characters. The ls command shows the dates of files in Swedish. Vi accepts 8-bit characters and can correctly converting upper- to lower-case in whatever character set I'm using at the moment. There are message catalogs and other neat stuff too. > >What you guys in iceland need is not to require the rest of the world > >to accomodate you, but for you to accomodate the rest of the world. > > Yeah, and us in Norway, Sweden, Finland, Denmark, Germany, France, Spain, > Portugal, Switzerland, Greece, Canada, etc., etc., etc... Even British can't > have their pound sign in 7-bit ASCII... > > Yeah, we certainly need to accomodate the U.S. (oops, the rest of the world). Why can't the U.S. give up the 'A', 'E' and 'I' characters instead (just joking)? > >Perhaps you need a new standard with digraphs or something. > > Why don't we just stick with the current 8-bit character standard in those > environments that provide it and mask the 8th bit only when necessary > (e.g. via a conditional compilation option is source files). For God's sake, don't care about the so-called "parity bit"! Parity is not part of the data, but of the serial line protocol. Parity should never be handled by the application, but by the serial line circuitry or by the tty driver. If the serial port and the terminal connected to it are set up correctly, the application will never have to care about stripping data down to 7 bits. The "parity bit" is not always the 8th bit either. There's 8 bit data + parity too, in which case the parity bit effectively becomes the 9th bit. -- Robert Claeson E-mail: rclaeson@erbe.se ERBE DATA AB