How would you design C's replacement?

[Rui Maciel]

I think if you set out to design a replacement for C - that is, a C
without all the defects - you'd end up with something very close to D
(from Walter Bright). From what I've read, D is what C should have been.

The same is said about C++ (the language's motto was something like "a
better C"), and the fact of the matter is that the C++ programming language
is one of the most popular programming languages ever devised.

That D hasn't taken the world by storm should tell us (all of us)
something about what the market thinks of the idea of a replacement for C.

Yes, it should tell us that the C++ programming language exists, and that
the D programming language doesn't offer any meaningful improvement over C++
while presenting some disadvantages as well.


Rui Maciel

 

[Tim Rentsch]

Surely there were better ways to address that issue.

That's probably true, but I think the underlying point is valid.
Trigraphs were made part of C to overcome an important limitation
for a significant (undoubtedly small, but still significant) part
of its intended audience. Granted, trigraphs are ugly, but given
that they were made part of the Standard they can't just be
discarded without regard to those for whom trigraphs were put in
to C in the first place. Even though most developers never use
trigraphs (I know I don't), they are important to some code
development. Has anyone made an effort to find out how much
legacy code there is that uses trigraphs? I'm not aware of any.

Personally, I don't see why anyone (who doesn't use trigraphs)
would care much one way or the other whether C has them. If
someone is concerned that trigraphs may occur unintentionally
in, eg, strings, it takes all of maybe 30 minutes to write
a tool to scan for them (or less if we can just use grep).
Just run the tool as part of regular compilation, flagging
the "error". Problem solved.

 

[Ben Pfaff]

Personally, I don't see why anyone (who doesn't use trigraphs)
would care much one way or the other whether C has them. If
someone is concerned that trigraphs may occur unintentionally
in, eg, strings, it takes all of maybe 30 minutes to write
a tool to scan for them (or less if we can just use grep).
Just run the tool as part of regular compilation, flagging
the "error". Problem solved.

If you use GCC, -Wtrigraphs (part of -Wall) solves the problem
without even spending those 30 minutes.

 

[Keith Thompson]

That's probably true, but I think the underlying point is valid.
Trigraphs were made part of C to overcome an important limitation
for a significant (undoubtedly small, but still significant) part
of its intended audience.

[snip]

Trigraphs are an effective refutation to the claim that C is perfect.

But nobody ever made such a claim, so ...

 

[Joe keane]

Trigraphs included?

Ritchie's C didn't have trigraphs.

ANSI's C didn't have trigraphs (except for ISO).

So it's just a monumental screw-up by ISO, and everyone just ignores them.

cc --enable-trigraphs --im-serious-enable-trigraphs
--no-i-am-not-insane

 

[J. J. Farrell]

Ritchie's C didn't have trigraphs.

ANSI's C didn't have trigraphs (except for ISO).

The first ISO C Standard was based on the first ANSI C Standard, and the
languages defined by the two were identical; both included trigraphs, as
have all subsequent ANSI and ISO C Standards.

So it's just a monumental screw-up by ISO,

No, by ANSI.

 

[Tim Rentsch]

That's probably true, but I think the underlying point is valid.
Trigraphs were made part of C to overcome an important limitation
for a significant (undoubtedly small, but still significant) part
of its intended audience.

[snip]

Trigraphs are an effective refutation to the claim that C is perfect.

But nobody ever made such a claim, so ...

So it's important to keep trigraphs in C, in case
someone ever does?

;-)

 

[jacob navia]

Le 11/05/12 17:36, Tim Rentsch a écrit :

Right. In fact I have -Wtrigraphs set in my own standard build
environment, and it's been there so long I'd forgotten that I did.
And I presume most other implementations provide a similar option.
So I guess the suggestion was made just for those unfortunate
souls whose compiler isn't so equipped.

So, you propose to mask the bug in the language by making all compilers
be non-conformant.


GREAT!

 

[Kenny McCormack]

Either that or the advantages of being a mainstream language compared
to something as fringe a D are almost always overwhelming, no matter
what the technical merits are. D might well be the greatest thing
since sliced bread (or not), but I don't know enough to judge.

Rui completely missed the point, as I've come to expect from him.

But just to make it clear, what I was arguing was that *if* you were going
to set out to replace C, you'd end up with something like D. That it hasn't
happened, tells you something about the wisdom of trying to replace C.

To be clear, the whole point is that D is C without the bugs, while C++ is C
embraced, expanded, enhanced, while keeping (most of) the bugs.

The bugs are what make C C. And, no, I'm not here to argue about what is
and isn't a bug in C - except to say that I do agree with what Walter says
about it on his site (which I haven't read in several years, so don't bother
nitpicking me on specifics). But the one I remember the best is the idea
that there should be no warnings. A construct should either be correct or
wrong (a syntax error); that C has so much stuff that is "warning" level is
(in this view) a bug.

 

[Ben Pfaff]

Le 11/05/12 17:36, Tim Rentsch a écrit :

So, you propose to mask the bug in the language by making all compilers
be non-conformant.

A compiler is allowed to issue a diagnostic for anything it
likes.

 

[Ben Pfaff]

So it's important to keep trigraphs in C, in case
someone ever does?

The existence of trigraphs means that no future version of C can
be perfect. If the future version has trigraphs, then it is
marred by their presence. If it does not have trigraphs, then it
falls short of perfection by failing to be backward compatible.

 

[Tim Rentsch]

Le 11/05/12 17:36, Tim Rentsch a @C3{A9}crit :

So, you propose to mask the bug in the language by making all compilers
be non-conformant.

Please read my comments again. I didn't propose, nor do I
propose, any such thing. What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs. I
am not advocating making any changes to any compilers.

GREAT!

That's sarcasm, isn't it? If you have something to say,
I'd prefer you say it straight out.

 

[jacob navia]

Le 11/05/12 18:41, Tim Rentsch a écrit :
.. What I did say was that anyone

who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.

Easily?

Who knows about trigraphs?

How can you knwow that a trigraph in a comment van make for a syntax
error 365 lines later?


int fn(void)
{
for (int i=0; i<100;i++) // is this is correct??/
{
.. 365 lines of code
}
}

This code produces
/tmp $ g++ trigraphs.c
trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable

So the compiler is non conforming

Most compilers do ignore trigraphs but many don't. You are just saying:

Instead of correcting the bug at the source (the bad specifications)
let's accept a workaround that masks the bug

 

[Ben Pfaff]

/tmp $ g++ trigraphs.c
trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable

So the compiler is non conforming

You have to add -trigraphs to run in conforming mode (in that
respect). So?

 

[jacob navia]

Le 11/05/12 19:49, Gareth Owen a écrit :

It's Jacob. What you actually said is pretty much irrelevant.

You are like that. What I actually said is that it is not the
compiler's task to correct the language.

Mr Rentsch said:

"
What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.
"
No, it is not easy (you have to KNOW about trigraphs in the first place)
then it is not the task of compilers to correct the bugs in the
language!

The fact that that option EXISTS is already the proof that the bug in
the language exists.

 

[jacob navia]

Le 11/05/12 19:50, Ben Pfaff a écrit :

You have to add -trigraphs to run in conforming mode (in that
respect). So?

So, it would be better if the bug was corrected at its source: the
badly specified C standard, that specifies those trigraphs!

That is what I am arguing. Mr Rentsch says that it is
"
What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.
"
No, it is not easy (you have to KNOW about trigraphs in the first place)
then it is not the task of compilers to correct the bugs in the
language!

The fact that that option EXISTS is already the proof that the bug in
the language exists.

 

[Tim Rentsch]

Le 11/05/12 18:41, Tim Rentsch a @C3{A9}crit :
. What I did say was that anyone

who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.

Easily?

Who knows about trigraphs?

How can you knwow that a trigraph in a comment van make for a syntax
error 365 lines later?


int fn(void)
{
for (int i=0; i<100;i++) // is this is correct??/
{
.. 365 lines of code
}
}

This code produces
/tmp $ g++ trigraphs.c
trigraphs.c:4:49: warning: trigraph ??/ ignored, use -trigraphs to enable

So the compiler is non conforming

Most compilers do ignore trigraphs but many don't. [snip]

Again, the scenario you're describing is not what I was
suggesting: 'while still using compilers that accept
trigraphs.' Please try to read more carefully.

 

[Tim Rentsch]

Le 11/05/12 19:49, Gareth Owen a @C3{A9}crit :

It's Jacob. What you actually said is pretty much irrelevant.

You are like that. What I actually said is that it is not the
compiler's task to correct the language.

Mr Rentsch said:

"
What I did say was that anyone
who is concerned about undesired trigraphs can easily prevent
them while still using compilers that accept trigraphs.
"
No, it is not easy (you have to KNOW about trigraphs in the first place)
[snip]

Surely anyone who is concerned about trigraphs already knows
about them. It would be nice if you would respond to what I
actually write, rather than just repeating your "trigraphs
are bad" talking points.

 

[Tim Rentsch]

The existence of trigraphs means that no future version of C can
be perfect. If the future version has trigraphs, then it is
marred by their presence. If it does not have trigraphs, then it
falls short of perfection by failing to be backward compatible.

That's true! Now I am forever doomed to be closely familiar
with an imperfect programming language. Oh wait.. maybe
the next revision will change the language so much it
will be completely unrecognizable. So there is still hope...

 

[David Thompson]

far more common problems are things like:
mistyping function names;
messing up the number or types of function arguments;
accidentally doing bad type conversions;
...

in GCC there were options to make the compiler reject the code more
readily in these cases, but annoyingly MSVC is a bit more prone to let
it through (usually just giving warnings), without options to turn up
the strictness.

Huh? Every MSVC I've used, back to 1998, had /W<level> and /WX.
Finding the 'official' place in the IDE to set them might be a little
work, but you can always insert manual settings if necessary.

this isn't to say that a person needs Java levels of strictness (where
every implicit type-conversion is an error, ...), but the compiler being
like "oh well, whatever" about implicit conversions between pointers and
integers or similar (or between incompatible pointer types) is probably
a bit too lax.

Java allows essentially the same implicit conversions as C++, allowing
for the minor differences between their primitive type and object
hierarchy, and the major difference in the way arrays work.
It is (mandatorily) stricter about initializing local variables before
they are used -- and always initializing objects and arrays. And
(optionally) more vocal about shadowing, dead stores, and such, than
most C (or C++) compilers I have used -- although C compilers
certainly can and may have such warnings, and some do.

C89 (and later) requires a cast to convert between pointers and
integers, or pointers that aren't to 'nearly' the same type or void.