# and %:%: tokens
sa...@bear.com
also says that a preprocessing line begins with a # token.
So is it leagal to write
%:%: include <stdio.h>
?
My Sun compiler does not accept it. So is it new in C9X?
Thank you,
Saroj Mahapatra
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Nick Maclaren
In article <707s37$ug0$1...@nnrp1.dejanews.com>, sa...@bear.com writes:
|> C9x says that # token is equivalent to %:%: token (except spelling). It
|> also says that a preprocessing line begins with a # token.
|>
|> So is it leagal to write
|> %:%: include <stdio.h>
|> ?
|>
|> My Sun compiler does not accept it. So is it new in C9X?
Yes.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Larry Jones
>
> In article <707s37$ug0$1...@nnrp1.dejanews.com>, sa...@bear.com writes:
> |> C9x says that # token is equivalent to %:%: token (except spelling). It
> |> also says that a preprocessing line begins with a # token.
> |>
> |> So is it leagal to write
> |> %:%: include <stdio.h>
> |> ?
> |>
> |> My Sun compiler does not accept it. So is it new in C9X?
>
> Yes.
No. It was new in ISO/IEC 9899/AMD1:1995, an amendment to the original
C standard (which has not been widely implemented).
-Larry Jones
Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin
Nick Maclaren
Larry Jones <larry...@sdrc.com> wrote:
>Nick Maclaren wrote:
>>
>> In article <707s37$ug0$1...@nnrp1.dejanews.com>, sa...@bear.com writes:
>> |> C9x says that # token is equivalent to %:%: token (except spelling). It
>> |> also says that a preprocessing line begins with a # token.
>> |>
>> |> So is it leagal to write
>> |> %:%: include <stdio.h>
>> |> ?
>> |>
>> |> My Sun compiler does not accept it. So is it new in C9X?
>>
>> Yes.
>
>No. It was new in ISO/IEC 9899/AMD1:1995, an amendment to the original
>C standard (which has not been widely implemented).
I KEEP forgetting about that thing (which I have also never seen)!
As far as I know, the only compiler that has implemented it is gcc,
but there may well be some I have not come across. Are there any
others?
John Hauser
> C9x says that # token is equivalent to %:%: token (except spelling).
My copy of the C9x draft says that the tokens # and %: are equivalent,
and that ## and %:%: are equivalent. This has in theory been true
since Amendment 1 of C90.
> So is it leagal to write
> %:%: include <stdio.h>
> ?
Try
%: include <stdio.h>
although your compiler (preprocessor) may still not accept it.
- John Hauser
Paul Eggert
>As far as I know, the only compiler that has implemented it is gcc,
Yes, I contributed digraph support to GCC. It may be amusing for
people to know that I was first inclined to have digraphs like `%:'
disabled by default in GCC, as they were a minor silent change to C89.
However, Richard Stallman convinced me that they should be enabled.
He's big on conforming to standards, even their silly parts, so long as
it's not too much trouble.
Trigraphs are another story -- they _do_ cause too much trouble, so
they're disabled by default in GCC.
The jury's still out on \u escapes. I haven't had time to read the
latest committee rewrite, which I hope has fixed the serious problems
in the earlier C9x draft.
Douglas A. Gwyn
> ...
> > In article <707s37$ug0$1...@nnrp1.dejanews.com>, sa...@bear.com writes:
> > |> C9x says that # token is equivalent to %:%: token (except spelling). It
> > |> also says that a preprocessing line begins with a # token.
> > |> %:%: include <stdio.h>
> C standard (which has not been widely implemented).
I'm away from my office at the moment, so I can't check this,
but Amendment 1 was *not* supposed to say that.
It introduced *digraphs* not *tetragraphs*.
(This was at the insistence of Denmark,
which reportedly had keyboards where trigraphs
actually had to be used and wanted something
involving fewer keystrokes.)
sa...@bear.com
egg...@twinsun.com (Paul Eggert) wrote:
> nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>
> >As far as I know, the only compiler that has implemented it is gcc,
>
> Yes, I contributed digraph support to GCC. It may be amusing for
> people to know that I was first inclined to have digraphs like `%:'
> disabled by default in GCC, as they were a minor silent change to C89.
> However, Richard Stallman convinced me that they should be enabled.
> He's big on conforming to standards, even their silly parts, so long as
> it's not too much trouble.
>
I agree with Stallman.
> Trigraphs are another story -- they _do_ cause too much trouble, so
> they're disabled by default in GCC.
>
Why is that so? Is it because trigraphs replace the trigraph sequence
anywhere (including in the middle of a token or string literal), but
digraphs can only be a full token?
> The jury's still out on \u escapes. I haven't had time to read the
> latest committee rewrite, which I hope has fixed the serious problems
> in the earlier C9x draft.
>
I remember you complaining about the range of UCNs (they are not
allowed to be in certain range) (my memory may be wrong). What exactly
is the problem with UCNs?
BTW, why were UCNs allowed in the identifiers? I can understand them
in string literals or character constants.
Paul Eggert
>> Trigraphs are another story -- they _do_ cause too much trouble, so
>> they're disabled by default in GCC.
>Why is that so? Is it because trigraphs replace the trigraph sequence
>anywhere (including in the middle of a token or string literal), but
>digraphs can only be a full token?
Yes.
>What exactly is the problem with UCNs?
In CD1 the main problem was that silly stringizing tricks could force
the translator to convert characters from external form to Unicode and
back, which is unrealistic in many cases, and impossible in at least
one encoding (ISO-2022-JP). I haven't yet had a chance to see how CD2
fixed this.
Jens Schweikhardt
# Nick Maclaren wrote:
#>
#> In article <707s37$ug0$1...@nnrp1.dejanews.com>, sa...@bear.com writes:
#> |> C9x says that # token is equivalent to %:%: token (except spelling). It
#> |> also says that a preprocessing line begins with a # token.
#> |>
#> |> So is it leagal to write
#> |> %:%: include <stdio.h>
#> |> ?
#> |>
#> |> My Sun compiler does not accept it. So is it new in C9X?
#>
#> Yes.
# No. It was new in ISO/IEC 9899/AMD1:1995, an amendment to the original
# C standard (which has not been widely implemented).
But # is spelled %: -- %:%: is ##, the concatenation operator.
So even if the Sun compiler implements digraphs, the original
won't compile.
Regards,
Jens
--
Jens Schweikhardt http://www.shuttle.de/schweikh/
SIGSIG -- signature too long (core dumped)
Clive D.W. Feather
<egg...@twinsun.com> writes
>Yes, I contributed digraph support to GCC. It may be amusing for
>people to know that I was first inclined to have digraphs like `%:'
>disabled by default in GCC, as they were a minor silent change to C89.
>Trigraphs are another story -- they _do_ cause too much trouble, so
>they're disabled by default in GCC.
I don't see the significant difference.
>However, Richard Stallman convinced me that they should be enabled.
>He's big on conforming to standards, even their silly parts, so long as
>it's not too much trouble.
What a bad attitude.
--
Clive D.W. Feather | Regulation Officer, LINX | Work: <cl...@linx.org>
Tel: +44 1733 705000 | (on secondment from | Home: <cd...@i.am>
Fax: +44 1733 353929 | Demon Internet) | <http://i.am/davros>
Written on my laptop; please observe the Reply-To address
Paul Eggert
>>Trigraphs are another story -- they _do_ cause too much trouble, so
>>they're disabled by default in GCC.
>I don't see the significant difference.
Trigraphs make it difficult to write programs that deal with C source code.
The basic problem is that, in practice, they screw up tokenization.
It's not just a matter of implementation difficulty; it's a matter of
correctness. For example, the program `yacc' reads and outputs quasi-C
code. Should `yacc' recognize "??/"" as a valid string? If a string
happens to have a trigraph in it, should `yacc' reformat the string to
avoid the trigraph when outputting the string? Arguments could be made
either way.
In practice, most people don't care about such issues, since only
standards nerds and museum curators use trigraphs. On the contrary,
when people happen to write trigraphs in their strings, they usually
don't want them to be interpreted as trigraphs. This is why GCC
disables trigraphs by default. The only complaints the GCC maintainers
get from users about this is that GCC doesn't complain about trigraphs
more loudly than it does.
In practice, digraphs don't screw up tokenization like trigraphs do, so
the above issues are much less important for digraphs. That's why GCC
supports digraphs; it doesn't even give you an option to turn them off.
Paul Eggert
>Paul Eggert <egg...@twinsun.com> writes
>>Richard Stallman convinced me that [digraphs] should be enabled.
>>He's big on conforming to standards, even their silly parts, so long as
>>it's not too much trouble.
>What a bad attitude.
Which part don't you like? Surely not the ``conforming to standards'' part.
Before anybody jumps on Stallman too much, I should mention that the
above is my vague paraphrase from memory of a long-ago email conversation,
and it may not correspond to exactly what Stallman thinks.
Nick Maclaren
In article <70ev59$csf$1...@shade.twinsun.com>, egg...@twinsun.com (Paul Eggert) writes:
|> "Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
|>
|> >>they're disabled by default in GCC.
|>
|> >I don't see the significant difference.
|>
|> Trigraphs make it difficult to write programs that deal with C source code.
|> The basic problem is that, in practice, they screw up tokenization.
That is not the only trouble, unfortunately. They also make it
tricky to generate C code automatically.
|> In practice, digraphs don't screw up tokenization like trigraphs do, so
|> the above issues are much less important for digraphs. That's why GCC
|> supports digraphs; it doesn't even give you an option to turn them off.
This is almost certainly because they can't occur in strings. They
are tokens, not characters.
I think that trigraphs were a mistake, too, and there are several
solutions that would have been better. Unfortunately, there was
some bizarre politics involved, and we got inflicted with something
that was neither fish, flesh, fowl nor good red herring.
I certainly think that gcc's diagnostics are good, but am less
certain that disabling trigraphs by default is. I would tend to
favour making them an error by default - and, yes, I do mean that
you would have to specify either -no-trigraphs or -iso-trigraphs if
you have any such character sequence in your code, or compilation
would fail.
Clive D.W. Feather
<egg...@twinsun.com> writes
>>>Richard Stallman convinced me that [digraphs] should be enabled.
>>>He's big on conforming to standards, even their silly parts, so long as
>>>it's not too much trouble.
>
>>What a bad attitude.
>
>Which part don't you like? Surely not the ``conforming to standards'' part.
No, the "so long as it's not too much trouble". Either conform to the
standard, or don't claim that you've tried.
>Before anybody jumps on Stallman too much, I should mention that the
>above is my vague paraphrase from memory of a long-ago email conversation,
>and it may not correspond to exactly what Stallman thinks.
Unfortunately, it matches other things I've heard.
James Kuyper
...
> In practice, most people don't care about such issues, since only
> standards nerds and museum curators use trigraphs. On the contrary,
Whether trigraphs were a good idea is debatable, and I have to agree
they are excessively clumsy, and a hazard in the creation of string
literals. However, you shouldn't imply that they were created for no
reason. There are real systems where people write real C code, despite
the fact that one or more of the characters designated by trigraphs
cannot be typed in directly. Trigraphs are what make that possible.
IIRC, most implementations using EBCDIC coding fall into this category,
as well as many implementations using one of the non-US versions of
ASCII.
Perhaps you're trying to imply that such machines exist only on display
in museums? That's not the impression I got from the last go-round on
trigraphs in this newsgroup.
Paul Eggert
>Either conform to the standard, or don't claim that you've tried.
GCC conforms to even the silly trigraphs part of the C standard
if you compile with the special options `-ansi -pedantic'.
But normally it doesn't conform, as this is more useful in practice.
My impression is that most compilers are like GCC in this respect.
For example, Sun C doesn't conform to the standard unless you compile
with `-Xc'. The exact set of features that are considered to be
``silly'' depends on the implementation, of course, but it's safe to
say that trigraphs are generally regarded to be a dubious part of the
existing standard.
So most implementers seem to share Stallman's opinion of the standard.
That is, they conform to the standard, unless it's too much trouble;
and in the troublesome cases they ask their users ``are you sure?'' and
get confirmation before operating in the silly way that the standard
prescribes.
Nick Maclaren
Paul Eggert <egg...@twinsun.com> wrote:
>"Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
>
>>Either conform to the standard, or don't claim that you've tried.
>
>GCC conforms to even the silly trigraphs part of the C standard
>if you compile with the special options `-ansi -pedantic'.
>But normally it doesn't conform, as this is more useful in practice.
>
>My impression is that most compilers are like GCC in this respect.
>For example, Sun C doesn't conform to the standard unless you compile
>with `-Xc'. The exact set of features that are considered to be
>``silly'' depends on the implementation, of course, but it's safe to
>say that trigraphs are generally regarded to be a dubious part of the
>existing standard.
Not quite. Most of them seem to implement the whole language, but
to define extra names in the headers by default. It isn't so much
that they exclude "silly" features as they prefer to provide the
POSIX/whatever facilities by default.
HP-UX (up to 9, at least) is a bizarre exception. It compiles in
K&R mode by default, and you have to specify that you want standard C.
You then GET standard C, and need to specify another symbol to get the
extra symbols.
In fact, the only C compilers that I have used that give a decently
clean standard C option are gcc, CSet/2, Norcroft C and HP C. Most
others seem to have a revolting number of extensions and pollute
the namespace excessively even when in the purest of standard modes.
It doesn't make it easy developing seriously portable code on other
systems :-(
Paul Eggert
>Paul Eggert wrote:
>> In practice, most people don't care about such issues, since only
>> standards nerds and museum curators use trigraphs.
>There are real systems where people write real C code, despite
>the fact that one or more of the characters designated by trigraphs
>cannot be typed in directly.
Yes, but few people benefit from trigraphs (and the benefits are small),
whereas many people are hurt by them (and the harms can be large, since
trigraphs are a silent change to the language); so on balance they are
a mistake.
>IIRC, most implementations using EBCDIC coding fall into this category,
Trigraphs don't solve the problem for EBCDIC, since they don't address
the problem of `!'.
In practice, what I and my EBCDIC correspondents do is make sure we
have a 1-1 correspondence between the portable C character set and
whatever local variant of EBCDIC obtains, and stick to that
correspondence. I haven't had to use EBCDIC C myself for nearly twenty
years, but if I had to use it again I'd continue to use this solution.
It worked for me in 1980, and would continue to work for me now.
> Perhaps you're trying to imply that such machines exist only on display
> in museums? That's not the impression I got from the last go-round on
> trigraphs in this newsgroup.
I plead guilty to using mild hyperbole in my phrase ``museum curators''.
(though I notice that you didn't complain about ``standards nerds'' :-).
But if you go back and re-read the last go-round, you'll see that it's
not necessary to use trigraphs to work with EBCDIC, and that many
serious EBCDIC users avoid trigraphs. This is hardly a ringing
endorsement of the need for trigraphs.
James Russell Kuyper Jr.
>
> James Kuyper <kuy...@wizard.net> writes:
>
> >Paul Eggert wrote:
> >> In practice, most people don't care about such issues, since only
> >> standards nerds and museum curators use trigraphs.
> I plead guilty to using mild hyperbole in my phrase ``museum curators''.
> (though I notice that you didn't complain about ``standards nerds'' :-).
Hey, it's better than 'pedant'! However, to be a real standards nerd,
I'd have to be doing some of the serious work on the standard. I'm just
a very vocal onlooker. Maybe next time round I'll take an active part.
I've never used trigraphs, and I pity anyone who has to. I've also never
run into problems from their side-effects; one consecutive '?' is enough
for me in any text string I've ever written.
Douglas A. Gwyn
> Yes, but few people benefit from trigraphs (and the benefits are small),
I don't think many programs are actually hurt by trigraph processing.
Perhaps a handful of ones involving chess notation, where "??!" is a
meaningful string that *might* be encoded in the source code.
Paul Eggert
Instead of theorizing about it, why not look at some real code?
I just took a quick scan of the top level (*/*.[ch] */*/*.[ch]) of some
widely available free software source that is installed at our site,
and found the following examples of unexpected trigraphs in these
programs. There are many other instances of trigraphs
in comments -- some of them quite strongly-worded comments about the
undesirability of trigraphs! -- but I omitted them in this survey.
elisp-manual/texindex.c: fprintf (stderr, " Usually FILE... is `foo.??' for the source file `foo.tex'.\n");
f2c/src/init.c:char *dflt1proc[] = { "(U_fp)0", "(??bug??)0", "(I1_fp)0",
gdb/gdb/procfs.c: { PR_CHECKPOINT, "PR_CHECKPOINT", "(???)" },
jpeg/jpeg-6b-beta2/jmemmac.c: osErr = FSpCreate ( &theSpec, '????', '????', smSystemScript );
rn/kfile.c: fputs("\tsubject not found (???)\n",stdout) FLUSH;
texinfo/po/cat-id-tbl.c: {"Usually FILE... is `foo.??' for a document `foo.texi'.\n", 357},
The story behine the last example might be amusing. The file
texinfo/po/cat-id-tbl.c is created automatically by a program that
scans C text and looks for messages. The original source code is
protected against trigraphs:
texinfo/util/texindex.c: fprintf (f, _("Usually FILE... is `foo.??\' for a document `foo.texi'.\n"));
but this protection got lost during the scan.
Clearly the automated procedure that generates texinfo/po/cat-id-tbl.c
is not trigraph-aware, and this is a portability bug caused by
unexpected trigraphs. In my opinion, the blame for this sort of bug
ought to fall squarely on the C Standard, not on the poor programmers
who have to deal with the possibility of trigraphs.
So trigraph problems occur in real life and hurt several well-known
applications. I should emphasize that this is in widely-tested and
ported code. Proprietary code often tends to have more trigraph
problems per line, since it hasn't been examined by as many eyeballs.
These programs are compiled by GCC at our site, and GCC disables
trigraphs by default, so we don't have a problem (thank goodness!).
Nick Maclaren
In article <70gd9f$du3$1...@shade.twinsun.com>,
>
>Trigraphs don't solve the problem for EBCDIC, since they don't address
>the problem of `!'.
>
>not necessary to use trigraphs to work with EBCDIC, and that many
>serious EBCDIC users avoid trigraphs. This is hardly a ringing
>endorsement of the need for trigraphs.
As someone who has implemented a C library under MVS, was Project
Manager of the relevant area in SHARE Europe, was involved (heavily)
in EBCDIC-related portability and conversions for decades, and so on,
I can confirm this view.
Trigraphs together with C9X digraphs and/or the <iso646.h> header DO
solve the EBCDIC problem, in a quite revolting way. Without the C9X
(all right, the interim update that only gcc implements) changes,
they don't.
Éamonn McManus
> Whether trigraphs were a good idea is debatable, and I have to agree
> they are excessively clumsy, and a hazard in the creation of string
> literals. However, you shouldn't imply that they were created for no
> the fact that one or more of the characters designated by trigraphs
What I've never understood is why this has to be in the C standard,
and therefore in every conforming C compiler, rather than being in
tools such as editors or preprocessors on the systems that have the
character-set problems, or perhaps being incorporated in the compilers
*on those systems*. It would have made sense for trigraphs to be
mentioned in an annex to the C standard as a conventional interchange
format, and even for compilers to be required to implement support for
files in that format. But given that it introduced a quiet change, it
did *not* make sense to require all compilers to recognise trigraphs
all the time. The behaviour of gcc and other sensible compilers
reflects that fact.
,
Eamonn http://www.gr.opengroup.org/~emcmanus
"My mother, who by an eerie circumstance was even older than I..." - Mimi Kahn
sa...@bear.com
"James Russell Kuyper Jr." <kuy...@wizard.net> wrote:
I also think how many programs are really affected by the trigraphs.
Does anybody have any bad experience from the trigraphs or is the
fear imaginary? Danish and may be other European languages still need
trigraphs (even with digraphs) for characters such as '\\'. It is easy
to grep for them too. Of course, when it comes to internationalization,
many people do not care and object to any change.
sa...@bear.com
Interesting survey. But how long have trigraphs been in the standard? For
quite some time! And if those programs did not fix their bugs, I do not think
C standard should be blamed for this.
Jens Schweikhardt
# I've never used trigraphs, and I pity anyone who has to. I've also never
# run into problems from their side-effects; one consecutive '?' is enough
# for me in any text string I've ever written.
Shell glob patterns come to mind...
Anyone here bitten by trigraphs silently messing up glob patterns??(oops)
Clive D.W. Feather
>>There are real systems where people write real C code, despite
>>the fact that one or more of the characters designated by trigraphs
>>cannot be typed in directly.
>
>trigraphs are a silent change to the language);
Apart from strings containing double question marks, can you show me a
program whose meaning was changed ? If not, it isn't a quiet change. And
if it's only strings, then "many people are hurt" and "harms can be
large" also appear to be hyperbole.
Dennis Yelle
> > >Paul Eggert wrote:
[...]
> > >I don't think many programs are actually hurt by trigraph processing.
> > >Perhaps a handful of ones involving chess notation, where "??!" is a
> > >meaningful string that *might* be encoded in the source code.
{Many existing lines containing unintended trigraphs]
And then we have:
> Interesting survey. But how long have trigraphs been in the standard? For
> quite some time! And if those programs did not fix their bugs, I do not think
> C standard should be blamed for this.
>
> Thank you,
> Saroj Mahapatra
What strange logic.
What we have here is a mistake (trigraphs) made 10 years ago.
Most people (both implementers and users) saw the mistake as a mistake
and ignored it. Compilers ignored trigraphs in their default mode
to avoid breaking existing working code,
and most users ignored trigraphs too.
The bug is not in the code containing unintentional trigraphs.
The bug is in the standard.
If somebody, somewhere wants trigraphs they should turn them
on with something like _Pragma( trigraph-on);
Dennis Yelle
Nick Maclaren
Clive D.W. Feather <cl...@demon.net> wrote:
>In article <70gd9f$du3$1...@shade.twinsun.com>, Paul Eggert
><egg...@twinsun.com> writes
>>>There are real systems where people write real C code, despite
>>>the fact that one or more of the characters designated by trigraphs
>>>cannot be typed in directly.
>>
>>Yes, but few people benefit from trigraphs (and the benefits are small),
>>whereas many people are hurt by them (and the harms can be large, since
>>trigraphs are a silent change to the language);
>
>Apart from strings containing double question marks, can you show me a
>program whose meaning was changed ? If not, it isn't a quiet change. And
>if it's only strings, then "many people are hurt" and "harms can be
>large" also appear to be hyperbole.
Perhaps somewhat, but I have had files corrupted by this cause. I needed
to convert a large amount of incomprehensible text from one format to
another, and so wrote a program to munge the text into a C program that
would then print the result. The single characters were easy to escape,
but I forgot the trigraphs.
As I had kept the input, I was OK, but they were right beggars to deal
with. More work than the rest of the job put together.
Douglas A. Gwyn
> >I don't think many programs are actually hurt by trigraph processing.
> >Perhaps a handful of ones involving chess notation, where "??!" is a
> >meaningful string that *might* be encoded in the source code.
If you only found six instances in a huge body of code,
that doesn't qualify as "many" cases, in my opinion.
More interestingly, presumably you've been compiling these
with GCC. These are all instances of *not conforming* code.
If GCC had correctly implemented the standard (in the mode
you use to compile them, long ago these bugs would have been
found and fixed. (Trigraphs have been part of Standard C
since 1989.)
Douglas A. Gwyn
> The bug is not in the code containing unintentional trigraphs.
> The bug is in the standard.
No, the bug is in nonconforming implementations.
The standard is as intended, on this issue.
> If somebody, somewhere wants trigraphs they should turn them
> on with something like _Pragma( trigraph-on);
There were no function-like pragma macros in C89,
and #pragma couldn't be written in just those cases that
need trigraphs without trigraphs already being in effect.
Douglas A. Gwyn
> As I had kept the input, I was OK, but they were right beggars to deal
> with. More work than the rest of the job put together.
I once wrote a similar code transliterator (to change //-comments
to /*-comments-*/), as a finite state machine, so I have some
relevant experience..
Inverse trigraph mapping would be *trivial* if only there were
a trigraph to represent the ? character (e.g. ???). You might
propose that in a public comment, since whenever I do it the
response is that nobody is asking for it.
Dennis Yelle
>
> Dennis Yelle wrote:
> > The bug is not in the code containing unintentional trigraphs.
> > The bug is in the standard.
>
> No, the bug is in nonconforming implementations.
> The standard is as intended, on this issue.
As intended by whom???
> > If somebody, somewhere wants trigraphs they should turn them
> > on with something like _Pragma( trigraph-on);
>
> There were no function-like pragma macros in C89,
Function-like pragmas could have been introduced.
Function-like pragmas do not break working programs.
The introduction of trigraphs broke working programs.
I am sorry that you have not learned the trigraph
lesson yet.
> and #pragma couldn't be written in just those cases that
> need trigraphs without trigraphs already being in effect.
#pragma could have been written with di-graphs.
di-graphs do not have the well known problems that trigraphs
have because di-graphs are not interpreted inside strings
and character constants.
Dennis Yelle
Thomas R. Truscott
>Does anybody have any bad experience from the trigraphs or is the
The company where I work had a bad experience just last month.
The "splash screens" for our software product were being revised
and the program which encodes the pixels into C strings
did not defend against the accidental creation of trigraphs.
[I will skip the details, except to say we defend against
the "trigraph problem" in two different ways, and both failed.]
The next week the screens were re-revised and the next morning
some versions up the product would not even reach a prompt
until someone thought to disable the splash screens.
This was so late in our product cycle that alarm bells went
off all over the company.
I can't presume to put a dollar cost on this,
and it keeps us on our toes so it is not all bad :-),
but it certainly qualifies as a bad experience.
From my perspective this issue isn't about whether
trigraphs are in some standard or are a "silent change",
it is that trigraphs are a useless feature
which is routinely and harmfully triggered by mistake.
Tom Truscott
P.S. We are now defending against the "trigraph problem"
in three different ways.
Paul Eggert
>Apart from strings containing double question marks, can you show me a
>program whose meaning was changed ? If not, it isn't a quiet change.
The Rationale for C89 explicitly lists trigraphs as a quiet change.
A quiet change is one that changes the meaning of a program without
eliciting a diagnostic from the translator. Strings containing
trigraphs have a different meaning in C89 than they do in K&R C, with
no diagnostic required; trigraphs therefore were a quiet change.
>And if it's only strings, then "many people are hurt" and "harms can be
>large" also appear to be hyperbole.
Changing the meaning of a string can break a program, quite badly.
Tom Truscott gave one example in <news:70jbai$l9b$1...@hal.cs.duke.edu>;
there are others.
Paul Eggert
>If you only found six instances in a huge body of code,
>that doesn't qualify as "many" cases, in my opinion.
No, it's a large number of cases, considering that they're taken from
widely used code that has been run by a _lot_ of people. Proprietary
code has less exposure and (in my experience) has many more problems
per line of code.
Your suggestion that only a ``handful'' of programs ``involving chess
notation'' would be involved suggests that you don't often encounter
the problem yourself. You're a lucky guy. In the real world of C
programming we encounter the problem far too often.
>presumably you've been compiling these with GCC.
Yes, but all the programs are regularly ported to non-GCC implementations.
These programs are all widely used outside the GCC world;
four of the six examples were taken from non-GNU sources.
So turning off trigraph processing is not just a GNU thing.
>These are all instances of *not conforming* code.
That's too bad, but it is a problem with the standard, not with its users.
Users have voted with their feet against trigraphs.
Paul Eggert
>Inverse trigraph mapping would be *trivial* if only there were
>a trigraph to represent the ? character (e.g. ???). You might
>propose that in a public comment, since whenever I do it the
>response is that nobody is asking for it.
No, please; let's not compound the problem by adding more trigraphs.
It's bad enough as it is.
Jens Schweikhardt
# "Douglas A. Gwyn" <DAG...@null.net> writes:
[about trigraphs and quiet changes]
#>These are all instances of *not conforming* code.
# That's too bad, but it is a problem with the standard, not with its users.
# Users have voted with their feet against trigraphs.
Right. And what about standardizing *this* kind of existing practice?
I sympathize a lot with Dennis Yelle's suggestion of making trigraph
support a pragma.
Nick Maclaren
In article <70mo9f$bl7$2...@news.BelWue.DE>, Jens Schweikhardt <schw...@diamant.noc.dfn.de> writes:
|> Paul Eggert <egg...@twinsun.com> wrote:
|> # "Douglas A. Gwyn" <DAG...@null.net> writes:
|>
|> [about trigraphs and quiet changes]
|>
|> #>These are all instances of *not conforming* code.
|>
|> # That's too bad, but it is a problem with the standard, not with its users.
|> # Users have voted with their feet against trigraphs.
|>
|> Right. And what about standardizing *this* kind of existing practice?
|> I sympathize a lot with Dennis Yelle's suggestion of making trigraph
|> support a pragma.
It can now be done cleanly, because '%:' can be used to introduce
the pragma directive. In C89, it couldn't be.
Douglas A. Gwyn
> >a trigraph to represent the ? character (e.g. ???). You might
> >propose that in a public comment, since whenever I do it the
> >response is that nobody is asking for it.
> No, please; let's not compound the problem by adding more trigraphs.
> It's bad enough as it is.
Did you even *read* the thread before posting a knee-jerk reaction?
I observed that this *one* additional trigraph would *solve* a
problem with the current trigraph scheme. That hardly "compounds
the problem"!
Norman Diamond
This suggestion of Mr. Gwyn's was correct. Although not exactly stated
in either of his postings or earlier in the thread that I noticed, this
suggestion would even make trigraph rules more bearable for those of us
who have reasons to hate trigraphs. Wherever we used to type a question
mark in a C program, we could now type three of them. Everywhere. This
would require adopting a new habit but it would be an easy one.
But regarding who is known for knee-jerk reactions with no appearance of
having read a thread, there's a famous proverb about glass houses.
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
Duncan Booth
>Inverse trigraph mapping would be *trivial* if only there were
>a trigraph to represent the ? character (e.g. ???). You might
>propose that in a public comment, since whenever I do it the
>response is that nobody is asking for it.
Pardon my ignorance, but can't you effectively use ?"" as though it were a
trigraph for the ? character in strings?
--
Duncan Booth dun...@dales.rmplc.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?
http://dales.rmplc.co.uk/Duncan
Douglas A. Gwyn
> Pardon my ignorance, but can't you effectively use ?"" as though it were a
> trigraph for the ? character in strings?
That works in string literals, but it complicates the general
job of mapping non-trigraph source code to trigraphed source
code, since it takes a substantial amount of analysis to
determine whether a ? occurs within a string literal or not.
(People can do that much more easily than a conversion program.)
Andreas Schwab
|> In article <70mo9f$bl7$2...@news.BelWue.DE>, Jens Schweikhardt <schw...@diamant.noc.dfn.de> writes:
|> |> Paul Eggert <egg...@twinsun.com> wrote:
|> |> # "Douglas A. Gwyn" <DAG...@null.net> writes:
|> |>
|> |> [about trigraphs and quiet changes]
|> |>
|> |> #>These are all instances of *not conforming* code.
|> |>
|> |> # That's too bad, but it is a problem with the standard, not with its users.
|> |> # Users have voted with their feet against trigraphs.
|> |>
|> |> Right. And what about standardizing *this* kind of existing practice?
|> |> I sympathize a lot with Dennis Yelle's suggestion of making trigraph
|> |> support a pragma.
|>
|> It can now be done cleanly, because '%:' can be used to introduce
|> the pragma directive. In C89, it couldn't be.
You don't need that, since C9x has _Pragma.
--
Andreas Schwab "And now for something
sch...@issan.cs.uni-dortmund.de completely different"
sch...@gnu.org
Andreas Schwab
|> Paul Eggert wrote:
|> > "Douglas A. Gwyn" <DAG...@null.net> writes:
|> > >Inverse trigraph mapping would be *trivial* if only there were
|> > >a trigraph to represent the ? character (e.g. ???). You might
|> > >propose that in a public comment, since whenever I do it the
|> > >response is that nobody is asking for it.
|> > No, please; let's not compound the problem by adding more trigraphs.
|> > It's bad enough as it is.
|>
|> Did you even *read* the thread before posting a knee-jerk reaction?
|> I observed that this *one* additional trigraph would *solve* a
|> problem with the current trigraph scheme.
You don't need that. Just change any ? following a ? to \?.
Nick Maclaren
In article <vyzn26n...@issan.cs.uni-dortmund.de>, Andreas Schwab <sch...@issan.cs.uni-dortmund.de> writes:
|> nm...@cus.cam.ac.uk (Nick Maclaren) writes:
|>
|> |> In article <70mo9f$bl7$2...@news.BelWue.DE>, Jens Schweikhardt <schw...@diamant.noc.dfn.de> writes:
|> |> |>
|> |> |> I sympathize a lot with Dennis Yelle's suggestion of making trigraph
|> |> |> support a pragma.
|> |>
|> |> It can now be done cleanly, because '%:' can be used to introduce
|> |> the pragma directive. In C89, it couldn't be.
|>
|> You don't need that, since C9x has _Pragma.
True, though I regard that as a horrible way of specifying a
global syntactic property such as trigraphs. In any case, the
difference is that it can be done in C9X and couldn't in C89.
Nick Maclaren
In article <vyzk91r...@issan.cs.uni-dortmund.de>, Andreas Schwab <sch...@issan.cs.uni-dortmund.de> writes:
|> "Douglas A. Gwyn" <DAG...@null.net> writes:
|>
|> |> Paul Eggert wrote:
|> |> > "Douglas A. Gwyn" <DAG...@null.net> writes:
|> |> > >Inverse trigraph mapping would be *trivial* if only there were
|> |> > >a trigraph to represent the ? character (e.g. ???). You might
|> |> > >propose that in a public comment, since whenever I do it the
|> |> > >response is that nobody is asking for it.
|> |> > No, please; let's not compound the problem by adding more trigraphs.
|> |> > It's bad enough as it is.
|> |>
|> |> Did you even *read* the thread before posting a knee-jerk reaction?
|> |> I observed that this *one* additional trigraph would *solve* a
|> |> problem with the current trigraph scheme.
|>
|> You don't need that. Just change any ? following a ? to \?.
I am afraid that doesn't work, in general! The problem is that
you are changing the number of tokens if the ? does not occur within
a character or string constant.
Andreas Schwab
|> In article <vyzk91r...@issan.cs.uni-dortmund.de>, Andreas Schwab <sch...@issan.cs.uni-dortmund.de> writes:
|> |> "Douglas A. Gwyn" <DAG...@null.net> writes:
|> |>
|> |> |> Paul Eggert wrote:
|> |> |> > "Douglas A. Gwyn" <DAG...@null.net> writes:
|> |> |> > >Inverse trigraph mapping would be *trivial* if only there were
|> |> |> > >a trigraph to represent the ? character (e.g. ???). You might
|> |> |> > >propose that in a public comment, since whenever I do it the
|> |> |> > >response is that nobody is asking for it.
|> |> |> > No, please; let's not compound the problem by adding more trigraphs.
|> |> |> > It's bad enough as it is.
|> |> |>
|> |> |> Did you even *read* the thread before posting a knee-jerk reaction?
|> |> |> I observed that this *one* additional trigraph would *solve* a
|> |> |> problem with the current trigraph scheme.
|> |>
|> |> You don't need that. Just change any ? following a ? to \?.
|>
|> I am afraid that doesn't work, in general! The problem is that
|> you are changing the number of tokens if the ? does not occur within
|> a character or string constant.
I don't understand. Outside of a char or string const or a comment a ?
never follows another ? in a valid source that is free of trigraphs.
Nick Maclaren
You may be right. I thought that it could occur during preprocessing,
but I can no longer think of an example where it makes a difference.
You certainly CAN write the following:
#define fred ??????
But I have difficulty in using that macro anywhere except in an
#include or #error directive. I may have forgotten a trick, though.
Paul Eggert
>Paul Eggert wrote:
>> "Douglas A. Gwyn" <DAG...@null.net> writes:
>> >Inverse trigraph mapping would be *trivial* if only there were
>> >a trigraph to represent the ? character (e.g. ???).
>> No, please; let's not compound the problem by adding more trigraphs.
>> It's bad enough as it is.
>Did you even *read* the thread before posting a knee-jerk reaction?
Yes.
Did you read my comments about how trigraphs break existing code?
Adding `???' as a trigraph would compound the problem.
Here are some example programs whose meaning would silently change
(i.e. the programs would silently break) if `???' were a trigraph.
CVS Emacs f2c GCC GDB INN Perl PGP Pine RPM Samba
Their source code is freely available, so you can check my results if you like.
And what benefits would we get from this proposed change?
Nothing, practically speaking.
This one is an _easy_ call.
Clive D.W. Feather
<t...@cs.duke.edu> writes
>The company where I work had a bad experience just last month.
>The "splash screens" for our software product were being revised
>and the program which encodes the pixels into C strings
>did not defend against the accidental creation of trigraphs.
>[I will skip the details, except to say we defend against
>the "trigraph problem" in two different ways, and both failed.]
I'm bothered by the fact that you defended against it and, presumably,
tested that defence, yet still ran into a problem. I would be interested
in details, since I can't see that this would be more than 3 or 4 lines
of code.
Clive D.W. Feather
<egg...@twinsun.com> writes
>>Apart from strings containing double question marks, can you show me a
>>program whose meaning was changed ? If not, it isn't a quiet change.
>
>The Rationale for C89 explicitly lists trigraphs as a quiet change.
>A quiet change is one that changes the meaning of a program without
>eliciting a diagnostic from the translator.
Accepted. But I was intrigued by the apparent claim that it had a much
wider effect that just strings. I may have read too much into your
posting and then answered it badly.
>>And if it's only strings, then "many people are hurt" and "harms can be
>>large" also appear to be hyperbole.
>Changing the meaning of a string can break a program, quite badly.
>Tom Truscott gave one example in <news:70jbai$l9b$1...@hal.cs.duke.edu>;
>there are others.
See my reponse to his posting and to others. "Defending" against
trigraphs shouldn't be that hard.
Clive D.W. Feather
<egg...@twinsun.com> writes
>elisp-manual/texindex.c: fprintf (stderr, " Usually FILE... is `foo.??' for
>the source file `foo.tex'.\n");
>f2c/src/init.c:char *dflt1proc[] = { "(U_fp)0", "(??bug??)0", "(I1_fp)0",
>gdb/gdb/procfs.c: { PR_CHECKPOINT, "PR_CHECKPOINT", "(???)" },
>rn/kfile.c: fputs("\tsubject not found (???)\n",stdout) FLUSH;
None of these were noticed using testing ? Out of interest, would they
have affected the output of the program in other than a cosmetic manner?
[adb on SCO Unix outputs something like "(??]" where the author clearly
wrote "(????)", for just the same reason.]
>jpeg/jpeg-6b-beta2/jmemmac.c: osErr = FSpCreate ( &theSpec, '????', '????',
>smSystemScript );
This, of course, uses implementation-defined behavior already. It would
have shown up immediately as soon as a trigraph-enabled compiler was
used.
>texinfo/po/cat-id-tbl.c: {"Usually FILE... is `foo.??' for a document
>`foo.texi'.\n", 357},
>
>The story behine the last example might be amusing. The file
>texinfo/po/cat-id-tbl.c is created automatically by a program that
>scans C text and looks for messages. The original source code is
>protected against trigraphs:
[...]
>Clearly the automated procedure that generates texinfo/po/cat-id-tbl.c
>is not trigraph-aware, and this is a portability bug caused by
>unexpected trigraphs. In my opinion, the blame for this sort of bug
>ought to fall squarely on the C Standard, not on the poor programmers
>who have to deal with the possibility of trigraphs.
I disagree. If you are claiming to write code that interprets C source
code, you should be aware of what is in the C language. What did it do
with the # and ## operators, or did it believe that macro arguements
could be expanded inside character and string literals ?
>So trigraph problems occur in real life and hurt several well-known
>applications. I should emphasize that this is in widely-tested and
>ported
but clearly not well-tested
>code.
The "hurt", in every case bar one, seems to be a formatting error in the
output.
Clive D.W. Feather
<nm...@cus.cam.ac.uk> writes
>Perhaps somewhat, but I have had files corrupted by this cause. I needed
>to convert a large amount of incomprehensible text from one format to
>another, and so wrote a program to munge the text into a C program that
>would then print the result. The single characters were easy to escape,
>but I forgot the trigraphs.
I'd be interested to discuss this off-line with you sometime. I'm not
convinced you were using the right tool for the job (my first attack
would be with lex) but, knowing you as I do, I hesitate to point
fingers.
Clive D.W. Feather
<emcm...@gr.opengroup.org> writes
>What I've never understood is why this has to be in the C standard,
>and therefore in every conforming C compiler, rather than being in
>tools such as editors or preprocessors on the systems that have the
>character-set problems, or perhaps being incorporated in the compilers
>*on those systems*.
Because ISO required it to be possible to write C using only the ISO-646
invariant character set. Where ISO got the requirement from, I'm less
sure.
Paul Eggert
>None of these [errors caused by trigraphs] were noticed using testing ?
I don't know; I'm not involved with testing those programs.
But what's your point? That trigraphs may cause bugs,
but this isn't a problem in practice because people always test
their code thoroughly? If so, then I don't agree.
Real life programs are not always tested exhaustively, so if trigraphs
cause problems with untested code, then that is a cost of trigraphs.
Also, if trigraphs are an error-prone feature, then they are a cost to
software developers, even when their bugs are caught in testing.
> would they have affected the output of the program
> in other than a cosmetic manner?
Let's look at the first example:
elisp-manual/texindex.c: fprintf (stderr, " Usually FILE... is `foo.??' for th
e source file `foo.tex'.\n");
If you compile the program with trigraph processing turned on,
the program will give the user incorrect advice.
Now, is this ``cosmetic'', or is a real harm? I say it's both.
In other cases, the harms of trigraphs are more severe than merely
incorrect advice. Tom Truscott gave one example of this.
>If you are claiming to write code that interprets C source
>code, you should be aware of what is in the C language.
Of course you should, but people are not perfect: they make mistakes,
and trigraphs are an error-prone feature that engender mistakes.
This is a real cost, in real programs, and this cost far outweighs
the benefits of trigraphs.
Robert Corbett
Nick Maclaren <nm...@cus.cam.ac.uk> wrote:
>
>You may be right. I thought that it could occur during preprocessing,
>but I can no longer think of an example where it makes a difference.
>You certainly CAN write the following:
>
> #define fred ??????
>
>But I have difficulty in using that macro anywhere except in an
>#include or #error directive. I may have forgotten a trick, though.
Try
#define STR(x) STRVAL(x)
#define STRVAL(x) #x
#define fred ??????
#include <stdio.h>
int
main(void)
{
printf("fred = %s\n", STR(fred));
return (0);
}
I understand people write code like this all the time (8-)).
Sincerely,
Bob Corbett
Douglas A. Gwyn
> You don't need that. Just change any ? following a ? to \?.
Doesn't work outside of a character constant (not s.c. anyway)
or string literal.
Douglas A. Gwyn
> I don't understand. Outside of a char or string const or a comment a ?
> never follows another ? in a valid source that is free of trigraphs.
It could occur in a comment, but I suppose that relatively
little harm is usually done by changing ?? to ?\? in a comment.
Douglas A. Gwyn
> Yes.
Apparently not, or at least you didn't understand it.
> Here are some example programs whose meaning would silently change
> (i.e. the programs would silently break) if `???' were a trigraph.
> ...
> And what benefits would we get from this proposed change?
> Nothing, practically speaking.
The suggestion for ??? was made in the context of a discussion
about the difficulty of writing a converter to take that
not-conforming code you so love and *automatically convert it*
to trigraph form so that it would *not* break when compiled by
a conforming compiler. (Of course, by now you have found the
places that need to be fixed and could convert them by hand.)
Such a conversion utility would be very easy to write *if*
there were a suitable encoding for each
?-not-part-of-a-trigraph character. I suggested ? -> ???,
but it has since been suggested that ?? -> ?\? is good enough.
Instead of GCC refusing to translate trigraphs, thereby
encouraging you to maintain those items of code in a
not-conforming source form, it would be much better to
translate them to Standard C and fix the damned compiler.
Trigraph processing is nearly *trivial*, since it is done
at a very early phase of translation, which is also why
a utility to convert your non-conforming sources to
trigraph-protected form would be nearly trivial, if the
escape ? can be taken care of. (No need to tokenize.)
Nick Maclaren
Clive D.W. Feather <cl...@demon.net> wrote:
>In article <70io1r$99a$1...@pegasus.csx.cam.ac.uk>, Nick Maclaren
><nm...@cus.cam.ac.uk> writes
>>Perhaps somewhat, but I have had files corrupted by this cause. I needed
>>to convert a large amount of incomprehensible text from one format to
>>another, and so wrote a program to munge the text into a C program that
>>would then print the result. The single characters were easy to escape,
>>but I forgot the trigraphs.
>
>I'd be interested to discuss this off-line with you sometime. I'm not
>convinced you were using the right tool for the job (my first attack
>would be with lex) but, knowing you as I do, I hesitate to point
>fingers.
Oh, I wasn't! The correct tool for the job would have been a good
programmable text editor (e.g. ZED or, I understand, TECO). But
all I had were the standard Unix tools, plus Emacs and Perl. As the
prospect of using awk was unpalatable, and I know C and I don't know
lex or Perl, I used C. The problem wasn't too hard to fix, once I
remembered it, but was a pain.
Other that the effect on format strings, which is rarely more than a
cosmetic problem (as you point out), I believe that this is the main
cause of problems with trigraphs. Using C (or even just cpp) for
this purpose is extremely common, and its use is often embedded deep
in long-forgotten scripts. Often, the user (the person who types in
the question marks) doesn't have a clue how they are processed.
How it could have been done better, and why it should have been, is
definitely an offline matter. Introducing a radically new way of
tackling this problem at this stage would be, er, unpopular :-)
Paul Eggert
>Apparently not, or at least you didn't understand it.
I understood it perfectly. You proposed adding a new trigraph `???' to
ease conversion from normal C to C-with-trigraphs. But trigraphs are a
mistake. And adding more trigraphs compounds the mistake.
>Instead of GCC refusing to translate trigraphs, thereby
>encouraging you to maintain those items of code in a
>not-conforming source form, it would be much better to
>translate them to Standard C and fix the damned compiler.
No, it would be much better to fix the standard to reflect
existing practice, which by and large either turns off
trigraph processing, or avoids trigraphs entirely.
The standard should serve programmers, not the other way around.
>Trigraph processing is nearly *trivial*,
I never said it wasn't. What I said was that trigraphs cause errors.
This is why common existing practice disagrees with the standard in this area.
Clive D.W. Feather
<egg...@twinsun.com> writes
>>None of these [errors caused by trigraphs] were noticed using testing ?
>
>I don't know; I'm not involved with testing those programs.
>But what's your point? That trigraphs may cause bugs,
>but this isn't a problem in practice because people always test
>their code thoroughly?
Not quite: my point is that people rail against trigraphs as if they
were the most awful thing ever invented, when the problems should have
been caught by normal testing. Compared to implementation-varying areas,
this is trivia.
>Real life programs are not always tested exhaustively, so if trigraphs
>cause problems with untested code, then that is a cost of trigraphs.
Agreed.
>>If you are claiming to write code that interprets C source
>>code, you should be aware of what is in the C language.
>
>Of course you should, but people are not perfect: they make mistakes,
>and trigraphs are an error-prone feature that engender mistakes.
>This is a real cost, in real programs, and this cost far outweighs
>the benefits of trigraphs.
That's a different - and debatable - issue. I wish we were hearing more
from the people who feel trigraphs are useful and/or necessary.
Dan Pop
>That's a different - and debatable - issue. I wish we were hearing more
>from the people who feel trigraphs are useful and/or necessary.
If you think that trigraphs are useful and/or necessary, try to read the
following C program, as such:
??=include <stdio.h>
main()
??<
int a??(10??);
a??(0??) = 0x10 ??! 0x22;
a??(0??) ??'= 0x33;
a??(9??) = a??(0??) ??' '??/x30';
printf("%d %d??/n", ??-a??(0??), a??(0??) ??! a??(9??));
return 0;
??>
Few people, outside of this newsgroup, would even recognize this gibberish
as C source code.
I can buy the argument "there were external constraints to do it", but
I don't buy any attempt to justify the usefulness/necessity of this
particular solution.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Hallvard B Furuseth
> If you think that trigraphs are useful and/or necessary, try to read the
> following C program, as such:
>
> ??=include <stdio.h>
>
> main()
> ??<
> int a??(10??);
>
> a??(0??) = 0x10 ??! 0x22;
> a??(0??) ??'= 0x33;
> a??(9??) = a??(0??) ??' '??/x30';
> printf("%d %d??/n", ??-a??(0??), a??(0??) ??! a??(9??));
> return 0;
> ??>
Just curious: Do you think the code below looks better?
I do, but I'm wondering if that's because I'm used to such code.
£include <stdio.h>
main()
æ
int aÆ10Å;
aÆ0Å = 0x10 ø 0x22;
aÆ0Å ç= 0x33;
aÆ9Å = aÆ0Å ç 'Øx30';
printf("%d %dØn", §aÆ0Å, aÆ0Å ø aÆ9Å);
return 0;
å
That's C code wihtout trigraphs in the Norwegian iso646 variant,
NS_4551-1, and to get a fair comparison i replaced the remaining
trigraphs with some random 8-bit characters (£ç§) instead of ASCII
(#^~).
--
Hallvard
Clive D.W. Feather
writes
>>That's a different - and debatable - issue. I wish we were hearing more
>>from the people who feel trigraphs are useful and/or necessary.
>following C program, as such:
This proves nothing. As the next article in the thread shows, it's
better than having letters scattered through your code. At least you
don't risk punctuation suddenly turning into identifiers.
I have little use [*] for trigraphs myself. I also have little use for
type qualifiers. That doesn't mean I have to campaign to have them
removed. What I said was, I wish we were hearing more from those who
*do* have a use for them.
[*] The ??=error directive is a fairly foolproof way of terminating
compilation with an error, whether or not the compiler groks ANSI C.
Clive D.W. Feather
<h.b.fu...@usit.uio.no> writes
>> If you think that trigraphs are useful and/or necessary, try to read the
>> following C program, as such:
[...]
>I do, but I'm wondering if that's because I'm used to such code.
>
> £include <stdio.h>
>
> main()
> æ
> int aÆ10Å;
Of course, you now risk - under C9X - this turning into code with a
completely different meaning. For example, aÆ0Å is an identifier (it
contains only letters and digits and begins with a letter).
>That's C code wihtout trigraphs in the Norwegian iso646 variant,
>NS_4551-1, and to get a fair comparison i replaced the remaining
>trigraphs with some random 8-bit characters (£ç§) instead of ASCII
>(#^~).
I've used at least one compiler that accepted £ as equivalent to #.
Paul D. Smith
cdwf> I have little use [*] for trigraphs myself. I also have little
cdwf> use for type qualifiers. That doesn't mean I have to campaign to
cdwf> have them removed. What I said was, I wish we were hearing more
cdwf> from those who *do* have a use for them.
IMHO, the fact that we're not hearing anything from anyone who has a use
for them is a powerful statement in this argument, all by itself :).
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Dan Pop
>Dan Pop writes:
>
>> If you think that trigraphs are useful and/or necessary, try to read the
>> following C program, as such:
>>
>> ??=include <stdio.h>
>>
>> main()
>> ??<
>> int a??(10??);
>>
>> a??(0??) = 0x10 ??! 0x22;
>> a??(0??) ??'= 0x33;
>> a??(9??) = a??(0??) ??' '??/x30';
>> printf("%d %d??/n", ??-a??(0??), a??(0??) ??! a??(9??));
>> return 0;
>> ??>
>
>Just curious: Do you think the code below looks better?
It doesn't look worse.
>I do, but I'm wondering if that's because I'm used to such code.
Of course you're used to it: virtually nobody's writing C code using
trigraphs and I guess that you prefer writing such code rather than using
trigraphs yourself: trigraphs remain trigraphs, Norwegian characters
become members of the basic source character set if you switch your
terminal to US ASCII.
> £include <stdio.h>
>
> main()
> æ
> int aÆ10Å;
>
> aÆ0Å = 0x10 ø 0x22;
> aÆ0Å ç= 0x33;
> aÆ9Å = aÆ0Å ç 'Øx30';
> printf("%d %dØn", §aÆ0Å, aÆ0Å ø aÆ9Å);
> return 0;
> å
>
>That's C code wihtout trigraphs in the Norwegian iso646 variant,
>NS_4551-1, and to get a fair comparison i replaced the remaining
>trigraphs with some random 8-bit characters (£ç§) instead of ASCII
>(#^~).
All terminals and printers supporting national iso646 variants that I
ever saw also supported US ASCII and could be *easily* switched from one
to the other.
Anyway, trigraphs would be useless if the program produced output
containing "#{|}[\]^~". You'd still have to mentally convert Norwegian
characters to their US ASCII equivalents.
I'm not a native speaker of English, but, not being a masochist, I've
never used terminals and printers configured for my native language when
doing any kind of programming. The idea of having national variants of
a 7-bit character set was brain dead in the first place.
Peter Seebach
Paul D. Smith <psm...@baynetworks.com> wrote:
>IMHO, the fact that we're not hearing anything from anyone who has a use
>for them is a powerful statement in this argument, all by itself :).
I only post every other argument, but a former coworker of mine has a use
for them. He's supporting some C code which needs to survive translation
on an IBM mainframe at a very remote site. The mainframe support people
are useless, so his only real option is to run everything through a filter
which breaks long lines, and encodes everything with trigraphs.
It's ugly, but it is a useful feature to have.
I do not believe the program would be impaired in any way if we'd just
legislated digraphs which were tokens for all of those things in the first
place, however.
-s
--
Copyright 1998, All rights reserved. Peter Seebach / se...@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Seeking interesting programming projects. Not interested in commuting.
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
Nick Maclaren
In article <znnZ1.2221$a6.69...@ptah.visi.com>, se...@plethora.net (Peter Seebach) writes:
|> In article <p54ssqo...@baynetworks.com>,
|> Paul D. Smith <psm...@baynetworks.com> wrote:
|> >IMHO, the fact that we're not hearing anything from anyone who has a use
|> >for them is a powerful statement in this argument, all by itself :).
|>
|> I only post every other argument, but a former coworker of mine has a use
|> for them. He's supporting some C code which needs to survive translation
|> on an IBM mainframe at a very remote site. The mainframe support people
|> are useless, so his only real option is to run everything through a filter
|> which breaks long lines, and encodes everything with trigraphs.
So what does he do about code pages 037 and 500? Only the two most
common code pages, and '!' differs :-(
|> It's ugly, but it is a useful feature to have.
However, until the advent of the <iso646.h> header, they weren't
enough for portability between even the main EBCDIC code pages.
|> I do not believe the program would be impaired in any way if we'd just
|> legislated digraphs which were tokens for all of those things in the first
|> place, however.
Yes, I agree.
Thomas R. Truscott
>>and the program which encodes the pixels into C strings
>>did not defend against the accidental creation of trigraphs.
>>[I will skip the details, except to say we defend against
>>the "trigraph problem" in two different ways, and both failed.]
>
>I'm bothered by the fact that you defended against it and, presumably,
Yes, that bothered me too! Here is why they failed:
Defense #1 is that our development compiler forbids trigraphs.
The company where I work is large enough that it can afford
an in-house C compiler, complete with specialized warnings
to help encourage or enforce various coding styles.
There is a monthly meeting to debate adding new warnings
and dropping old ones, in which phrases like "cost/benefit",
"signal/noise", and "the users will mutiny" are quite popular.
For each warning there is also a longer explanation available,
including typical mistakes and typical fixes.
About three years ago warning 241, "trigraph encountered",
became a "must-fix" warning. We thought this would suffice.
Defense #1 failed because there are multiple splash screens,
e.g. one for Solaris, another with Windows/NT, etc.
and the development compiler was compiling one (not all) of them.
The one it compiled did not have any accidental trigraphs.
Defense #2 is that we scan all compiler logs on all "target"
build machines for interesting messages.
(This is semi-automated, since most messages are just noise.)
This catches lots of interesting things, such as
undefined evaluation: d += *(++m1) * *m1;
null effect: else len - ++start;
always true: if (model != HPDESK || model != HPDJPORT)
Defense #2 "succeeded" in that the native HP-UX compiler
spotted an "undefined escape sequence" as a consequence
of its trigraph conversions. The developer was alerted.
Defense #2 failed in that the developer took no action.
Although in retrospect a mistake, the developer could justify
this because there was no visible symptom of a problem,
just a lone compiler's obscure warning message.
I can imagine lots more reasons for inaction,
including a vague disbelief that "trigraphs" even exist :-)
Defense #3 is that we grep the source code for trigraphs.
This was added as a result of the splash screen incident
(though it probably would not have avoided it)
in order to spot the cases that both #1 and #2 can miss.
==================
Trigraphs are the "=-" of the 90s.
Too bad dmr isn't still in charge.
Tom Truscott
Nick Maclaren
Here is a draft of a comment that I intend to make about trigraphs.
It wasn't feasible in C89, but I think that it will be in C9X.
Comments on things that I have missed would be appreciated, but
please spare me the rhetoric!
Category: Feature that should be included
Committee Draft subsection: 5.2.1.1, 6.10.6
Title: Pragma to disable trigraphs
Detailed description:
Trigraphs cause debate that is heated out of all proportion to their
importance (or the difficulty of handling them, for that matter.) With
the changes in AMD:1995 and C9X, it becomes easy to provide a pragma
to enable or disable them at will. The following solution should
resolve this issue.
The first paragraph of 5.2.1.1 should have prepended:
If the state of the TRIGRAPHS pragma is on, ...
And the following paragraph should be added to 5.2.1.1:
The TRIGRAPHS pragma can be used to enable (if the state is on) or
disable (if the state is off) trigraphs. The pragma takes effect
from its occurrence until another TRIGRAPHS pragma is encountered,
or until the end of the translation unit. The default state (on or
off) for the pragma is implementation-defined.
Being the sort of pragma it is, there is no point in binding it to a
syntactic scope. Its default could be on, if that were preferred.
And the following should be added to 6.10.6:
#pragma STDC TRIGRAPHS on-off-switch
Keith Thompson
> Here is a draft of a comment that I intend to make about trigraphs.
> It wasn't feasible in C89, but I think that it will be in C9X.
> Comments on things that I have missed would be appreciated, but
> please spare me the rhetoric!
> disable (if the state is off) trigraphs. The pragma takes effect
> from its occurrence until another TRIGRAPHS pragma is encountered,
> or until the end of the translation unit. The default state (on or
> off) for the pragma is implementation-defined.
>
> Being the sort of pragma it is, there is no point in binding it to a
> syntactic scope. Its default could be on, if that were preferred.
My concern with this is its interaction with include files. If a
header enables or disables trigraphs, does it silently affect a source
file that includes the header? What happens if a source file enables
or disables trigraphs before including a standard header?
One solution would be to state that the TRIGRAPHS pragma affects only
the source file in which it appears, but that seems odd. I don't
think there are any other constructs that behave that way. It would
mean that a #include directive is no longer equivalent to the contents
of the included file.
Also, if the default state is implementation-defined, many source
files that don't use the TRIGRAPHS pragma would become non-portable.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst> <*>
Qualcomm, San Diego, California, USA <http://www.qualcomm.com>
I must be a techno-geek. My mouse is bigger than my phone.
Peter Curran
<snip>
>Yes, but few people benefit from trigraphs (and the benefits are small),
>whereas many people are hurt by them (and the harms can be large, since
>trigraphs are a silent change to the language); so on balance they are
>a mistake.
<snip>
I've always assumed that anyone likely to be affected by trigraphs
would use a text editor that eliminates the problem. For example, it
would be simple to write an emacs command to eliminate tragraphs
whenever a C file was read (representing any unavailable characters by
a convenient local substitute), and regenerate them when one was
written. The simple scheme the committee chose makes this almost
trivial. I really can't see why they should cause so much difficulty.
Of course, if you use vi, you're toast, but you can't blame the
committee for *everything* :-)
--
Peter Curran pcu...@acm.gov (chg gov=>org)
Douglas A. Gwyn
> I've always assumed that anyone likely to be affected by trigraphs
> would use a text editor that eliminates the problem. For example, it
> would be simple to write an emacs command to eliminate tragraphs
> whenever a C file was read (representing any unavailable characters by
> a convenient local substitute), and regenerate them when one was
> written. The simple scheme the committee chose makes this almost
> trivial. I really can't see why they should cause so much difficulty.
My own opinion is that coding of the source characters is beyond
the proper scope of a programming language standard and that any
suitable scheme should be acceptable. In particular, local
conventions to work around deficiencies such as not having a \
character in the native character set ought to take care of such
problems without having to even be mentioned in the standard.
(That's what we've done for years for EBCDIC/ASCII clashes, etc.)
The standard ought to simply exhibit the required characters,
then use them.
The actual reason C89 incorporated the trigraph mechanism at the
last minute is that one of the national bodies would not approve
the standard without some such mechanism. The argument was that
in their country, there were many keyboards with the ISO 646
invariant character set plus various alphabetic characters not
found on USASCII keyboards, usurping several of the codes that
in USASCII were assigned to important C source characters such
as { and \. Several of us argued back that *some* codes should
be used for these characters (preferably the ASCII codes to
facilitate international program interchange) and that the local
input and display facilities ought to provide { \ etc. glyphs,
or else the C source code would be hard to read. We were
assured that such requirements could not feasibly be met and
that any solution had to limit itself to the ISO 646 invariant
character set. Thus, trigraphs (and later, digraphs).
I personally would like to remove all these kludges from the
standard and describe the language using the traditional
characters -- *which even in C89 had to be supported anyway*.
Then, people exchanging source code could agree among
themselves whether to use UTF-8 or whatever, with nice-looking
source code at both ends. They *could* even agree to convert
to and from trigraph-C as an ISO 646 interchange format.
Nick Maclaren
>nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>> Here is a draft of a comment that I intend to make about trigraphs.
>> It wasn't feasible in C89, but I think that it will be in C9X.
>> Comments on things that I have missed would be appreciated, but
>> please spare me the rhetoric!
>[...]
>> The TRIGRAPHS pragma can be used to enable (if the state is on) or
>> disable (if the state is off) trigraphs. The pragma takes effect
>> from its occurrence until another TRIGRAPHS pragma is encountered,
>> or until the end of the translation unit. The default state (on or
>> off) for the pragma is implementation-defined.
>>
>> Being the sort of pragma it is, there is no point in binding it to a
>> syntactic scope. Its default could be on, if that were preferred.
>[...]
>
>My concern with this is its interaction with include files. If a
>header enables or disables trigraphs, does it silently affect a source
>file that includes the header? What happens if a source file enables
>or disables trigraphs before including a standard header?
Thanks for your comment. You are the second person to make that remark,
and are quite right. I need to think.
>One solution would be to state that the TRIGRAPHS pragma affects only
>the source file in which it appears, but that seems odd. I don't
>think there are any other constructs that behave that way. It would
>mean that a #include directive is no longer equivalent to the contents
>of the included file.
It never was, for system headers, anyway. Yes that is a possibility,
as the other person also said.
>Also, if the default state is implementation-defined, many source
>files that don't use the TRIGRAPHS pragma would become non-portable.
They are, anyway :-( gcc and many (non-GNU and GNU) utilities don't
handle them, at least by default. Some don't handle them at all.
sa...@bear.com
t...@cs.duke.edu (Thomas R. Truscott) wrote:
> Defense #1 is that our development compiler forbids trigraphs.
> The company where I work is large enough that it can afford
> an in-house C compiler, complete with specialized warnings
> to help encourage or enforce various coding styles.
> There is a monthly meeting to debate adding new warnings
> and dropping old ones, in which phrases like "cost/benefit",
> "signal/noise", and "the users will mutiny" are quite popular.
> For each warning there is also a longer explanation available,
> including typical mistakes and typical fixes.
> About three years ago warning 241, "trigraph encountered",
> became a "must-fix" warning. We thought this would suffice.
>
> Defense #1 failed because there are multiple splash screens,
> e.g. one for Solaris, another with Windows/NT, etc.
> and the development compiler was compiling one (not all) of them.
> The one it compiled did not have any accidental trigraphs.
>
Hopefully, this is a lesson for many people that they can use a compiler
like gcc and turn off the trigraphs. Whether trigraphs are useful or not
is a different issue. But when it is in the standard and you do not obey
the rules, the cost may be high!
Thanks,
Saroj Mahapatra
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Keith Thompson
[...]
> as the other person also said.
Right, but it would break the equivalence for non-system headers.
> They are, anyway :-( gcc and many (non-GNU and GNU) utilities don't
> handle them, at least by default. Some don't handle them at all.
In the case of gcc, it's at least possible to run it in a conforming
mode. My personal default mode for gcc is "-ansi -pedantic -Wall".
If the default state of the proposed TRIGRAPHS header were
implementation-defined, there would be no way to guarantee consistent
behavior.
Nick Maclaren
>nm...@cus.cam.ac.uk (Nick Maclaren) writes:
>[...]
>> It never was, for system headers, anyway. Yes that is a possibility,
>> as the other person also said.
>
>Right, but it would break the equivalence for non-system headers.
>
>> They are, anyway :-( gcc and many (non-GNU and GNU) utilities don't
>> handle them, at least by default. Some don't handle them at all.
>
>In the case of gcc, it's at least possible to run it in a conforming
>mode. My personal default mode for gcc is "-ansi -pedantic -Wall".
>If the default state of the proposed TRIGRAPHS header were
>implementation-defined, there would be no way to guarantee consistent
>behavior.
Yes, I have been convinced! My latest wording deals with this problem.
Basically, either trigraphs must be supported, or they must be
diagnosed. Not perhaps optimal, but safe and compatible with C89.
Norman Diamond
>In <HBF.981...@bombur2.uio.no> Hallvard B Furuseth <h.b.fu...@usit.uio.no> writes:
>>Just curious: Do you think the code below looks better?
>
>It doesn't look worse.
That depends on what your window does with an unmatched half of an
EUC character (in this case, a byte with value roughly in the range
decimal 160 to 254 followed by a byte which isn't). It gets tougher
when a valid EUC character is found in two consecutive bytes. SJIS
would be tougher too. But Mr. Furuseth said he was posting a national
ISO646 variant, where I thought all byte values would be less than 127?
>>I do, but I'm wondering if that's because I'm used to such code.
>
>Of course you're used to it: virtually nobody's writing C code using
>trigraphs and I guess that you prefer writing such code rather than using
>trigraphs yourself: trigraphs remain trigraphs, Norwegian characters
>become members of the basic source character set if you switch your
>terminal to US ASCII.
[...]
>All terminals and printers supporting national iso646 variants that I
>ever saw also supported US ASCII and could be *easily* switched from one
>to the other.
Could be. There are also some terminals, printers, and windows which
don't support national ISO646 variants. Some can easily be switched
among EUC and/or SJIS, and US ASCII. Some cannot. On many systems,
even if \ can be made to display as a backslash, it's still easier to
leave it as a yen sign. If one is printing in an 8-bit character set
and wants to display a yen sign as a yen sign, then one would not set
the printer to display \ as a backslash.
To the best of my understanding, despite Clive Feather's disagreement,
the standard requires programs to use ??/ to get the effect of a
backslash, and requires heavy magic when the resulting character is
sent to a printer. But for practical purposes everyone uses \ (yen
sign) to get the effect of a backslash and lets the printer display
it as \ (yen sign). I've never seen anyone outside this newsgroup
use trigraphs.
--
<< If this were the company's opinion, I would not be allowed to post it. >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
Hallvard B Furuseth
> Mr. Furuseth said he was posting a national
> ISO646 variant, where I thought all byte values would be less than 127?
Yes. I should have said, I illustrated in latin-1 what ASCII C code
looks like when displayed as NS_4551-1.
[Dan Pop]
> All terminals and printers supporting national iso646 variants that I
> ever saw also supported US ASCII and could be *easily* switched from one
> to the other.
Oh, how I wished that was true when I was a student...
But maybe we were just forbidden to fiddle with the terminal setup on
shared terminals because students would sometimes mess it up completely.
[Norman Diamond]
> To the best of my understanding, despite Clive Feather's disagreement,
> the standard requires programs to use ??/ to get the effect of a
> backslash,
I believe the Rationale disagrees with you too. If you want to put it
in Standardese, I think the "yen=backslash" character *is* a backslash
as far as C is concerned. But someone have weird terminals that use a
very strange glyph for it, a glyph which happens to look like yen.
--
Hallvard
Francis Glassborow
<h.b.fu...@usit.uio.no> writes
>I believe the Rationale disagrees with you too. If you want to put it
>in Standardese, I think the "yen=backslash" character *is* a backslash
>as far as C is concerned. But someone have weird terminals that use a
>very strange glyph for it, a glyph which happens to look like yen.
So to display a yen symbol I must repeat it? I can understand why that
might irritate Japanese programmers. However UK programmers had many
years of irritation over # whose code produced a pound Sterling glyph on
many of our output devices. Even worse for communication, US
programmers refer to the # glyph as 'pound'.
Whenever you try to squeeze gallons into a single pint pot you have
problems (BTW try putting an Imperial pint as used in the UK into a US
pint glass:)
Francis Glassborow Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Clive D.W. Feather
<t...@cs.duke.edu> writes
>>>[I will skip the details, except to say we defend against
>>>the "trigraph problem" in two different ways, and both failed.]
>Defense #1 is that our development compiler forbids trigraphs.
[...]
>Defense #1 failed because there are multiple splash screens,
>e.g. one for Solaris, another with Windows/NT, etc.
>and the development compiler was compiling one (not all) of them.
>Defense #2 is that we scan all compiler logs on all "target"
>build machines for interesting messages.
[...]
>Defense #3 is that we grep the source code for trigraphs.
If you want to forbid trigraphs, this seems to be the obvious way to do
it - it can be made part of the basic build process.
>Defense #2 failed in that the developer took no action.
Unfortunately all non-automatic systems risk this.
>Although in retrospect a mistake, the developer could justify
>this because there was no visible symptom of a problem,
>just a lone compiler's obscure warning message.
Then you need to re-educate the developer with a LART.
Clive D.W. Feather
<nm...@cus.cam.ac.uk> writes
>Here is a draft of a comment that I intend to make about trigraphs.
You need to make it clear how this interacts with #include - my
preference would be that it does not apply to included files.
You need to force the default state to on, otherwise code that is
legitimate in C89 silently changes meaning in C9X (I thought you hated
such changes).
However, you're asking for a Translation Phase 4 feature to
retroactively alter the meaning of Translation Phase 1. This can be
risky: can I mention, for example:
%:pragma STDC TRIGRAPHS off ??/
Is this acceptable ? At what point does the change take effect ? Suppose
that I want to do TP1-3 as a separate pass, or as a module with
significant buffering ? Have I got to backtrack and reinterpret the
entire source ?
Clive D.W. Feather
>One solution would be to state that the TRIGRAPHS pragma affects only
>the source file in which it appears, but that seems odd. I don't
>think there are any other constructs that behave that way.
#if / #else / #endif do; the contents of a #include within these clauses
can't affect what text is retained.
Nick Maclaren
In article <szsyYzDy...@romana.davros.org>, "Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
|> In article <715i81$3uv$1...@pegasus.csx.cam.ac.uk>, Nick Maclaren
|> <nm...@cus.cam.ac.uk> writes
|> >Here is a draft of a comment that I intend to make about trigraphs.
|> [...]
|>
|> You need to make it clear how this interacts with #include - my
|> preference would be that it does not apply to included files.
Thanks. Yes. I have taken that on board.
|> You need to force the default state to on, otherwise code that is
|> legitimate in C89 silently changes meaning in C9X (I thought you
|> hated such changes).
There are different opinions, but my current draft does that. No,
my most fervent objections are reserved for quiet changes that break
existing, clean code and cannot be detected semi-automatically.
|> However, you're asking for a Translation Phase 4 feature to
|> retroactively alter the meaning of Translation Phase 1. This can be
|> risky: can I mention, for example:
|>
|> %:pragma STDC TRIGRAPHS off ??/
|>
|> Is this acceptable ? At what point does the change take effect ? Suppose
|> that I want to do TP1-3 as a separate pass, or as a module with
|> significant buffering ? Have I got to backtrack and reinterpret the
|> entire source ?
It needs clarification, yes, but I don't think that it is a major
problem. The code affected by trigraphs and that involved in the
STDC pragma directives don't interact. The obvious definition is
that it takes effect when the complete pragma directive has been
read and decoded, so the above is NOT one - but it could be, if
the next line were blank. As far as I know, no implementation
has ever used the phase 1-4 distinction introduced by C89.
There are actually quite a lot of places where the translation
phases break down. Most of them are where the order WITHIN a
phase is important, but there is no such specification. CD2 has
removed the worst from the UCNs, but there are at least the
following other ones:
Pragmas (or other preprocessing directives) that affect
preprocessing in any way not specifically mentioned by the
standard.
Exactly when array parameters are converted to pointers,
which affects what sizeof should deliver when applied to them.
This has been clarified by a footnote in CD2, but is nowhere
stated in the main text.
I think that I did find a case of phase reversal, but have now
forgotten what it was - it wasn't important, anyway.
To set the record straight, I think that this is a horrible way
of proceeding, and I would much prefer the C standard to permit
alternate conforming behaviour - i.e. implementation-defined,
with recommended practice that both be user-selectable in any
compiler. But I have lost that one so many times that I don't
see any hope :-(
Peter Curran
<h.b.fu...@usit.uio.no> wrote:
>I believe the Rationale disagrees with you too. If you want to put it
>in Standardese, I think the "yen=backslash" character *is* a backslash
>as far as C is concerned. But someone have weird terminals that use a
>very strange glyph for it, a glyph which happens to look like yen.
I don't think so, although we are getting into philiosophy and
religion here. The standard is defined in terms of glyphs, not
encodings of those glyphs (although it does place limitations on the
encodings). A yen sign is a yen sign, not a backslash, no matter what
the underlying encodings may be.
David R. Conrad
>[A] former coworker of mine has a use
>for them. He's supporting some C code which needs to survive translation
>on an IBM mainframe at a very remote site. The mainframe support people
>are useless, so his only real option is to run everything through a filter
>which breaks long lines, and encodes everything with trigraphs.
Is the problem that some needed symbols which are missing in the character
set on the mainframe, or is it that the files need to survive character
set translation(s) in transit? If the latter, then one non-trigraph
solution would be to encode the source with something like MIME base64
(or even Quoted-Printable) and craft a program to decode it on the
mainframe.
(Of course, *that* decoder would initially have to be sent to the
mainframe under his current system, trigraphs and all, but after thus
bootstrapping it, later revisions could be sent the new way, sans
trigraphs.)
--
David R. Conrad <d...@adni.net>
who has never found any useful purpose for trigraphs, but thinks the
point about ??=error is a pretty neat trick.
Norman Diamond
>In article <HBF.981...@bombur2.uio.no>, Hallvard B Furuseth
><h.b.fu...@usit.uio.no> writes
>>in Standardese, I think the "yen=backslash" character *is* a backslash
>>as far as C is concerned. But someone have weird terminals that use a
>>very strange glyph for it, a glyph which happens to look like yen.
>
Yes.
>I can understand why that might irritate Japanese programmers.
Why? If \ looks like a backslash to you, and in order to display a
backslash you must repeat it, does that irritate you?
My concerns are different. The standard (in conflict with the Rationale
if I understand both the standard and Mr. Furuseth correctly, and still
my belief even though Mr. Feather disagrees) requires a certain character
to be a backslash glyph and to have backslash behaviour. \ is a yen
glyph which has backslash behaviour, therefore I believe that Japanese
implementations have this minor non-conformance. Trigraphs slightly
compound the problem because ??/??/ is supposed to print as a backslash
even though the printer still has a yen sign. UCNs make it worse.
I would be happy if wording were added to the standard specifying that
the source and execution character sets must include characters which
behave in the manner which the rest of the standard describes for
[set of glyphs presently listed in the standard], but do not have to
be displayed exactly as those characters. Then certain non-conformances,
which everyone prefers for practical reasons, would become conformances.
I still don't know anyone outside this newsgroup who likes trigraphs.
Nick Maclaren
David R. Conrad <d...@darwin.adni.net> wrote:
>In article <znnZ1.2221$a6.69...@ptah.visi.com>, Peter Seebach wrote:
>>[A] former coworker of mine has a use
>>for them. He's supporting some C code which needs to survive translation
>>on an IBM mainframe at a very remote site. The mainframe support people
>>are useless, so his only real option is to run everything through a filter
>>which breaks long lines, and encodes everything with trigraphs.
>
>Is the problem that some needed symbols which are missing in the character
>set on the mainframe, or is it that the files need to survive character
>set translation(s) in transit? If the latter, then one non-trigraph
>solution would be to encode the source with something like MIME base64
>(or even Quoted-Printable) and craft a program to decode it on the
>mainframe.
I doubt it. The problem is not so much that characters are missing
(though they can be), but that essential characters may have more than
one code. EBCDIC is a family of codes, like ASCII or ISO 646, but
does not have a de-facto default (unlike those.) Furthermore, the
user can select which code he writes his programs in, and the headers
need to be able to adapt without having a code page flag to test.
Trigraphs provide a way of describing all of the essential characters
in a way that is common to all of the main EBCDIC variants, except
for '!'. And, because the code for '!' differes between the two
most common forms of EBCDIC, trigraphs alone are useless for solving
the code page problem.
Trigraphs PLUS <iso646.h> do solve the problem, but so do digraphs
plus <iso646.h>. Getting '!' into strings is painful in either
case, but not difficult provided that you can guarantee a fully
conforming preprocessor and <iso646.h>.
Hallvard B Furuseth
> However, you're asking for a Translation Phase 4 feature to
> retroactively alter the meaning of Translation Phase 1. This can be
> risky: can I mention, for example:
>
> %:pragma STDC TRIGRAPHS off ??/
Nick Maclaren writes:
> The obvious definition is that it takes effect when the complete
> pragma directive has been read and decoded, so the above is NOT one -
> but it could be, if the next line were blank.
How about this:
_Pragma("STDC TRIGRAPHS off""); puts("(???)");
Since you'll have to require some sort of restriction anyway, I suggest
a constraint that after phase 1 (or maybe before trigraph replacement),
the source line must be spelled exactly as one of
" # pragma STDC TRIGRAPHS on/off \n"
" %: pragma STDC TRIGRAPHS on/off \n"
(or " ??= pragma STDC TRIGRAPHS on/off \n")
except for variations in whitespace.
--
Hallvard
Clive D.W. Feather
<nm...@cus.cam.ac.uk> writes
>|> %:pragma STDC TRIGRAPHS off ??/
>|>
>|> that I want to do TP1-3 as a separate pass, or as a module with
>|> significant buffering ? Have I got to backtrack and reinterpret the
>|> entire source ?
>
>It needs clarification, yes, but I don't think that it is a major
>problem. The code affected by trigraphs and that involved in the
>STDC pragma directives don't interact.
%: pragma STDC TRIGRAPHS /* ??/* on // */ off
They definitely interact.
>The obvious definition is
>that it takes effect when the complete pragma directive has been
>read and decoded, so the above is NOT one - but it could be, if
>the next line were blank. As far as I know, no implementation
>has ever used the phase 1-4 distinction introduced by C89.
I'm not sure that's a valid argument.
>There are actually quite a lot of places where the translation
>phases break down. Most of them are where the order WITHIN a
>phase is important, but there is no such specification.
If it's the order within a phase, then it's not a phase problem.
The phases of translation stuff means that each phase should be able to
be implemented as a separate pass of a multi-pass compiler. As far as I
know that can currently always be done. You would break it.
> Pragmas (or other preprocessing directives) that affect
>preprocessing in any way not specifically mentioned by the
>standard.
I could argue that the phases of translation mean these can't affect the
behavior of phases 1 to 3. Nonetheless, you're stepping outside the
Standard with them.
>Exactly when array parameters are converted to pointers,
All within TP7.
>To set the record straight, I think that this is a horrible way
>of proceeding, and I would much prefer the C standard to permit
>alternate conforming behaviour - i.e. implementation-defined,
>with recommended practice that both be user-selectable in any
>compiler.
I wouldn't - it makes it impossible to write a translation unit
conforming on all conforming implementations.
Clive D.W. Feather
<dia...@tbj.dec.com> writes
>My concerns are different. The standard (in conflict with the Rationale
>if I understand both the standard and Mr. Furuseth correctly, and still
>my belief even though Mr. Feather disagrees) requires a certain character
>to be a backslash glyph and to have backslash behaviour.
Yes, I disagree. The Standard requires there to be a character in source
files which is converted, during TP1, to the character represented by \
in the Standard. Providing it behaves as the character represented by \
in the text of the Standard, I see nothing requiring it to have a
particular glyph (a term that does not appear in TP2).
>\ is a yen
>glyph which has backslash behaviour, therefore I believe that Japanese
>implementations have this minor non-conformance.
I don't believe this is a non-conformance.
>Trigraphs slightly
>compound the problem because ??/??/ is supposed to print as a backslash
>even though the printer still has a yen sign.
Again I disagree. ??/ is replaced by the \ character during TP1.
Whatever \\ prints as, so do ??/??/ ??/\ and \??/
>I would be happy if wording were added to the standard specifying that
>the source and execution character sets must include characters which
>behave in the manner which the rest of the standard describes for
>[set of glyphs presently listed in the standard], but do not have to
>be displayed exactly as those characters.
I believe that is the current meaning of the Standard. I see no wording
forbidding such an implementation.
Dennis Yelle
>
> In article <719oh6$t1$1...@pegasus.csx.cam.ac.uk>, Nick Maclaren
> <nm...@cus.cam.ac.uk> writes
> >|> %:pragma STDC TRIGRAPHS off ??/
> >|>
> >|> Is this acceptable ? At what point does the change take effect ? Suppose
> >|> that I want to do TP1-3 as a separate pass, or as a module with
> >|> significant buffering ? Have I got to backtrack and reinterpret the
> >|> entire source ?
> >
> >It needs clarification, yes, but I don't think that it is a major
> >problem. The code affected by trigraphs and that involved in the
> >STDC pragma directives don't interact.
>
> %: pragma STDC TRIGRAPHS /* ??/* on // */ off
>
> They definitely interact.
Don't do that!
It is similar to this:
i = i++;
There are a lot of things that look like C that
should not be written in a C program.
That line above is one of them.
I think we need to add to the proposal that if any
trigraphs are encountered when trigraph processing
is turned off then an error must be produced.
> >The obvious definition is
> >that it takes effect when the complete pragma directive has been
> >read and decoded, so the above is NOT one - but it could be, if
> >the next line were blank. As far as I know, no implementation
> >has ever used the phase 1-4 distinction introduced by C89.
>
> I'm not sure that's a valid argument.
>
> >There are actually quite a lot of places where the translation
> >phases break down. Most of them are where the order WITHIN a
> >phase is important, but there is no such specification.
>
> If it's the order within a phase, then it's not a phase problem.
>
> The phases of translation stuff means that each phase should be able to
> be implemented as a separate pass of a multi-pass compiler. As far as I
> know that can currently always be done. You would break it.
That is a silly thing to say.
Most of those phases are just used to try to simplify the standard.
(And I don't think they actually do it to any significant degree.)
If they are getting in the way of something useful, they should
be tossed out.
> > Pragmas (or other preprocessing directives) that affect
> >preprocessing in any way not specifically mentioned by the
> >standard.
>
> I could argue that the phases of translation mean these can't affect the
> behavior of phases 1 to 3. Nonetheless, you're stepping outside the
> Standard with them.
>
> >Exactly when array parameters are converted to pointers,
>
> All within TP7.
>
> >To set the record straight, I think that this is a horrible way
> >of proceeding, and I would much prefer the C standard to permit
> >alternate conforming behaviour - i.e. implementation-defined,
> >with recommended practice that both be user-selectable in any
> >compiler.
>
> I wouldn't - it makes it impossible to write a translation unit
> conforming on all conforming implementations.
Not true.
Just never put two question marks together and
you will not have a problem.
That is a rule I try to live with today.
You don't actually use trigraphs in your code do you??(opps)
Digraphs solve all of the problems that trigraphs were
invented to solve without the problems that trigraphs cause.
Dennis Yelle
Douglas A. Gwyn
> ... Providing it behaves as the character represented by \
> in the text of the Standard, I see nothing requiring it to have a
> particular glyph (a term that does not appear in TP2).
I agree -- the "intuitive" glyphs would resemble the ones printed
in the standard, but actual glyphs might be anything that the
users will tolerate. Remember early DECwriters? It was hard
sometimes to figure out what a character was supposed to be from
the glyph, until you got used to them.
Nick Maclaren
Clive D.W. Feather <cl...@demon.net> wrote:
>In article <719oh6$t1$1...@pegasus.csx.cam.ac.uk>, Nick Maclaren
><nm...@cus.cam.ac.uk> writes
>>|> %:pragma STDC TRIGRAPHS off ??/
>>|>
>>|> Is this acceptable ? At what point does the change take effect ? Suppose
>>|> that I want to do TP1-3 as a separate pass, or as a module with
>>|> significant buffering ? Have I got to backtrack and reinterpret the
>>|> entire source ?
>>
>>It needs clarification, yes, but I don't think that it is a major
>>problem. The code affected by trigraphs and that involved in the
>>STDC pragma directives don't interact.
>
>%: pragma STDC TRIGRAPHS /* ??/* on // */ off
>
>They definitely interact.
That's not how I read the standard. My reading is that a preprocessor
directive is not 'evaluated' until the end of line indicator is
reached (or the closing parenthesis for a pragma operator.) But I
agree that some clarification is needed - and NOT just because of this.
>>The obvious definition is
>>that it takes effect when the complete pragma directive has been
>>read and decoded, so the above is NOT one - but it could be, if
>>the next line were blank. As far as I know, no implementation
>>has ever used the phase 1-4 distinction introduced by C89.
>
>I'm not sure that's a valid argument.
Expand it to saying that the phase definition is actually erroneous,
and should have only four levels: preprocessing, compilation, binding
and execution. The extra levels (1-3) were introduced for solely
descriptive purposes and had no prior art, but seem to have become
equal in status with the main levels.
>> Pragmas (or other preprocessing directives) that affect
>>preprocessing in any way not specifically mentioned by the
>>standard.
>
>I could argue that the phases of translation mean these can't affect the
>behavior of phases 1 to 3. Nonetheless, you're stepping outside the
>Standard with them.
Yes. I am not denying that this is a horrible solution.
>>Exactly when array parameters are converted to pointers,
>
>All within TP7.
Yes but, in CD2, only in a footnote.
>>To set the record straight, I think that this is a horrible way
>>of proceeding, and I would much prefer the C standard to permit
>>alternate conforming behaviour - i.e. implementation-defined,
>>with recommended practice that both be user-selectable in any
>>compiler.
>
>I wouldn't - it makes it impossible to write a translation unit
>conforming on all conforming implementations.
It is (effectively) at present. There are no useful or realistic
strictly conforming programs - cue another rant :-(
There are a LOT of features that cannot be used in strictly conforming
code, and I don't see that making trigraphs another is a major
handicap. To clarify things, my main interest is in getting
mandatory diagnostics - this is because there are two, almost equally
influential, camps that treat them incompatibly.
Larry Jones
>
> >>Exactly when array parameters are converted to pointers,
> >
> >All within TP7.
>
> Yes but, in CD2, only in a footnote.
This has little to do with Nick's main point, but I wanted to clarify
that this is *NOT* true in CD2 (although it was true in CD1). See
6.7.5.3p6 and 6.9.1p7 respectively for the prototype and non-prototype
cases.
-Larry Jones
Why is it you always rip your pants on the day everyone has to
demonstrate a math problem at the chalkboard? -- Calvin
Nick Maclaren
Larry Jones <larry...@sdrc.com> wrote:
>Nick Maclaren wrote [quoting others]:
>>
>> >>Exactly when array parameters are converted to pointers,
>> >
>> >All within TP7.
>>
>> Yes but, in CD2, only in a footnote.
>
>This has little to do with Nick's main point, but I wanted to clarify
>that this is *NOT* true in CD2 (although it was true in CD1). See
>6.7.5.3p6 and 6.9.1p7 respectively for the prototype and non-prototype
>cases.
Yes, it is a different point but, no, I am afraid that it is NOT
completely specified by those paragraphs. In particular, they do
not specify the compilation ordering (which is where the phase
problems come in.) Consider:
1) A compiler parses the text, converts array parameters to
pointers and creates a parse tree; it then performs type compatibility
checking and sizeof interpretation on that parse tree.
2) A compiler parses the text, performs type compatibility and
sizeof interpretation and creates a parse tree; it then converts
array parameters to pointers in that parse tree.
There is NOTHING that I can find that specifies which model should be
used, except for that footnote. Of course, we all know that the
first one is the expected approach, despite the fact that a naive
reader (and every language that I have ever heard of except for C)
would assume the second. But the standard doesn't SAY so.
And the difference is significant. Not merely do different sets of
types become compatible, but sizeof changes value.