<iso646.h>
Doug Gwyn
<iso646.h> -- macros for use in place of certain tokens that are
not expressible in the invariant subset of ISO 646:1991
public-domain implementation for all versions of C
last edit: 13-Dec-1992 Gw...@ARL.Army.Mil
complies with the following standard:
ANSI/ISO 9899:1990[1992] (as expected to be amended in 1993)
Usage: ??=include <iso646.h>
Notes: The C standard has always required that the following
trigraphs be supported in translation phase 1:
??= mapped to #
??( mapped to [
??/ mapped to \
??) mapped to ]
??' mapped to ^
??< mapped to {
??! mapped to |
??> mapped to }
??- mapped to ~
The forthcoming normative addendum to the C standard that
requires conforming implementations to provide <iso646.h>
also requires support in translation phases 3..4 for the
following preprocessing tokens:
%: alternate spelling for #
%:%: alternate spelling for ##
It also requires support in translation phases 3..7 for the
following preprocessing tokens:
<% alternate spelling for {
%> alternate spelling for }
<: alternate spelling for [
:> alternate spelling for ]
The C standard also requires that the "difficult" characters
be somehow provided in both the basic source and execution
character sets, regardless of the provision of trigraph,
digraph, and macro alternatives for these characters.
It is suggested that all C programmers avoid use of the
following identifiers in their programs, in case somebody
later needs to use <iso646.h> in maintaining the programs.
*/
#define or ||
#define bitor |
#define or_eq |=
#define xor ^
#define xor_eq ^=
#define compl ~
#define and &&
#define bitand &
#define and_eq &=
#define not !
#define ne !=
Tim McDaniel
What insane asylum added digraphs to the existing trigraph mess, and
also said that the "difficult" characters have to exist anyway? What's
the point of trigraphs and digraphs then?
What fool made these identifiers ("or", "ne", ...) reserved? "If you
want PL/I ..." and all that. (Designing a language from scratch, I
would have used "and", "or", et cetera. But C didn't, but now we have
both.)
--
Tim McDaniel
Internet: mcdaniel@{grex,m-net}.ann-arbor.mi.us, mcda...@adi.com
John F. Woods
>What is a "normative addendum"?
It seems to be the ISO's way of fixing standards that aren't broken ;-).
>What insane asylum added digraphs to the existing trigraph mess, and
>also said that the "difficult" characters have to exist anyway? What's
>the point of trigraphs and digraphs then?
The point of trigraphs is that *terminals* don't have to have the "difficult"
characters, and that the "difficult" characters don't need to have the same
representations between implementations (and may well not, in an environment
where national characters have gobbled up the ASCII values for the "difficult"
characters). The chief "use" of trigraphs seems to be as an exchange medium;
as long as two sites agree at least on the "easy" characters' values, then a
trigraphed source on tape can be written at one site and read at the other.
Of course, why it was necessary to do violence to the language in order to
avoid having an occasional tape accompanied by a handwritten note and/or a
quickie conversion utility has escaped many people...
>What fool made these identifiers ("or", "ne", ...) reserved?
As near as I can tell, no one made those identifiers reserved; Doug Gwyn seems
to have merely suggested them as an alternative for some reason only he can
definitively comment on (but I'll bet it was to head off a THIRD (and FOURTH
and FIFTH...) insane incomprehensible mapping scheme ("characters not available
in all national character sets will be encoded as :::::0000000000:::::, where
the string of 0's shall be replaced with a CCITT checksum of the Latin-1 name
of the original character....")).
Sakari Jalovaara
Jeez, Doug, for a second there I actually believed you were seriously
suggesting people should use `not' for `!'. But are those digraphs
really going to be suggested to be added to C?
j...@ksr.com (John F. Woods):
> the "difficult" characters don't need to have the same representations
> between implementations (and may well not, in an environment where
> national characters have gobbled up the ASCII values for the
> "difficult" characters).
Does anyone, anywhere on the world know of a serious implementation of
C that uses mostly ASCII but doesn't recognize the value 0x7b as left
brace? (Totally regardless of what that character looks like on a
terminal - on mine, it looks like an 'a' with two dots; compilers have
*no* problems with that.)
A language standard simply should not concern itself with what
characters look like on various terminals. The "national characters
need trigraphs" argument is just plain WRONG.
> Of course, why it was necessary to do violence to the language in
> order to avoid having an occasional tape accompanied by a
> handwritten note and/or a quickie conversion utility has escaped
> many people...
Exactly! The C standard could even have required C systems to be able
to process ASCII source code; whether that is implemented by the native
character set, as a compiler option, or as a separate program, is up to
the implementation. As is the exact key sequence required to enter a
"left brace" token (even if it is ??( or $$( and displays as three
characters on some terminals!)
Trigraphs are BAD and UNNECESSARY.
Digraphs are WORSE and UNNECESSARY.
++sja
Larry Jones
> What is a "normative addendum"?
ISO allows for two different types of addenda (appendices): normative
and non-normative. A normative addendum is an actual part of the
standard, a non-normative addendum is explanatory comments which are not
part of the official standard. Addenda can be part of the standard from
the very beginning or can be added after the fact to modify or clarify
an existing standard.
> What insane asylum added digraphs to the existing trigraph mess, and
> also said that the "difficult" characters have to exist anyway? What's
> the point of trigraphs and digraphs then?
>
> What fool made these identifiers ("or", "ne", ...) reserved? "If you
> want PL/I ..." and all that. (Designing a language from scratch, I
> would have used "and", "or", et cetera. But C didn't, but now we have
> both.)
This is a bit of a contentious issue, so I will try to keep my personal
opinions in check until after I relate the facts.
First, a bit of history. Back when X3J11 was working on the ANSI C
Standard, one of the deficiencies of C that the committee was asked to
address was the problem that C used most of the ASCII character set but
many machines do not have all of those characters available. In
particular, when ASCII (which is a US standard [X3.4]) was
internationalized into ISO 646, a number of characters (0x40, 0x5b -
0x53, 0x60, and 0x7b-7e) were designated as "National or
application-oriented graphic characters". This means that any nation
can have a national standard that specifies the meaning of these
characters as well as individual applications can define them as they
wish. Also, character 0x23 is allowed to be defined as either the
(British) pound sign or the number sign, and 0x24 is allowed to be
defined as either the (US) dollar sign or a generic currency symbol.
In the USA, the ASCII standard defines these characters as commercial
at (@), left square bracket ([), reverse slant (\), right square
bracket (]), circumflex accent (^), grave accent (`), left curly brace
({), vertical line (|), right curly bracket (}), tilde (~), number sign
(#), and dollar sign ($). Other nations have similar national
standards that define these characters quite differently.
X3J11 felt that it was important, if the C Standard was to be an
international standard, to be able to write a C program using only
those characters that were guaranteed to exist -- those characters
defined in ISO 646 that are NOT redefinable. We also felt that it was
important to be able to convert to and from that notation very easily;
in particular, it should be possible to do the conversion without
having to parse the C program so that a simple text substitution (e.g.
a sed script) is sufficient to convert back and forth. We tried to
come up with digraphs, but there aren't enough to meet these criteria.
Thus, trigraphs. Our thoughts at the time were that trigraphs would be
most useful for moving programs from one environment to another; we
assumed that most systems had *some* way to represent these characters
that would be used locally, although trigraphs could be used there as
well. And, of course, a user is always free to create a header with
macros for the difficult characters and use those instead (although
that won't work inside character or string literals). X3J11 recognized
that trigraphs were a bad solution to a vanishing problem, but it *is*
a problem and there didn't seem to be any better solutions.
At the same time that X3J11 was finishing up the ANSI C Standard, ISO
began work on an International Standard for C as Working Group 14 under
Subcommittee 22. The Danish delegation remarked that they did not, in
fact, have a way of representing those characters on their terminals,
trigraphs were ugly, and they would like some better method. What they
proposed was a collection of digraphs and keywords. X3J11 examined
their proposals and pointed out a number of objections, both technical
and aesthetic, pointed out that trigraphs were a solution to the
problem, and declined to make any changes to the (draft) ANSI Standard.
The Danes then revised their proposal and the cycle repeated a number
of times. Eventually the ANSI C Standard was approved as it appears
today and the ISO C Standard was also approved with identical technical
content for expediency although a number of delegations had issues that
they wanted to have addressed via normative addenda later.
Now, it's later. Denmark has brought a number of proposals to WG14,
asking for approval as a normative addendum. X3J11 in it's role as
Technical Advisory Group to the US delegation has continued to advise
against adopting any of the proposals both because of technical
conflicts and because we do not believe that they add any significant
value to the C language. In the meantime, however, both ANSI and ISO
have also started projects to standardize C++, the Danes made a similar
proposal to those committees, and it has been accepted. SC22, the
parent committee of both the C and C++ working groups, has resolved that
the Danes' concern be addressed and further charged both working groups
with avoiding gratuitous incompatibilities between C and C++. At the
meeting last week, X3J11 finally gave up and recommended that the US
vote to accept the current Danish proposal as a proposed normative
addendum to the ANSI/ISO standard. The substance of that proposal
should be fairly obvious from Doug's posted implementation.
If you think this is a crock, then what we need to do is to get it shot
down by a wide variety of countries at the ISO SC22 level rather than
having the big bad USA picking on poor little Denmark which is how some
people have viewed X3J11's objections. For additional information, I
suggest you contact the chair of WG14, P. J. Plauger (p...@plauger.com).
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH 45150-2789 513-576-2070
larry...@sdrc.com or ...uunet!sdrc!larry.jones
Let's just sit here a moment... and savor the impending terror. -- Calvin
Paul Eggert
if <iso646.h> is not included? If so, some strictly conforming ANSI C
programs will not conform to the proposed new standard. As a trivial
example, the program
#define x %:
int main() { return 0; }
is strictly conforming ANSI C, but it would not conform to the proposed
new standard. Surely it is important that existing conforming programs
not change in meaning because of the proposed revisions.
peter curran
Re: <iso646.h>
It seems to me that this is a reasonable solution (if I understand
it correctly).
Note that if your code does not include the <iso646.h> header file,
it does not affect you at all. This is a key point, and differs from
the trigraph situation, where anyone can be bitten (although the
chances are pretty small), whether s/he knows about them or not.
On the other hand, if you are in an environment where some or all of
the "national" characters have been redefined, making the standard
ASCII graphics unavailable, there are now standard substitutions that
are reasonably readable (at least in English!), less ugly than
trigraphs, and that you can get used to consistently in all code.
Without this proposal, everyone affected by the problem would [do] no
doubt adopt their own macros, degrading the readability of their code.
Peter Curran
Usenet: peter....@canrem.com RIME: CRS (#118)
---
ş DeLuxeı 1.25 #12339 ş
--
Canada Remote Systems - Toronto, Ontario
World's Largest PCBOARD System - 416-629-7000/629-7044
der Mouse
> [stuff explaining why <iso646.h> exists]
> If you think this is a crock, then what we need to do is to get it
> shot down by a wide variety of countries at the ISO SC22 level rather
> than having the big bad USA picking on poor little Denmark which is
> how some people have viewed X3J11's objections.
Feh. Me, what I'll do is what I always do when someone promulgates a
stupid standard: ignore it. I'll proceed to use "or" as an identifier
whenever it seems to be the appropriate name. I'll use ??= in strings
when it seems appropriate. And if someone has problems porting my code
because of this, that's too bad, but I refuse to cripple myself because
others insist on crippling themselves. At least this time, a new
header is required before the silliness becomes programmer-visible.
der Mouse
Sakari Jalovaara
> On the other hand, if you are in an environment where some or all of
> the "national" characters have been redefined, making the standard
> ASCII graphics unavailable,
So far, there has been no proof that such an environment exists.
++sja
Erik Naggum
It exists, but programmers never experience it. Good C programmers
never write natural language text in the source files, anyway, and so
have _no_ problems with the soi disant "national characters". Bad and
mediocre C programmers who have a problem with national characters,
should load a new font or buy a new terminal, not impose trigraph and
digraph bullshit on the world. Programmers and/or companies hiring them
who can't afford a new terminal with the proper character set should be
put on a black list published widely within the user communities.
Enough of this stupidity, already.
It turned out that there is _one_ Norwegian, in a little over 4,200,000,
who was sufficiently interested in the work in progress in JTC 1/SC 22
to want to establish a SC 22 "peer group" who could vote on SC 22 work,
and now we don't even have O (Observatory) status in SC 22. If the same
is true for Denmark, and I have some reason to think it is, you should
direct your flames towards Keld Simonsen <ke...@dkuug.dk>, and ask him to
buy a new terminal instead of harrassing the C community with his funny
proposals.
If he can't afford it, despite drawing massive funds from the Nordic
Council for his "7-bit character set backward compatibility" dinosaur,
we could all send $1 to Danish Standards and request that he get a new
terminal, or a new machine if enough people send money, as a belated
Christmas present from The Net. He may not enjoy it, but I'm sure the
entire C community will, and for many, many years to come.
Happy New Year, C community! Good grief.
Best regards,
</Erik>
--
Erik Naggum ISO 8879 SGML +47 295 0313
ISO 10744 HyTime
<er...@naggum.no> ISO 9899 C Memento, terrigena
<SG...@ifi.uio.no> ISO 10646 UCS Memento, vita brevis