Lcc win overflow handling

[jacob navia]

There was a recent thread about overflow handling. In that thread I
mentioned the two solutions that lcc-win proposes to detect overflow
efficiently.

(1) Direct handling of the overflow flag. This is risky and has some
drawbacks. Since C is not assembly, you can't be sure that some other
operation hidden within the C code modifies the flags. Besides, its
generalization is faulty since some machines integrate the overflow
handling into special versions of the four operations that trap
on overflow.

(2) The other option is just to pass a compile time argument to the
compiler that should call a function when oveerflows occurs. It
is the responsability of the compiler to figure out how to do that.
The only thing that you know is that a function will be called
telling you the source line and the file name of the place in
your code where overflow occurred. You can replace the default
function with a function of your own that does something else as
the default action, i.e. aborting the program. If your replacement
function returns, the code will go on exactly after the operation
that overflowed happened. The compiler saves all registers and
restores them after your function returns, oso the code will go on
with a random result.

The regulars here (kuyper, heathfield, thomson) started complaining that
the first solution "is not portable" without ever mentionig the second
solution. This message is intended to start a constructive discussion
so I would ask mr kuyper for instance, that says:

"I have learned to read as little as possible of what you write" that
they refrain from participating in the discussion to the benefit of his
blood pressure.

Thanks in advance.

 

[Keith Thompson]

There was a recent thread about overflow handling. In that thread I
mentioned the two solutions that lcc-win proposes to detect overflow
efficiently.

(1) Direct handling of the overflow flag. This is risky and has some
drawbacks. Since C is not assembly, you can't be sure that some other
operation hidden within the C code modifies the flags. Besides, its
generalization is faulty since some machines integrate the overflow
handling into special versions of the four operations that trap
on overflow.

(2) The other option is just to pass a compile time argument to the
compiler that should call a function when oveerflows occurs. It
is the responsability of the compiler to figure out how to do that.
The only thing that you know is that a function will be called
telling you the source line and the file name of the place in
your code where overflow occurred. You can replace the default
function with a function of your own that does something else as
the default action, i.e. aborting the program. If your replacement
function returns, the code will go on exactly after the operation
that overflowed happened. The compiler saves all registers and
restores them after your function returns, oso the code will go on
with a random result.

The regulars here (kuyper, heathfield, thomson) started complaining that
the first solution "is not portable" without ever mentionig the second
solution. This message is intended to start a constructive discussion
so I would ask mr kuyper for instance, that says:

"I have learned to read as little as possible of what you write" that
they refrain from participating in the discussion to the benefit of
his blood pressure.

I've discussed your second solution at some length, pointing out
possible problems and suggesting alternatives.

As for the first solution, do you have a problem with the fact that
we discussed it?

You've said that you posted these as proposals to comp.std.c.
I don't doubt that you did, but I don't remember the specifics, and
I'd like to consult that article and the ensuing thread. Can you
provide any of the following: a Google Groups URL, a message-id,
the subject header, or the date?

And please spell my name correctly. It's Thompson, with an 'h'
and a capital 'T'. (Most of us here address each other by our
first names, but you can do as you like.)

 

[jacob navia]

Keith Thompson a écrit :

I've discussed your second solution at some length, pointing out
possible problems and suggesting alternatives.

As for the first solution, do you have a problem with the fact that
we discussed it?

You did not discuss it at all.

For instance that kuyper. He answers me pointing out that the
_overflow() functions has some drawbacks. I point him to the second
solution and he answers that he did not read it because

"I have learned to read as little as possible of what you write"

What do you want me to do with this kind of "discussion"?

The ONLY objective here is to denigrate me or to prove I am wrong
because I do not adhere to the regular's pedantic attitude.

This guy phil carmody says that the alpha has no overflow flags
implying of course that there is no way to detect overflow. When
I prove him wrong he sends a message complaining that I changed
addresses and his killfile doesn't work any more.

Great.

Who are this people?

What have they produced for the C community besides being arrogant
here?

One of the most ridiculous cases is Tom St Denis that wrote here:

if (a*b < a || a*b < b) then overflow...

Crazy but true.

And that guy wrote a book about big int implementation
GREAT!

You've said that you posted these as proposals to comp.std.c.
I don't doubt that you did, but I don't remember the specifics, and
I'd like to consult that article and the ensuing thread. Can you
provide any of the following: a Google Groups URL, a message-id,
the subject header, or the date?

I do not remember either, it was a long time ago. I remember
I started that discussion.

One thread I could find was
http://www.archivum.info/comp.lang.c/2005-12/00561/Re:_detecting_integer_overflow
where I discussed again that. But I do not find the original thread.

 

[jacob navia]

I tried searching in google within the comp.std.c group

A search for "overflow" yields nothing even if there are hundreds of
articles with that word in their bodies.

So I started searching manually clicking in the "previous messages"
button.

But when I arrived at 2005, google said:

<quote>

We're sorry...

.... but your query looks similar to automated requests from a computer
virus or spyware application. To protect our users, we can't process
your request right now.

We'll restore your access as quickly as possible, so try again soon. In
the meantime, if you suspect that your computer or network has been
infected, you might want to run a virus checker or spyware remover to
make sure that your systems are free of viruses and other spurious software.
<end quote>

And none of the commands would work anymore.

SInce they do not provide with a mean to jump directly to 2005
there is no way to go beyond that.

 

[Keith Thompson]

Keith Thompson a écrit :

You did not discuss it at all.

What? I've personally posted several articles discussing your first
option, and at least two discussing your second. Do I need to provide
you with message-ids?

For instance that kuyper. He answers me pointing out that the
_overflow() functions has some drawbacks. I point him to the second
solution and he answers that he did not read it because

"I have learned to read as little as possible of what you write"

What do you want me to do with this kind of "discussion"?

Since you ask, I want you to stop whining about it in public.
He insulted you. Move on with your life. (And before you complain
about what I just wrote, keep in mind that you asked for my advice.)

The ONLY objective here is to denigrate me or to prove I am wrong
because I do not adhere to the regular's pedantic attitude.

Complete nonsense.

This guy phil carmody says that the alpha has no overflow flags
implying of course that there is no way to detect overflow.

He said, entirely correctly as far as I can tell, that the Alpha
has no overflow flag. You even posted excerpts from the Alpha
assembler manual that confirmed that fact.

He did not say or imply that "there is no way to detect overflow".
In fact it is entirely possible to detect overflow on the DEC Alpha;
methods for doing so just don't happen to use an overflow flag.
Nobody has said otherwise.

His point, I think, was that the fact that the Alpha uses methods
other than an overflow flag to detect overflow implies that your
_overflow() function is not suitable for an Alpha implementation.
I'm not sure now whether you ever proposed something like _overflow()
as an addition to the C standard. If you haven't, then there
doesn't seem to be anything to argue about.

When
I prove him wrong he sends a message complaining that I changed
addresses and his killfile doesn't work any more.

When did you prove him wrong? I must have missed that.

[snip]

One of the most ridiculous cases is Tom St Denis that wrote here:

if (a*b < a || a*b < b) then overflow...

Crazy but true.

And that guy wrote a book about big int implementation
GREAT!

Somebody made a mistake. You and I have both made our share of them.
So what?

[...]

 

[Richard Tobin]

A search for "overflow" yields nothing even if there are hundreds of
articles with that word in their bodies.

Works fine when I try it. This URL returned 146 hits:

http://www.google.com/groups?q=group:comp.lang.c+overflow&as_scoring=d&lr=lang_en&scoring=d

-- Richard

 

[Antoninus Twink]

His point, I think, was that the fact that the Alpha uses methods
other than an overflow flag to detect overflow implies that your
_overflow() function is not suitable for an Alpha implementation.

Utter bullshit, Keith.

Just who do you think is impressed by your pathetic Jacob-bashing? Why
not leave that crap to your pal Heathfield?

 

[robertwessel2]

There was a recent thread about overflow handling. In that thread I
mentioned the two solutions that lcc-win proposes to detect overflow
efficiently.

(1) Direct handling of the overflow flag. This is risky and has some
    drawbacks. Since C is not assembly, you can't be sure that some other
    operation hidden within the C code modifies the flags. Besides, its
    generalization is faulty since some machines integrate the overflow
    handling into special versions of the four operations that  trap
    on overflow.

(2) The other option is just to pass a compile time argument to the
    compiler that should call a function when oveerflows occurs. It
    is the responsability of the compiler to figure out how to do that.
    The only thing that you know is that a function will be called
    telling you the source line and the file name of the place in
    your code where overflow occurred. You can replace the default
    function with a function of your own that does something else as
    the default action, i.e. aborting the program. If your replacement
    function returns, the code will go on exactly after the operation
    that overflowed happened. The compiler saves all registers and
    restores them after your function returns, oso the code will go on
    with a random result.

The regulars here (kuyper, heathfield, thomson) started complaining that
the first solution "is not portable" without ever mentionig the second
solution. This message is intended to start a constructive discussion
so I would ask mr kuyper for instance, that says:

"I have learned to read as little as possible of what you write" that
they refrain from participating in the discussion to the benefit of his
blood pressure.

The problem with the first solution is that it won't work well, even
on x86, without the generation of substantial amounts of extra code.
Of course with enough code a sticky overflow flag could be made to
work on any platform.

The problem with the second is that it's as tough to deal with code
generation wise as the first, and I'm not sure that calling an
exception handler really improves my life a lot as compared to the
first option.

IMO, overflow detection should be a pretty local option, and the cost
of detecting overflow should only be incurred where it's needed. As
an example, consider the arithmetic statements in Cobol, which all
support an optional "overflow" clause. As a simple case you can
(roughly) do:

compute x = a*100+b
on size error
__do something__

The compiler is obligated to correctly and reliably detect if the
assignment to x will overflow (on size error also catches things like
divide-by-zero). That's a useful feature. Note that the Cobol
compiler is *also* obligated to generate wider intermediates if
necessary to perform the computation correctly.

One problem with your solutions is that they're not well bounded as to
what's being checked, and when I care for things to be checked (heck C
specifically defines unsigned fields as not overflowing, while I can
most certainly see that I might want to detect an "overflow" assigning
a value to an unsigned integer - sticking with Cobol for a second,
overflow detection is certainly not conditioned on the signedness of
the target). Something akin to an exception-like block delimiting an
overflow checked bit of code might work (which would at least let you
limit the overhead to the places where it’s wanted), but how that
impacts subroutines that you might call from within that block is a
difficult issue. And it's hard to say exactly what overflow *is* in
this context. In the Cobol case it's well defined, and in a useful
way - what I *really* care about is if the final result is accurate/
meaningful, not the details of the intermediate steps.

At this point I don't see a sufficient definition of what you're
proposing to catch, and without that, I'm not sure how useful it might
be. For example, what if (using 16 bit ints) you add +20000, +20000,
and -10000. Overflow or not? What code will you need to generate to
detect it? I’m having difficulty seeing that meaning overflow
detection is really possibly given the way arithmetic is defined in C,
at least with ordinary types. And perhaps that’s an answer – a new
set of numeric types that obeys more “conventional” arithmetic rules,
like the types in Cobol.

 

[jacob navia]

(e-mail address removed) a écrit :

The problem with the first solution is that it won't work well, even
on x86, without the generation of substantial amounts of extra code.
Of course with enough code a sticky overflow flag could be made to
work on any platform.

True

The problem with the second is that it's as tough to deal with code
generation wise as the first, and I'm not sure that calling an
exception handler really improves my life a lot as compared to the
first option.

(1) The code generation is very simple for the x86 or power pc families.
In general RISC/CISC code generation presents no problems at all
for this application.

In the x86 the code is very simple:
Code showing the operation being done not shown
jno _$L476
pusha
pushl $42
pushl\t$__functionlabel
call __overflow
addl\t$8,%%esp
popa
_$L476:
(1) I test the overflow flag. If not set I skip the code calling the
handler.
(2) I save all registers in the stack
(3) I push the line number
(4) I push the function name
(5) I call the handler
(6) If the handler returns I adjust the stack
(7) restore all registers
(8) The rest of the code

In the power pc you would choose an instruction that sets the flags,
then test those flags etc.

IMO, overflow detection should be a pretty local option, and the cost
of detecting overflow should only be incurred where it's needed. As
an example, consider the arithmetic statements in Cobol, which all
support an optional "overflow" clause. As a simple case you can
(roughly) do:

compute x = a*100+b
on size error
__do something__

The compiler is obligated to correctly and reliably detect if the
assignment to x will overflow (on size error also catches things like
divide-by-zero). That's a useful feature. Note that the Cobol
compiler is *also* obligated to generate wider intermediates if
necessary to perform the computation correctly.

This problem can be solved with the #pragma feature. I proposed a
#pragma overflowcheck(on/off)
that would mark the parts of the code where you want overflow checking.

One problem with your solutions is that they're not well bounded as to
what's being checked, and when I care for things to be checked (heck C
specifically defines unsigned fields as not overflowing, while I can
most certainly see that I might want to detect an "overflow" assigning
a value to an unsigned integer - sticking with Cobol for a second,
overflow detection is certainly not conditioned on the signedness of
the target).

Only the signed for operations are checked.

Something akin to an exception-like block delimiting an
overflow checked bit of code might work (which would at least let you
limit the overhead to the places where it’s wanted), but how that
impacts subroutines that you might call from within that block is a
difficult issue.

No. If they have overflow checking they will check, if not they will
not check!

Very easy.

And it's hard to say exactly what overflow *is* in
this context. In the Cobol case it's well defined, and in a useful
way - what I *really* care about is if the final result is accurate/
meaningful, not the details of the intermediate steps.

The same here

At this point I don't see a sufficient definition of what you're
proposing to catch, and without that, I'm not sure how useful it might
be. For example, what if (using 16 bit ints) you add +20000, +20000,
and -10000. Overflow or not?

If you use 16 bit ints yes. If you use intermediate 32 bit ints no.

What code will you need to generate to
detect it? I’m having difficulty seeing that meaning overflow
detection is really possibly given the way arithmetic is defined in C,
at least with ordinary types. And perhaps that’s an answer – a new
set of numeric types that obeys more “conventional” arithmetic rules,
like the types in Cobol.

In C the operations are done with ints, and if ints are 32 bits there is
no overflow. If you do have an intermediate overflow with 32 bit ints
then there will be a trap. Since you want accurate results, it is
better to trap than to return a result completely meaningless!

What is incredible is that in all this discussion the fact that a
meaningless results is computed doesn't seem to bother anyone.

What is important in the mind of many people here is that FAST
results are computed. If they are wrong nobody cares!

 

[Tom St Denis]

Feeding the troll...

One of the most ridiculous cases is Tom St Denis that wrote here:

if (a*b < a || a*b < b) then overflow...

Crazy but true.

It was in response to your "divisions are expensive" line.

In fact, in the libraries where I have to deal with carries or sign
propagation I exploit 2's complement and just shift.

For instance, in my subtraction code I have a loop that looks like:

for (x = 0; x < oldbused; x++) {
t = ((fp_word)a->dp[x]) - (((fp_word)b->dp[x]) + t);
c->dp[x] = (fp_digit)t;
t = (t >> DIGIT_BIT)&1;
}

Where fp_word is double precision [e.g. 64-bits on a 32-bit host],
fp_digit is single precision [e.g., 32-bits on a 32-bit host]. in
this case the 33rd bit is set if the subtraction produced a carry
(e.g. a->dp[x] < b->dp[x] + t).

So for every platform with 2's complement math this is correct,
doesn't rely on any 'flags,' and is very efficient.

The example I gave was contrived, as I don't do signed math [on that
basis] in my libraries. In my math libraries the numbers are
represented by an array of unsigned integers and a sign flag. So my
low-level C * multiplications are all of unsigned values. I extract
the high words by using double precision data types.

Tom

 

[Keith Thompson]

What is incredible is that in all this discussion the fact that a
meaningless results is computed doesn't seem to bother anyone.

What is important in the mind of many people here is that FAST
results are computed. If they are wrong nobody cares!

jacob, I think you've misunderstood the arguments. I don't recall
anyone arguing *against* the idea of overflow checking, as long as
it's optional so existing correct code isn't made slower. (For
example, if I've done an analysis that shows a given chunk of code
can't cause an overflow, I don't want the compiler inserting
additional code to check for overflow -- except perhaps during
testing.)

Various posters, including me, have pointed out what we think are
problems with your specific proposals.

We're not arguing against the idea of overflow checking (at least
I'm not), we're looking for better ways to define it.

(And nobody has even suggested using Ada, which has overflow
checking built into the language, rather than C.)

 

[Amandil]

And please spell my name correctly.  It's Thompson, with an 'h'
and a capital 'T'.  (Most of us here address each other by our
first names, but you can do as you like.)

On that note, Mr. Thompson, I've always wondered: Any relation to Ken
(the famous one)?

-- Marty Amandil

 

[jacob navia]

Keith Thompson a écrit :

jacob, I think you've misunderstood the arguments. I don't recall
anyone arguing *against* the idea of overflow checking, as long as
it's optional so existing correct code isn't made slower. (For
example, if I've done an analysis that shows a given chunk of code
can't cause an overflow, I don't want the compiler inserting
additional code to check for overflow -- except perhaps during
testing.)

I proposed the "pragma solution, but apparently, even if I repeated it
several times, this is ignored.

Various posters, including me, have pointed out what we think are
problems with your specific proposals.

Neither you nor anybody else said anything about

#pragma overflowcheck(on/off)

This option would be issued at the global level
(not within a function), to turn on/off overflow
checking for specified functions.

Rationale:

Compilers move code around, join common sub expressions, etc

That wouldn't be possible if overflow checked/unchecked
code would be merged.

This option calls a callback function with the prototype:

void (overflowcallback)(unsigned line,char *function-name);

This function pointer points to a function that receives the line number
and the function name where the overflow occurred.

The user can assign to this function pointer any function at any
time during the execution of the program

We're not arguing against the idea of overflow checking (at least
I'm not), we're looking for better ways to define it.

Strange strange. I did not see a SINGLE positive proposal besides
the usual polemic against me.

I have implemented this stuff, this is not just empty talk.

(And nobody has even suggested using Ada, which has overflow
checking built into the language, rather than C.)

I think C should have this as an optional feature.

 

[Beej Jorgensen]

What is important in the mind of many people here is that FAST
results are computed.

That's because we have "make the common case fast" branded on our
frontal lobes. Overflow is relatively uncommon, and perhaps downright
rare.

When I'm looping from 0 to 999, I absolutely positively do not want
overflow checking on my i++ unless it is absolutely positively 100%
free. And I think you're going to have trouble making it free on all
platforms.

If they are wrong nobody cares!

I think you're mistaken about that. Just because a particular method of
testing for errors is unpopular doesn't mean the people involved aren't
interested in catching them. When I need overflow checking, I'll do it
myself [1].

Besides, I already said I'd consider a #pragma to turn this kind of
checking on.

-Beej

[1] CERT: "Ensure that operations on signed integers do not result in
overflow" http://preview.tinyurl.com/lcpye8

 

[Keith Thompson]

On that note, Mr. Thompson, I've always wondered: Any relation to Ken
(the famous one)?

No (though I was once mistaken for him).

And yes, I'm sure that we're not related, or at least that if we
are the shared last name is coincidental. The name "Thompson"
doesn't go back very many generations in my family, and if Ken
and I shared a common Thompson ancestor I'd know about it.

 

[Bart]

Strange strange. I did not see a SINGLE positive proposal besides
the usual polemic against me.

I have implemented this stuff, this is not just empty talk.

I've never bothered with int overflow checking before (I just relied
on wrong results to tell me there was a problem). But for fun I
applied your second method to an interpreted language project (so it
only took a couple of minutes to modify Add and Multiply).

Now finally, when I run a factorial program, I get this:

1! = 1
2! = 2
3! = 6
4! = 24
5! = 120
6! = 720
7! = 5040
8! = 40320
9! = 362880
10! = 3628800
11! = 39916800
12! = 479001600
13! =int overflow on Line 22 in t.pcm called from ...

instead of getting 13! = 1932053504. This is jolly good, I might leave
it in (or possibly make it switch to wider precision).

(I am using the simpler 'jo errorroutine' form (relying on existing
language features for error reporting), so the overhead is less, and
in the context of interpreted code, is insignificant.)

So I think this would be a useful feature for C.

 

[jacob navia]

Beej Jorgensen a écrit :

Besides, I already said I'd consider a #pragma to turn this kind of
checking on.

-Beej

[1] CERT: "Ensure that operations on signed integers do not result in
overflow" http://preview.tinyurl.com/lcpye8

We agree then!

 

[Keith Thompson]

Keith Thompson a écrit :

I proposed the "pragma solution, but apparently, even if I repeated it
several times, this is ignored.

You've posted several different versions of your proposal. It's
difficult to keep track of them.

In one particular article to which I responded, you wrote:

| There was a recent thread about overflow handling. In that thread I
| mentioned the two solutions that lcc-win proposes to detect overflow
| efficiently.
|
| (1) Direct handling of the overflow flag. This is risky and has some
| drawbacks. Since C is not assembly, you can't be sure that some other
| operation hidden within the C code modifies the flags. Besides, its
| generalization is faulty since some machines integrate the overflow
| handling into special versions of the four operations that trap
| on overflow.
|
| (2) The other option is just to pass a compile time argument to the
| compiler that should call a function when oveerflows occurs. It
| is the responsability of the compiler to figure out how to do that.
| The only thing that you know is that a function will be called
| telling you the source line and the file name of the place in
| your code where overflow occurred. You can replace the default
| function with a function of your own that does something else as
| the default action, i.e. aborting the program. If your replacement
| function returns, the code will go on exactly after the operation
| that overflowed happened. The compiler saves all registers and
| restores them after your function returns, oso the code will go on
| with a random result.

I took that to be your summary of what you're proposing. In that
summary, your second proposal implies that (a) the setting is
controlled by a "compile time argument to the compiler" (a
command-line option?), and that (b) the setting would apply to an
entire translation unit.

I don't respond to everything you write. Apparently you posted one
article with no mention of #pragma, and another in which you do
mention #pragma, and I happened to respond to the first.

If you had a single coherent proposal, it would be easier to discuss
it. I understand that creating a single coherent proposal isn't easy,
and can be the result of lengthy discussions. Given the number of
articles that have been posted on this topic in multiple threads, I'm
just having trouble keeping track.

Neither you nor anybody else said anything about

#pragma overflowcheck(on/off)

This option would be issued at the global level
(not within a function), to turn on/off overflow
checking for specified functions.

How are the affected functions specified? Are you saying that all
functions defined after "#pragma overflowcheck(on)" have overflow
checking enabled?

Rationale:

Compilers move code around, join common sub expressions, etc

That wouldn't be possible if overflow checked/unchecked
code would be merged.

Right, but if the #pragma inhibited such code movement, you could use
it within a function definition and have finer-grained control.

Incidentally, if you're proposing this as an addition to the language
standard it should probably be:

#pragma STDC OVERFLOW_CHECK on-off-switch

where on-off-switch is one of

ON OFF DEFAULT

See C99 6.10.6.

This option calls a callback function with the prototype:

void (overflowcallback)(unsigned line,char *function-name);

I think you mean:

void overflowcallback(unsigned line, char *function_name);

And I'd suggest "const char *function_name".

(I'm not entirely convinced that unsigned is the right type for the
line number, but it's ok.)

This function pointer points to a function that receives the line number
and the function name where the overflow occurred.

The user can assign to this function pointer any function at any
time during the execution of the program

Oh, I see, there's a function *pointer*. So in some standard header,
you want to have a declaration like this:

extern void (*overflowcallback)(unsigned line, const char *function_name);

and a program can modify its value. What's the initial value of this
object?

As I've said before, one problem with a callback fucntion is that it
doesn't have access to local variables in the function where the
overflow occurs. Several alternative proposals have been posted here
that don't have that problem.

Strange strange. I did not see a SINGLE positive proposal besides
the usual polemic against me.

Then you haven't been paying attention.

I have implemented this stuff, this is not just empty talk.


I think C should have this as an optional feature.

I don't disagree.

 

[jacob navia]

Richard Heathfield a écrit :

C /already/ allows this as an optional feature. Such features are
called "extensions", and lots of implementations provide extensions.

Incredible

The same people that at each message write

PORTABILITY PORTABILITY

and always brand anything lcc-win proposes as "unportable extensions"
propose... well to have extensions to plug in a hole in the language

Why?

Because I see that nobody is even starting to argue against this being
a big hole in the specs.

Why not close it with an optional construct that allows to check for
overflow for specified functions?

My proposal doesn't need any code modifications and could mean just a
global command line option, as it is in lcc-win now.

The increased granularity of a per function on/off setting would
further reduce the run time penalty to almost nothing.

When I started lcc-win, a recompilation of the compiler with itself took
25 seconds.

Now, it takes 2 seconds. From 1995 to 2009 we have a factor of 10 of
performance increase.

Many other CPU families are similar.

If C is to be used in environments where accuracy of results is
important then this option is an absolute necessity. Not everybody
is programming games...

 

[Keith Thompson]

C /already/ allows this as an optional feature. Such features are
called "extensions", and lots of implementations provide extensions.

Sure, but there's a difference between an ordinary extension (with
no guarantee of commonality from one implementation to another) and
a standardized but optional feature, like C99's IEC 60559 support,
which allows you to write code that's portable to all implementations
that support the feature.

But now that I think about it, I dislike the idea of making it an
"optional feature" in the sense that one implementation might support
it another might not. What I might like to see is a mandatory
feature, in the sense that all implementations must support it,
that imposes no costs on *programs* that don't use it.