Past overflow discussion

[jacob navia]

Finally I found the discussion that I started in comp.std.c.

It was on July 15th, 2004, the name of the thread was "integer overflow".

The first answer I got was from a certain "Dan Pop". He was the
"heathfield" of that time.

Here is it:
<quote>

People who care about such issues, detect the overflow *before* it
actually happens, so your feature is useless to them. It is also, by
definition, useless to people who don't care and to people who rely on
their implementations' behaviour upon integer overflow.

So, if you still didn't get it: you have a solution in search of a
problem.

<end quote>

This is the same reaction as our great current heathfield that proposed
testing for overflow with a cumbersome "straight C" construct.

Other answers were similar, specially from the representative of
the committee, Mr Gwyn:

<quote>

there is obviously no benefit to offset the cost
when the code is correct. Only erroneous implementation
sees any benefit. Perhaps effort is better put into code
correctness..

<end quote>

Great answers aren't they?

*Five years* later there isn't any reaction of the committee, and no
work in this is being done at all.

As far as I know.

 

[jacob navia]

Richard Heathfield a écrit :

Have you actually followed the ISO procedure for proposing a change to
the Standard?

Yes.

I called the French organization of norms: AFNOR.

They asked for 10 000 euros upfront.

Then, I would have to finance an expert committee to ponder about my
proposal.

There is no C group in the AFNOR now, since only the C++ group is
important enough. The C group was disbanded.

Another way to propose something is to spend thousands of dollars
in trips to all committee meetings. I do not have that money.

I asked if the committee could establish somewhere a web presence but
the answer were some ironic remarks, then silence.

Actually, committee members do not read this group, I have been told.

---
www.dictionary.com

pow·er·less
adj.
1. Lacking strength or power; helpless and totally ineffectual.
2. Lacking legal or other authority.


I would add:

3. Doesn't have any money.

 

[Gabriel Dos Reis]

| Richard Heathfield a écrit :
| >
| > Have you actually followed the ISO procedure for proposing a change
| > to the Standard?
| >
|
| Yes.
|
| I called the French organization of norms: AFNOR.
|
| They asked for 10 000 euros upfront.
|
| Then, I would have to finance an expert committee to ponder about my
| proposal.
|
| There is no C group in the AFNOR now, since only the C++ group is
| important enough. The C group was disbanded.

In fact, the C++ group used to also handle C-related documents. At
least that has been the case since 1998 or so. I haven't heard it
changed.

 

[jacob navia]

Gabriel Dos Reis a écrit :

| Richard Heathfield a écrit :
| >
| > Have you actually followed the ISO procedure for proposing a change
| > to the Standard?
| >
|
| Yes.
|
| I called the French organization of norms: AFNOR.
|
| They asked for 10 000 euros upfront.
|
| Then, I would have to finance an expert committee to ponder about my
| proposal.
|
| There is no C group in the AFNOR now, since only the C++ group is
| important enough. The C group was disbanded.

In fact, the C++ group used to also handle C-related documents. At
least that has been the case since 1998 or so. I haven't heard it
changed.

Sure. I think the C group disappeared at that time (1998)

 

[Frank]

No, he wasn't. He was much, much more acerbic than I am.

I think Richard and Dan are both a hoot. I would never equate them
though. (A Brit and a Romainian)

Dan answered questions with e-mail as I worked through the K&R
material for the first time, and he saved his invectives for those who
aroused his deep passions regarding the direction of this language.

The claim was made that there is no standard way to detect overflow in
C. I demonstrated that the claim was false, by showing a way to
detect overflow (*before* the event) in standard C. I also pointed
out that any implementation is already free to provide an extension
by which overflows can be detected in some non-standard way.

I'm surprised that IEEE stuff doesn't cover this for C. It does for
fortran. I notice in H&S V a single reference to IEEE, on p 135: IEEE
support in C is optional.

What does that mean? In fortran, you just build around the IEEE
modules. Is there a corresponding set of code for C?

 

[jacob navia]

Richard Heathfield a écrit :

If you can't afford to go the formal route, then you are going to have
to *persuade* ISO C committee members that your proposed change is
sufficiently worthwhile for them to champion it on your behalf.

Can't do that since I do not know even who they are.

ISO C
committee people are busy people (because they have a day job too),

And I am as busy as they are.

so they are not going to waste their time with arguments written in
crayon.

Let it be

If you want to persuade a serious, bright, busy person that
you are a serious, bright, worthy-of-spending-time-listening-to
person, you are going to have to change. If an ISO C committee member
reads of your attack on Doug Gwyn, it will not help to persuade him
that your proposal is worth reading.

I did not attack Mr Gwyn: I just QUOTED what he said. Of course if he
says such things that when quoted they sound like if I was attacking
him, it is his problem, not mine



He is the champion of gets(), that greatly designed function, still
in the current standard. Why should I attack him? He does that himself.

If he reads your articles in
this group where you call bright people "liar" or "moron", again it
will not help to convince him that you are worth reading.

Probably

In short: if you want to stand even a tiny chance of changing the
language, you are going to have to grow up and start recognising that
disagreeing with you does not necessarily imply that the person who
disagrees is a liar or a moron.

Of course not, and I have never treated Gwyn of liar or a moron.

Why should they establish a Web presence?

They *could* (gasp) try to work with the C community
instead of dicating standards that go where nobody wants to go.

If they are already getting
suggestions faster than they can handle them (which is quite likely),
establishing a Web presence would just soak up time, and maintaining
it credibly would soak up even more time.

Yes, it is a waste of time. Just go on like this.

At least one does: Lawrence Jones. Three other possibles: I don't know
whether Walter Banks is on the committee. Francis Glassborow, whom I
believe to be on the committee, certainly reads acllcc++, and I've
seen an occasional post of his in this group, possibly crossposts
from clc++. Peter Seebach moderates clcm (which is sortakinda this
group only not really), but I'm not sure if he's still on the
committee.

I am tired of this. The problem is that I try to change standard C.

What a waste of time.

asctime(), gets(), that's standard C. OK.

Who cares?

I will work in my implementation, and leave standard c to that wise
committee.

 

[jacob navia]

Mark McIntyre a écrit :

Yes.
What was your point? To prove that you indeed had a solution in search
of a problem? Perhaps you don't get it.

yeah i don't get it...

overflow?

not a problem, just go on with wrong results. We are in C. Anything
goes.

 

[Phil Carmody]

Yes.

<popping up-thread>

Seconded!

What was your point? To prove that you indeed had a solution in search
of a problem? Perhaps you don't get it.

I think if he'd have got it, he'd have got out, or at least
got out of our way.

Phil

 

[Nick Keighley]

I'm surprised that IEEE stuff doesn't cover this for C.  It does for
fortran.  I notice in H&S V a single reference to IEEE, on p 135: IEEE
support in C is optional.

What does that mean?  

in the 1999 C IEEE support is optional. There are ways for a program
to determine if IEEE is supported on a particular implementation. If
it is then various IEEE thingies are available. I'm not sure if
overflow detection is included. Of course IEEE only applies to
floating
point.

In fortran, you just build around the IEEE
modules.  Is there a corresponding set of code for C?

As noted above, C *may*, but doesn't have to, support IEEE.
C allows for other types of floating point presumably old ones
or simple ones of embedded systems.

 

[Gabriel Dos Reis]

| Gabriel Dos Reis a écrit :
| >
| > | Richard Heathfield a écrit :
| > | >
| > | > Have you actually followed the ISO procedure for proposing a change
| > | > to the Standard?
| > | >
| > | | Yes.
| > | | I called the French organization of norms: AFNOR.
| > | | They asked for 10 000 euros upfront.
| > | | Then, I would have to finance an expert committee to ponder
| > about my
| > | proposal.
| > | | There is no C group in the AFNOR now, since only the C++ group
| > is
| > | important enough. The C group was disbanded.
| >
| > In fact, the C++ group used to also handle C-related documents. At
| > least that has been the case since 1998 or so. I haven't heard it
| > changed.
| >
| >
|
| Sure. I think the C group disappeared at that time (1998)

I think I continued handling C-related issues after that year.

-- Gaby

 

[Frank]

On 5 Sep, 06:00, Frank <[email protected]> wrote:

in the 1999 C IEEE support is optional. There are ways for a program
to determine if IEEE is supported on a particular implementation. If
it is then various IEEE thingies are available. I'm not sure if
overflow detection is included. Of course IEEE only applies to
floating
point.

http://en.wikipedia.org/wiki/IEEE_754-2008 I think this shows that
overflow is covered.
My appraisal of the situation in fortran was a simplification. The
consensus seems to be that having the feature optional was the best
way to go, that is, it made standard what it could without forcing
vendors to be non-compliant in an arbitrary manner. It doesn't take
long for such discussions to get into hardware and vendor questions
that are really tricky.

As noted above, C *may*, but doesn't have to, support IEEE.
C allows for other types of floating point presumably old ones
or simple ones of embedded systems.

I googled further for "754 IEEE C" and couldn't find an example of how
this is implemented in a standard way for C. I'd like to do a
comparison with the situation in fortran. They too have many
questions unsettled like what a quiet signal is.

 

[Keith Thompson]

On Sep 5, 7:29 am, Nick Keighley <[email protected]>
wrote: [...]

As noted above, C *may*, but doesn't have to, support IEEE.
C allows for other types of floating point presumably old ones
or simple ones of embedded systems.

I googled further for "754 IEEE C" and couldn't find an example of how
this is implemented in a standard way for C. I'd like to do a
comparison with the situation in fortran. They too have many
questions unsettled like what a quiet signal is.

See the C99 standard; the latest draft is available at
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>. Annex F
covers support for IEC 60559 (formerly IEEE 754) floating-point
arithmetic. As has been mentioned, support is optional.

 

[David R Tribble]

As noted above, C *may*, but doesn't have to, support IEEE.
C allows for other types of floating point presumably old ones
or simple ones of embedded systems.

Yes. IBM/370 floating-point, for example, which preceded the IEEE
format by a couple of decades, and AFAIK is still in use on Z/390
systems.

I wonder how many terabytes of files still exist containing floating-
point
data in IBM format.

-drt

 

[Barry Schwarz]

Yes. IBM/370 floating-point, for example, which preceded the IEEE
format by a couple of decades, and AFAIK is still in use on Z/390
systems.

I wonder how many terabytes of files still exist containing floating-
point
data in IBM format.

Current IBM zArchitecture hardware supports three different floating
point formats:

The original hexadecimal format you describe (which actually
goes back earlier to the S/360).

A binary format which I believe is based on some IEEE
standard.

A new decimal format (which enables values like 0.1 to be
represented exactly).

I don't know if their C compiler has an option to let you select which
format you want to use.

 

[Frank]

See the C99 standard; the latest draft is available at
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>.  Annex F
covers support for IEC 60559 (formerly IEEE 754) floating-point
arithmetic.  As has been mentioned, support is optional.

I thought I'd work up one of the examples in annex f. This is a sad-
looking little program

F:\gfortran\dan>gcc iec1.c -std=c99 -Wall -Wextra -pedantic -o
iec.exe
iec1.c:1: warning: ignoring #pragma STDC FENV_ACCESS
C:\DOCUME~1\dan\LOCALS~1\Temp/ccRQln8l.o:iec1.c.text+0x91):
undefined referenc
e to `__mingw_vprintf'
collect2: ld returned 1 exit status

F:\gfortran\dan>type iec1.c
#pragma STDC FENV_ACCESS ON
#include <stdio.h>
#include <fenv.h>

int main(void)
{
float w[] = { 0.0/0.0 }; // raises an exception
static float x = 0.0/0.0; // does not raise an exception
float y = 0.0/0.0; // raises an exception
double z = 0.0/0.0; // raises an exception

printf("%f %f %f %f\n", w, x, y ,z);
}

// gcc iec1.c -std=c99 -Wall -Wextra -pedantic -o iec.exe

F:\gfortran\dan>

I have any number of questions about the above, but I think I can
cover them with: why does this fail?

The pragma that's being ignored is identical to p. 68 of H&S.

 

[Frank]

Current IBM zArchitecture hardware supports three different floating
point formats:

        The original hexadecimal format you describe (which actually
goes back earlier to the S/360).

        A binary format which I believe is based on some IEEE
standard.

        A new decimal format (which enables values like 0.1 to be
represented exactly).

I don't know if their C compiler has an option to let you select which
format you want to use.

The z10 from ibm implements 754 in full:

http://en.wikipedia.org/wiki/IBM_z10_(microprocessor)

I've never been on a computer with more processing capacity than my
current desktop. I wonder what it is about this hardware that makes
it suitable for this purpose.

 

[Keith Thompson]

See the C99 standard; the latest draft is available at
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf>.  Annex F
covers support for IEC 60559 (formerly IEEE 754) floating-point
arithmetic.  As has been mentioned, support is optional.

I thought I'd work up one of the examples in annex f. This is a sad-
looking little program
[...]
#pragma STDC FENV_ACCESS ON
#include <stdio.h>
#include <fenv.h>

int main(void)
{
float w[] = { 0.0/0.0 }; // raises an exception
static float x = 0.0/0.0; // does not raise an exception
float y = 0.0/0.0; // raises an exception
double z = 0.0/0.0; // raises an exception

printf("%f %f %f %f\n", w, x, y ,z);

(You have a type mismatch; use w[0] rather than w.)

}
[...]

I have any number of questions about the above, but I think I can
cover them with: why does this fail?

Consult gcc's documentation:

* `The default state for the `FENV_ACCESS' pragma (C99 7.6.1).'

This pragma is not implemented, but the default is to "off" unless
`-frounding-math' is used in which case it is "on".

gcc does not fully conform to C99.

 

[Peter Nilsson]

Finally I found the discussion that I started
in comp.std.c.

*Five years* later there isn't any reaction
of the committee,

*Five years* later do you have anything to add but your own
personal bitterness?

Have you fully implemented it in your own compiler? Do you
have profilings on speed performance. Have you solidified
the trap handling mechanisms?

Are there any major clients using it? Do you have letters
of positive feedback? Have you offered to show M$ or GCC
how to implement it? Have you thought about submitting an
article to one of the major tech mags?

Are there other languages that implement it? Has it shown
to be of value?

You complain about the cost of submitting a proposal to
your standards body, but you're really just complaining
that others have the audacity to charge for work as you
do. If you don't have the money, then pursue sponsors
who do.

A word of advice though, don't limit yourself to usenet,
and don't start your letters by bitching about the very
people you're writing to.

 

[jacob navia]

Peter Nilsson a écrit :

*Five years* later do you have anything to add but your own
personal bitterness?

Have you fully implemented it in your own compiler?
Yes

Do you
have profilings on speed performance.
Yes

Have you solidified
the trap handling mechanisms?

I proposed two.

Are there any major clients using it?

Since I distribuite my compiler system for free, there are no
"major clients". My compiler system has been downoaded more
than a million tiumes though.

Do you have letters
of positive feedback?

I did not ask for any.

Have you offered to show M$ or GCC
how to implement it?

Since they aren't interested in implementing C99 I would bet
that implementing C201X is not their main worry...

Have you thought about submitting an
article to one of the major tech mags?

No interest in C.
If you do not believe me just try.

Are there other languages that implement it?

Fortran, as I have read in this forum.

Has it shown
to be of value?

Providing with a mean to catch overflow?

There is no value whatsoever, nobody will earn a penny with that.
Apparently you do not see any value, since you ask this question...
What value can have a language where a + b can yield a wrong result?

You complain about the cost of submitting a proposal to
your standards body, but you're really just complaining
that others have the audacity to charge for work as you
do.

This is incredible. I have been paying money
since at least 13 years for the lcc-win project.

Not counting anything for my work. Just the costs of
distributing, server time, etc.

I give
the software at no cost and you tell me that I "charge for
my work"???

You join the ranks of the "regulars" in comp.lang.c, where
no lie is too big to try to denigrate my project.

> If you don't have the money, then pursue sponsors
who do.

Sure sure.

A word of advice though,

[snip]

Do not need your advice Sir.

What have YOU done?

What did YOU contribute to the community?

 

[Keith Thompson]

Peter Nilsson a écrit : [...]

Are there any major clients using it?

Since I distribuite my compiler system for free, there are no
"major clients". My compiler system has been downoaded more
than a million tiumes though.

See below.

[...]

Since they aren't interested in implementing C99 I would bet
that implementing C201X is not their main worry...

Microsoft may not have shown any interest in implementing C99,
but the gcc developers certainly have (though their progress hasn't
been as quick as I'd like).

[...]

This is incredible. I have been paying money
since at least 13 years for the lcc-win project.

Not counting anything for my work. Just the costs of
distributing, server time, etc.

I give
the software at no cost and you tell me that I "charge for
my work"???

You join the ranks of the "regulars" in comp.lang.c, where
no lie is too big to try to denigrate my project.

According to what appears to be the offical lcc-win32 web page,
<http://www.cs.virginia.edu/~lcc-win32/>:

This software is not freeware, it is copyrighted by Jacob
Navia. It's free for non-commercial use, if you use it
professionally you have to have to buy a licence.

It's great that you've made it free for non-commercial use. There is
nothing wrong with charging for your work. Why would you deny that
you do so? And why would you call someone a liar for saying something
that you've said on your own web page?

[snip]

jacob, you need to understand that we don't *care* enough to denigrate
your project.