Trigraphs

[Christopher Benson-Manica]

Assuming trigraphs are specified in the standard currently, how much longer do
you suppose that will be the case? Are there still enough "short" keyboards
out there to justisfy trigraphs?

--
Christopher Benson-Manica | Jumonji giri, for honour.
ataru(at)cyberspace.org |

[Andreas Kahari]

In article <bj**********@chessie.cirr.com>, Christopher Benson-Manica wrote:

Assuming trigraphs are specified in the standard currently, [reformatted paragraph] how much longer do you suppose that will be the case? Are
there still enough "short" keyboards out there to justisfy
trigraphs?

You mean, how long will it take for everyone to switch to ASCII
keyboards?

It is not simply a question of what keyboards are being used
(the standard never mentiones the word "keyboard") but what
character sets are being used by C programmers.

--
Andreas Kähäri

[Christopher Benson-Manica]

Andreas Kahari <ak*******@freeshell.org> spoke thus:

It is not simply a question of what keyboards are being used
(the standard never mentiones the word "keyboard") but what
character sets are being used by C programmers.

You mean '{' and '}' aren't found in many character sets...?

--
Christopher Benson-Manica | Jumonji giri, for honour.
ataru(at)cyberspace.org |

[Andreas Kahari]

In article <bj**********@chessie.cirr.com>, Christopher Benson-Manica wrote:

Andreas Kahari <ak*******@freeshell.org> spoke thus:

It is not simply a question of what keyboards are being used
(the standard never mentiones the word "keyboard") but what
character sets are being used by C programmers.

You mean '{' and '}' aren't found in many character sets...?

If there exists character sets that does not include { or },
there must clearly be *some* way of replacing these characters
in the source of a C program.
--
Andreas Kähäri

[Lew Pitcher]

Christopher Benson-Manica wrote:

Andreas Kahari <ak*******@freeshell.org> spoke thus:

It is not simply a question of what keyboards are being used
(the standard never mentiones the word "keyboard") but what
character sets are being used by C programmers.

You mean '{' and '}' aren't found in many character sets...?

More to the point, '[' and ']' aren't found in certain mainframe (EBCDIC)
charactersets. Other characters are missing from EBCDIC-US as well.
--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

[Tom Zych]

Lew Pitcher wrote:

More to the point, '[' and ']' aren't found in certain mainframe (EBCDIC)
charactersets. Other characters are missing from EBCDIC-US as well.

Ecch. EBCDIC. COBOL. Trigraphs. gets(). void main. The ugly side of
computer science...

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13

[Glen Herrmannsfeldt]

"Lew Pitcher" <Le*********@td.com> wrote in message
news:J8*******************@news20.bellglobal.com.. .

Christopher Benson-Manica wrote:

Andreas Kahari <ak*******@freeshell.org> spoke thus:

It is not simply a question of what keyboards are being used
(the standard never mentiones the word "keyboard") but what
character sets are being used by C programmers.

You mean '{' and '}' aren't found in many character sets...?

More to the point, '[' and ']' aren't found in certain mainframe (EBCDIC)
charactersets. Other characters are missing from EBCDIC-US as well.

Even worse, there are multiple definitions for some of the characters. '['
and ']' have existed for many years on the TN print train, but somehow that
wasn't good enough to define them in EBCDIC.

According to the card I have here, GX20-1850-2, '{' in EBCDIC is at X'C0'
but the TN print train has it at X'8B', and '}' in EBCDIC at X'D0' and TN
has it at X'9B'.

Also, EBCDIC has both a solid and split vertical bar. Some ASCII tables use
one, and some the other, for the printable representation, and I believe
that has also been a problem with conversion tables.

Just to continue the confusion, EBCDIC has CR, NL, and LF control
characters, X'0D', X'15', and X'25' respectively. Which one should C use as
the '\n' character?

PL/I has the opposite problem, as EBCDIC has a character for the NOT
operator, which ASCII doesn't have.

-- glen

[Christian Bau]

In article <J8*******************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:

Christopher Benson-Manica wrote:

Andreas Kahari <ak*******@freeshell.org> spoke thus:

It is not simply a question of what keyboards are being used
(the standard never mentiones the word "keyboard") but what
character sets are being used by C programmers.

You mean '{' and '}' aren't found in many character sets...?

More to the point, '[' and ']' aren't found in certain mainframe (EBCDIC)
charactersets. Other characters are missing from EBCDIC-US as well.

And before anyone tries to get rid of trigraphs, I would like to hear a
suggestion how to do this without breaking programs that use them.

[Serve La]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bj**********@chessie.cirr.com...

Assuming trigraphs are specified in the standard currently, how much longer do you suppose that will be the case? Are there still enough "short" keyboards out there to justisfy trigraphs?

I've been told that italian and danish keyboards don't support some of C's
common symbols. Personally, I wouldn't be using C if I had to use trigraphs.

[Mark Gordon]

On Fri, 12 Sep 2003 22:51:16 +0100
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

In article <J8*******************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:

Christopher Benson-Manica wrote:

Andreas Kahari <ak*******@freeshell.org> spoke thus:
>It is not simply a question of what keyboards are being used
>(the standard never mentiones the word "keyboard") but what
>character sets are being used by C programmers.
You mean '{' and '}' aren't found in many character sets...?

More to the point, '[' and ']' aren't found in certain mainframe
(EBCDIC) charactersets. Other characters are missing from EBCDIC-US
as well.

And before anyone tries to get rid of trigraphs, I would like to hear
a suggestion how to do this without breaking programs that use them.

Write a program to parse the source and get rid of the trigraphs.
--
Mark Gordon

[Andreas Kahari]

In article
<20******************************@flash-gordon.me.uk>, Mark
Gordon wrote:

On Fri, 12 Sep 2003 22:51:16 +0100
Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

[cut]

And before anyone tries to get rid of trigraphs, I would like to hear
a suggestion how to do this without breaking programs that use them.

Write a program to parse the source and get rid of the trigraphs.

You can't do that with code that is generated automatically and
then interpreted on a non-ASCII system (I don't know if this
arrangement exists).
- I don't like macros, let's do away whith them!
- That will break a lot of old code.
- I'll just write a program that replaces macros with their definition...

Not quite the same maybe.

The point of tri- and digraphs is to make C programming possible
on systems which does not support the ASCII character set, but
that does support ISO 646. If your system does support the
characters that the tri- and digraphs are replacing, then you
are very welcome to substitute them in all your code, but you
probably won't be able to send the code back to its originator
without replacing them again.
--
Andreas Kähäri

[Hallvard B Furuseth]

Andreas Kahari wrote:

Write a program to parse the source and get rid of the trigraphs.
You can't do that with code that is generated automatically and
then interpreted on a non-ASCII system

ASCII has nothing to do with it. The standard says that the source
character set must include all the C characters. They just don't have
to look like they do in the standard. For example, the character ¥ may
be treated by the compiler as if it was a \. If people don't like
that, they can write ??/ instead.

(In practice it is the other way around. The OS was typically typically
written by Americans and thinks it is running on ASCII hardware, but the
site's terminals display ¥ for char(92) = ASCII '\'.)
The point of tri- and digraphs is to make C programming possible
on systems which does not support the ASCII character set,

Almost. It is to allow people on such systems to avoid such hacks, and
to have something to write if certain characters are not readily
available on their keyboards.

--
Hallvard

[Hallvard B Furuseth]

Glen Herrmannsfeldt wrote:

Even worse, there are multiple definitions for some of the characters. '['
and ']' have existed for many years on the TN print train, but somehow that
wasn't good enough to define them in EBCDIC.
What are TN and the TN print train?
Also, EBCDIC has both a solid and split vertical bar. Some ASCII
tables use one, and some the other, for the printable representation,
and I believe that has also been a problem with conversion tables.
I'm curious: Is there a similar problem when converting to Unicode,
or do people agree on which is which in that case?
Just to continue the confusion, EBCDIC has CR, NL, and LF control
characters, X'0D', X'15', and X'25' respectively. Which one should C
use as the '\n' character?

If CR is Carriage Return, I presume it should be \r.

What do EBCDIC NL and LF do?

--
Hallvard

[Hallvard B Furuseth]

I wrote:

What do EBCDIC NL and LF do?

....and are their mappings to Unicode well-defined and agreed upon?

--
Hallvard

[Glen Herrmannsfeldt]

"Hallvard B Furuseth" <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote in
message news:HB**************@bombur.uio.no...

Glen Herrmannsfeldt wrote:

Even worse, there are multiple definitions for some of the characters. '[' and ']' have existed for many years on the TN print train, but somehow that wasn't good enough to define them in EBCDIC.

What are TN and the TN print train?

The traditional IBM printers used a train or chain of characters. The more
usual ones didn't have lower case characters, or other less commonly used
characters. There is one with the Fortran 48 character set, one with the
PL/I 60 character set, and TN has 120, including lower case letters, '[',
']', '{', '}', and a variety of characters for drawing boxes.

Also, EBCDIC has both a solid and split vertical bar. Some ASCII
tables use one, and some the other, for the printable representation,
and I believe that has also been a problem with conversion tables.

I'm curious: Is there a similar problem when converting to Unicode,
or do people agree on which is which in that case?

Just to continue the confusion, EBCDIC has CR, NL, and LF control
characters, X'0D', X'15', and X'25' respectively. Which one should C
use as the '\n' character?

If CR is Carriage Return, I presume it should be \r.

What do EBCDIC NL and LF do?

LF is linefeed, and NL is newline. The ASCII LF character is commonly used
as the C '\n' character, as ASCII doesn't have a newline character. But
EBCDIC does!

I don't know at all what unicode has for control characters.

-- glen

[Chris Torek]

>"Hallvard B Furuseth" <h.b.furuseth(nospam)@usit.uio(nospam).no> wrote in

message news:HB**************@bombur.uio.no...

What are TN and the TN print train?

In article <zsK8b.438909$uu5.77845@sccrnsc04>
Glen Herrmannsfeldt <ga*@ugcs.caltech.edu> writes:The traditional IBM printers used a train or chain of characters.
More specifically, two common kinds of printers were "band" and
"chain" printers. A chain printer is pretty easy to imagine (and
a band printer is pretty much the same thing, using a sort of
rubber-band or metal band instead of interlocking chain pieces).
The chain is just long enough to string completely around the
cogs at the two ends:

[view from above]
_____________________
/| |\
|-o- -o-|
\|___________________|/
[paper goes here]

Behind the chain there are a bunch of tiny hammers, one for each
column that can print a character. The chain goes around and around
in a big loop, and whenever a character on the chain is ready to
print in that position on the paper, the hammer fires, pushing the
chain-link against the paper (with an ink ribbon in between of
course). Once all the characters on a given line have been printed,
the paper is fed up one line, and the next line can be printed.

The operators would get quite mad at you if you told the machine
to print out lines of text that exactly matched the chain sequence.
The reason is that this meant that the chain would rotate around
until *every character was in place simultaneously*, and then ALL
the hammers would fire at once. This could (and often would) break
the chain, sending printer bits flying. (Presumably some chain
printers incorporated logic to slow down such output, thus not
wrecking the machinery.)

In any case, the chains were replaceable, and some print jobs would
require different "print trains" or "print chains". The printer
had to be told which sequence was loaded, and which characters were
physically available.

[In EBCDIC,]LF is linefeed, and NL is newline. The ASCII LF character is commonly used
as the C '\n' character, as ASCII doesn't have a newline character. But
EBCDIC does!

Actually, ASCII code X'0A' (in EBCDIC-ese), 10 decimal, is *both*
linefeed *and* newline. Which you get depends on which ASCII you
are using. Thus, if you are going to have a newline at all, this
is the correct choice (but then you have no separate linefeed,
unlike EBCDIC).
--
In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Jack Klein]

On Fri, 12 Sep 2003 22:51:16 +0100, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote in comp.lang.c:

In article <J8*******************@news20.bellglobal.com>,
Lew Pitcher <Le*********@td.com> wrote:

Christopher Benson-Manica wrote:

Andreas Kahari <ak*******@freeshell.org> spoke thus:
>It is not simply a question of what keyboards are being used
>(the standard never mentiones the word "keyboard") but what
>character sets are being used by C programmers.
You mean '{' and '}' aren't found in many character sets...?

More to the point, '[' and ']' aren't found in certain mainframe (EBCDIC)
charactersets. Other characters are missing from EBCDIC-US as well.

And before anyone tries to get rid of trigraphs, I would like to hear a
suggestion how to do this without breaking programs that use them.

All three of them???

;)

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Tom Zych]

Chris Torek wrote:

The operators would get quite mad at you if you told the machine
to print out lines of text that exactly matched the chain sequence.
The reason is that this meant that the chain would rotate around
until *every character was in place simultaneously*, and then ALL
the hammers would fire at once. This could (and often would) break
the chain, sending printer bits flying. (Presumably some chain
printers incorporated logic to slow down such output, thus not
wrecking the machinery.)

Hmm...I wonder if someone in Fleetwood Mac used to work in
computing?

http://www.buckinghamnicks.net/bn/rumours/thechain.html

;)

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13

[Richard Heathfield]

Jack Klein wrote:

On Fri, 12 Sep 2003 22:51:16 +0100, Christian Bau
<ch***********@cbau.freeserve.co.uk> wrote in comp.lang.c:

And before anyone tries to get rid of trigraphs, I would like to hear a
suggestion how to do this without breaking programs that use them.

All three of them???

;)

<shrug> I've worked on dozens of programs that use trigraphs (for several
separate companies), although not in the last four years or so. I would be
unsurprised to discover myself working in such an environment again, and
I'd like to use C in that environment if I may, so let's allow C to
continue to support these platforms. Thanks.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Villy Kruse]

On 13 Sep 2003 15:13:05 +0200,
Hallvard B Furuseth <h.**********@usit.uio.no> wrote:

Glen Herrmannsfeldt wrote:

Even worse, there are multiple definitions for some of the characters. '['
and ']' have existed for many years on the TN print train, but somehow that
wasn't good enough to define them in EBCDIC.

What are TN and the TN print train?

Also, EBCDIC has both a solid and split vertical bar. Some ASCII
tables use one, and some the other, for the printable representation,
and I believe that has also been a problem with conversion tables.

I'm curious: Is there a similar problem when converting to Unicode,
or do people agree on which is which in that case?

Just to continue the confusion, EBCDIC has CR, NL, and LF control
characters, X'0D', X'15', and X'25' respectively. Which one should C
use as the '\n' character?

If CR is Carriage Return, I presume it should be \r.

What do EBCDIC NL and LF do?

By them selves nothing, only when sent to a device they may do something.
In the EBCDIC world and IBM/360 in particular neither was used to control
the printer.

Newline is next line at the beginning of line. Line feed is next line same
character position. In ASCII you emulate the newline function using the
sequence CR,LF. In the C lagnuage one of them has (arbitrarily) been used
as the '\n' character.

Villy

[Villy Kruse]

On Sat, 13 Sep 2003 10:22:27 +0000 (UTC),
Andreas Kahari <ak*******@freeshell.org> wrote:

The point of tri- and digraphs is to make C programming possible
on systems which does not support the ASCII character set, but
that does support ISO 646. If your system does support the
characters that the tri- and digraphs are replacing, then you
are very welcome to substitute them in all your code, but you
probably won't be able to send the code back to its originator
without replacing them again.

On all the unix systems where this was relevant you would need all the
characters marked as national use in ISO646 anyway for the unix shell
and the other unix utilities, so trigraphs wasn't solving anything
there anyway. MS-DOS, another widely used system with a C compiler,
never used national variations of ISO646.

It is just a matter of learning that '{|}' prints as 'äöü' and these
characters are not letters.
Villy

[Villy Kruse]

On Sat, 13 Sep 2003 08:28:32 +0200,
Serve La <[e-mail]> wrote:

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:bj**********@chessie.cirr.com...

Assuming trigraphs are specified in the standard currently, how much

longer do

you suppose that will be the case? Are there still enough "short"

keyboards

out there to justisfy trigraphs?

I've been told that italian and danish keyboards don't support some of C's
common symbols. Personally, I wouldn't be using C if I had to use trigraphs.

They are available by using ackward key strokes. When you add accented
letters to a 102 key keyboard something has to give, and the little used
symbols in regular text like {}[]|\ will be the first to go.
Villy

[Richard Bos]

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:

And before anyone tries to get rid of trigraphs, I would like to hear a
suggestion how to do this without breaking programs that use them.

Use digraphs instead. Trigraphs are an abomination that can bugger up
your output even on computers that don't need them. Digraphs are much
more programmer-friendly.

Richard

[Andreas Kahari]

In article <3f*****************@news.nl.net>, Richard Bos wrote:
[cut]

Use digraphs instead. Trigraphs are an abomination that can bugger up
your output even on computers that don't need them. Digraphs are much
more programmer-friendly.

All trigraphs does not have digraph equivalents, such as the
trigraphs for '~' and '^'.

--
Andreas Kähäri

[Richard Bos]

Tom Zych <tz******@pobox.com> wrote:

Lew Pitcher wrote:

More to the point, '[' and ']' aren't found in certain mainframe (EBCDIC)
charactersets. Other characters are missing from EBCDIC-US as well.

Ecch. EBCDIC. COBOL. Trigraphs. gets(). void main. The ugly side of
computer science...

You seem to be confusing some things. Trigraphs, EBCDIC and COBOL are
ugly constructs, and not, from a C programmer's POV, very well thought
out, but they serve their purpose and in the case of trigraphs and
EBCDIC are even compatible with reliable C programming.
gets() and void main(), OTOH, are a different kettle of fish. They are
not a good idea, never were a good idea, and never will be a good idea,
no matter what kind of big iron you're trying to program on - and they
should be avoided by every serious C programmer.

Richard

[Richard Bos]

Andreas Kahari <ak*******@freeshell.org> wrote:

In article <3f*****************@news.nl.net>, Richard Bos wrote:
[cut]

Use digraphs instead. Trigraphs are an abomination that can bugger up
your output even on computers that don't need them. Digraphs are much
more programmer-friendly.

All trigraphs does not have digraph equivalents, such as the
trigraphs for '~' and '^'.

True, but AFAIK <iso646.h> does have alternatives for all of those.
Ugly, I'll grant you, but not as phenomenally disbeatific as trigraphs.

Richard

[LibraryUser]

Glen Herrmannsfeldt wrote:

.... snip ...
The advantage of chain printers is that for smaller character
sets you can put more copies of each character on, and it will
print faster. There are even chains with only numbers and
number related punctuation. All the older high level languages
used upper case characters only. It was common for the printer
to map lower case to upper case, which made some debugging hard.
The compiler would complain about something that looked just fine
on the printout.

In those days I had a filter for my printouts, which would
overprint all upper case characters. When things like MX80
printers became available I would normally prefer them for the
listings, because they could handle lower case. Then we got some
sort of matrix line printer that basically had a comb, and
printed a matrix by shuttling the comb back and forth. Sounded
like a herd of screeching banshees, but at least it was faster.

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

[Hallvard B Furuseth]

Richard Bos wrote:

Andreas Kahari <ak*******@freeshell.org> wrote:

All trigraphs does not have digraph equivalents, such as the
trigraphs for '~' and '^'.

True, but AFAIK <iso646.h> does have alternatives for all of those.

The only problem is \ inside strings and character constants. Digraphs
and macros don't work there. Though by the time trigraphs arrived, I
had long ago learned to read Ø as \ (or vice versa), and I still prefer
'Øn' over '??/n'. Not that it matters now, when latin-1 is here.

--
Hallvard

[Joona I Palaste]

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no> scribbled the following:

Richard Bos wrote:

Andreas Kahari <ak*******@freeshell.org> wrote:

All trigraphs does not have digraph equivalents, such as the
trigraphs for '~' and '^'.
True, but AFAIK <iso646.h> does have alternatives for all of those.

The only problem is \ inside strings and character constants. Digraphs
and macros don't work there. Though by the time trigraphs arrived, I
had long ago learned to read Ø as \ (or vice versa), and I still prefer
'Øn' over '??/n'. Not that it matters now, when latin-1 is here.

"Øn", isn't that Norwegian for "The Island" or something?

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"To err is human. To really louse things up takes a computer."
- Anon

[Andreas Kahari]

In article <bk**********@oravannahka.helsinki.fi>, Joona I Palaste wrote:

Hallvard B Furuseth <h.b.furuseth(nospam)@usit.uio(nospam).no>
scribbled the following:

[cut]

'Øn' over '??/n'. Not that it matters now, when latin-1 is here.

"Øn", isn't that Norwegian for "The Island" or something?

Hi Joona.

At least the Swedish word for it, using Norwegian (and Danish)
script.
--
Andreas Kähäri

[lawrence.jones]

Glen Herrmannsfeldt <ga*@ugcs.caltech.edu> wrote [quoting Chris Torek]:

I believe at least on the 1403 that the spacing of the characters on the
train is slightly larger than the print column spacing, so that can't
happen.

You're correct that the character spacing on the chain or train was
slightly wider than the print column spacing, but that wasn't done to
avoid chain breakage, it was done to reduce the peak current demand --
trying to fire all the hammers at exactly the same time would require an
enormous amount of energy. Nonetheless, printing the characters in the
order they appeared on the chain (which was called the "chain break
pattern" for obvious reasons) would still subject the chain to a great
deal of mechanical stress and could cause breakage.

Actually, ASCII code X'0A' (in EBCDIC-ese), 10 decimal, is *both*
linefeed *and* newline. Which you get depends on which ASCII you
are using. Thus, if you are going to have a newline at all, this
is the correct choice (but then you have no separate linefeed,
unlike EBCDIC).

I always thought that was just a Unix/C convention, and wasn't part of the
ASCII standard.

It definitely was (and is!) part of the ASCII standard. I think
allowing the vertical format effectors (LF, FF, and VT) to optionally
affect the horizontal position as well was added in the 1977 revision
and then deprecated in the 1986 revision (which is still in effect,
having just been reaffirmed last year).

-Larry Jones

In short, open revolt and exile is the only hope for change? -- Calvin

[Hallvard B Furuseth]

Joona I Palaste wrote:

"Øn", isn't that Norwegian for "The Island" or something?

No, 'øya' (øy : island, -a: 'female' the).

However, 'ø' is 'island' in some dialects, and I wouldn't be surprised
if one of them uses '-n' for as "male 'the'" instead of '-en' in this
case. Someone close to Sweden, for example.

--
Hallvard

[Tom Zych]

Richard Bos wrote:

Tom Zych <tz******@pobox.com> wrote:

Ecch. EBCDIC. COBOL. Trigraphs. gets(). void main. The ugly side of
computer science...

You seem to be confusing some things. Trigraphs, EBCDIC and COBOL are
ugly constructs, and not, from a C programmer's POV, very well thought
out, but they serve their purpose and in the case of trigraphs and
EBCDIC are even compatible with reliable C programming.
gets() and void main(), OTOH, are a different kettle of fish. They are
not a good idea, never were a good idea, and never will be a good idea,
no matter what kind of big iron you're trying to program on - and they
should be avoided by every serious C programmer.

All true. I was just lumping them all under the more inclusive
category of "things I find revolting and intend to avoid forever" :)

Though I suppose I might use trigraphs if I ever try my hand at the
IOCCC ;)

--
Tom Zych
This email address will expire at some point to thwart spammers.
Permanent address: echo 'g******@cbobk.pbz' | rot13