Past overflow discussion
jacob navia
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.
Richard Heathfield
> 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.
No, he wasn't. He was much, much more acerbic than I am.
<snip Dan Pop's reaction>
> This is the same reaction as our great current heathfield that
> proposed testing for overflow with a cumbersome "straight C"
> construct.
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.
<snip>
> *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.
Have you actually followed the ISO procedure for proposing a change to
the Standard?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
jacob navia
>
> 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.
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.
--
Dr. Gabriel Dos Reis (g...@cs.tamu.edu), Assistant Professor
http://www.cs.tamu.edu/people/faculty/gdr
Department of Computer Science & Engineering; TAMU
301, Bright Building -- College Station, TX 77843-3112
jacob navia
> jacob navia <ja...@nospam.org> writes:
>
> | 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)
Mark McIntyre
>
> Great answers aren't they?
Yes.
What was your point? To prove that you indeed had a solution in search
of a problem? Perhaps you don't get it.
Mark McIntyre
> 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.
Did you expect people to work for free?
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Frank
> In <4aa169ac$0$12621$ba4ac...@news.orange.fr>, jacob navia wrote:
>
> > 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.
>
> 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.
> > This is the same reaction as our great current heathfield that
> > proposed testing for overflow with a cumbersome "straight C"
> > construct.
>
> 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?
Richard Heathfield
> Richard Heathfield a �crit :
>>
>> Have you actually followed the ISO procedure for proposing a change
>> to the Standard?
>>
<snip>
>
> Another way to propose something is to spend thousands of dollars
> in trips to all committee meetings. I do not have that money.
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. ISO C
committee people are busy people (because they have a day job too),
so they are not going to waste their time with arguments written in
crayon. 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. 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.
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.
> I asked if the committee could establish somewhere a web presence
> but the answer were some ironic remarks, then silence.
Why should they establish a Web presence? 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.
> Actually, committee members do not read this group, I have been
> told.
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.
jacob navia
> In <4aa191bc$0$12614$ba4a...@news.orange.fr>, jacob navia wrote:
>
>> Richard Heathfield a �crit :
>>> Have you actually followed the ISO procedure for proposing a change
>>> to the Standard?
>>>
> <snip>
>> Another way to propose something is to spend thousands of dollars
>> in trips to all committee meetings. I do not have that money.
>
> 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.
>> I asked if the committee could establish somewhere a web presence
>> but the answer were some ironic remarks, then silence.
>
> 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.
>> Actually, committee members do not read this group, I have been
>> told.
>
> 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
yeah i don't get it...
overflow?
not a problem, just go on with wrong results. We are in C. Anything
goes.
Phil Carmody
> jacob navia wrote:
>>
>> Great answers aren't they?
>
> 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
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)
Richard Heathfield
> Richard Heathfield a �crit :
<snip>
>>
>> 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.
Your problem. If you want to solve it, find out 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.
Your problem. If you want to solve it, make time.
>> so they are not going to waste their time with arguments written in
>> crayon.
>
> Let it be
If you mean you now want to drop your proposal, that's fine - so drop
it. If you meant something else, okay, but the readers of this group
are (modulo any committee member subscribers) not the people you need
to persuade.
>> 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.
Right, but then you followed it with an obviously sarcastic remark.
Your problem, not mine.
> Of course if
> he says such things that when quoted they sound like if I was
> attacking him, it is his problem, not mine
But if you are sarcastic to him, it is your problem, not his.
>
> :-)
>
> He is the champion of gets(), that greatly designed function, still
> in the current standard. Why should I attack him? He does that
> himself.
You are *not good* at sarcasm. But in attempting to use it with regard
to Doug Gwyn, you are not making it easy for him or any other
committee member to take you seriously.
>> 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.
The fact that you have treated other bright people that way, however,
does your reputation no good at all.
>>> I asked if the committee could establish somewhere a web presence
>>> but the answer were some ironic remarks, then silence.
>>
>> 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.
Sure, but putting it in those terms is unlikely to win you any
champions on the committee. They don't /have/ to deal with you. If
you want your proposal to be accepted, you /do/ have to deal with
them. So communicating with them is your problem, not theirs. That
may not seem very just, but it's the way things are. If you dislike
that state of affairs enough to try to change it, that's up to you,
but your current approach is not helping anyone, least of all you.
>> 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.
They may consider it so. It seems by the reaction that they do see it
so. But I'm only guessing.
>>> Actually, committee members do not read this group, I have been
>>> told.
>>
>> 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.
The way you are doing it is indeed a complete waste of your time.
> asctime(), gets(), that's standard C. OK.
The Standard isn't perfect but, if you want to change it, moaning
about it is not going to help. You have to get involved in the
process. If you can't or won't, fine, but it means you won't have any
impact on C, and your proposals will fall on deaf ears. Moaning about
it in comp.lang.c is a complete waste of time.
> Who cares?
You obviously don't care enough, or you wouldn't approach the matter
in the way you do.
> I will work in my implementation, and leave standard c to that wise
> committee.
Fine. Your implementation is topical in comp.compilers.lcc.
Richard Heathfield
That's not what Doug Gwyn said. He said that effort would be better
spent on fixing broken code than in penalising correct code.
> We are in C. Anything goes.
Only as an implementation-specific extension. Even then, a diagnostic
message is often required.
Nick Keighley
> On Sep 4, 2:31 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
> > 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 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
I think I continued handling C-related issues after that year.
-- Gaby
Frank
wrote:
> On 5 Sep, 06:00, Frank <merr...@lomas-assault.net> 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.
> > In fortran, you just build around the IEEE
> > modules. Is there a corresponding set of code for C?
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 <nick_keighley_nos...@hotmail.com>
> 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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
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
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.
--
Remove del for email
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
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
> On Sep 5, 8:38 pm, Keith Thompson <ks...@mib.org> wrote:
>
>> 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.
--
Peter
jacob navia
> jacob navia <ja...@nospam.org> wrote:
>> Finally I found the discussion that I started
>> in comp.std.c.
> <snip>
>> *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?
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?
Richard Heathfield
> Peter Nilsson a �crit :
<snip>
>
>> 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"???
"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.
Professional use is:
* Related to business (e.g you use it in a corporation)
* If you sell your software.
If you plan to use lcc-win32 in courses of programming in your
University, contact us for special educational rates."
That looks to me like you charge for your work, except for
non-commercial use. Please do not make the mistake of interpreting
this as an attack. It isn't. Clearly your Web site claims that you
charge for your work. Well, so do other people.
> You join the ranks of the "regulars" in comp.lang.c, where
> no lie is too big to try to denigrate my project.
You are repeating your mistake of interpreting an attempt to help you
move forward as if it were a personal attack. Peter is not lying, and
he's not denigrating your project. You have been asked so often not
to confuse honest disagreement and lying that it is hard to escape
the conclusion that you yourself are lying, in that you know
perfectly well that Peter is telling the truth but you call him a
liar anyway.
<snip>
> What have YOU done?
>
> What did YOU contribute to the community?
One thing he contributed to the community was his good advice on how
to move forward a proposal to get a change made to the C language.
That his advice was spurned is hardly his fault.
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.
[...]
>> 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...
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).
[...]
>> 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.
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.
Francis Glassborow
> No interest in C.
> If you do not believe me just try.
>
Have you ever submitted an article to an ACCU publication (C Vu and
Overload). I think not else I am pretty sure it would have been
published. ACCU continues to have an interest in C but it is hard to
demonstrate that because people seem reluctant to write articles and
reluctant to propose C related presentations for its annual conference.
Frank
> Consult gcc's documentation:
Thx, Keith, I wouldn't have found that in a million years. What is
the newsgroup that deals with gcc-specific stuff?
>
> * `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".
For whatever I tested with, it made no difference in the output
whether that flag was included.
>
> gcc does not fully conform to C99.
What's more, it doesn't support annex f completely, which is, of
course, their prerogative. I've been dinking around with this:
F:\gfortran\dan>gcc iec3.c -Wall -Wextra -o iec.exe
F:\gfortran\dan>iec
-1.#IND00 1.#QNAN0 -1.#IND00 -1.#IND00
1.#INF00 1.#INF00 1.#INF00
1100000000000000100000000000000000000000000000000000000000000000000000000000.000
000
1.#INF00
-0.000000
erfc is 2.000000
tgamma is 1.#INF00
tgamma is 1.#INF00
F:\gfortran\dan>type iec3.c
#include <stdio.h>
#include <fenv.h>
#include <math.h>
int main(void)
{
float f[] = { 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",f[0], x, y ,z);
float u[] = { 1.1e75 }; // raises exceptions
static float v = 1.1e75; // does not raise exceptions
float w = 1.1e75; // raises exceptions
double a = 1.1e75; // may raise exceptions
float b = 1.1e75f; // may raise exceptions
long double c = 1.1e75; // does not raise exceptions
printf("%f %f %f \n%f \n %f \n %Lf\n", u[0],v,w,a,b,c);
float g = erfc(-u[0]);
printf("erfc is %f\n", g);
float h = tgamma(0.0);
printf("tgamma is %f\n", h);
h = tgamma(-3);
printf("tgamma is %f\n", h);
return 0;
}
// gcc iec3.c -Wall -Wextra -o iec.exe
F:\gfortran\dan>
This shows that the static storage class specifier doesn't make a
difference in not raising an exception. I would have expected
differing exceptions for the tgamma's.
However, erfc(-¥) returns 2.
Keith Thompson
> On Sep 6, 7:44 pm, Keith Thompson <ks...@mib.org> wrote:
>
>> Consult gcc's documentation:
>
> Thx, Keith, I wouldn't have found that in a million years. What is
> the newsgroup that deals with gcc-specific stuff?
gnu.gcc.help
I found that particular passage by typing "info gcc" and searching for
FENV_ACCESS.
[...]
Dik T. Winter
...
> Other answers were similar, specially from the representative of
> the committee, Mr Gwyn:
...
> Great answers aren't they?
Yes, they tell you specifically that the useability is limited.
> *Five years* later there isn't any reaction of the committee, and no
> work in this is being done at all.
Well, why should they work on something that they do not think useful?
Anyhow, I also fail to see the advantage, unless the "overflow flag"
is sticky. That is that after:
x = a * b + c;
a check for overflow will reveal whether any of the two operations (or
both) did overflow. Your specifiction is not good enough to tell
what happens if the multiplication overflows but the subsequent
addition not.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Dik T. Winter
> On Sep 4, 2:31=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
...
> > 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.
IEEE doesn't cover it for Fortran either, I think, because IEEE is for
floating-point, and here the issue is integer overflow.
Dik T. Winter
...
> > Are there other languages that implement it?
>
> Fortran, as I have read in this forum.
That was a misunderstanding by Frank. Fortran does not check integer