Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #6088 > unrolled thread

Re: Read again about my objection about C++ and C

Started byRichard Heathfield <rjh@cpax.org.uk>
First post2015-12-30 18:50 +0000
Last post2015-12-30 20:06 +0000
Articles 10 — 3 participants

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 18:50 +0000
    Re: Read again about my objection about C++ and C Öö Tiib <ootiib@hot.ee> - 2015-12-30 11:28 -0800
      Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 19:48 +0000
      Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 19:51 +0000
      Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 20:07 +0000
    Re: Read again about my objection about C++ and C fir <profesor.fir@gmail.com> - 2015-12-30 11:34 -0800
    Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 19:41 +0000
      Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 19:51 +0000
      Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 20:06 +0000
      Re: Read again about my objection about C++ and C Richard Heathfield <rjh@cpax.org.uk> - 2015-12-30 20:06 +0000

#6088 — Re: Read again about my objection about C++ and C

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 18:50 +0000
SubjectRe: Read again about my objection about C++ and C
Message-ID<n618tb$9as$1@dont-email.me>
On 30/12/15 21:39, Ramine wrote:

[Subject line: Read again about my objection about C++ and C]

Since your knowledge of good C++ programming style is so limited that 
you still use 'using namespace std', can you persuade us that your views 
on C and C++ are worth anything?

<snip>

> So what remains about C and C++ is that in C++ and C you can
> not at runtime catch the exception of signed int or unsigned int
> overflow or underflow ,

In C and C++, it is not possible to overflow or underflow unsigned 
integer types, so there is no way for the exception to be generated. 
Even with signed integer types, there is no requirement on architectures 
to generate an exception for overflow, and C does not mandate that 
implementations carry out software checks, for the excellent reason that 
programmers who design their software in such a way that overflow cannot 
happen should not be penalised by extra checks every time they add two 
numbers together:

int quadratic(int x, int a, int b, int c)
{
   return a * x * x + b * x + c;
}

int foo()
{
   y = quadratic(3, 2, -3, 4);
   z = quadratic(2, 3, -1, 6);
   return y + z;
}

For such code, it would be folly to impose a run-time penalty.

> this is a weakness in C++ and C ,

No, it isn't.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [next] | [standalone]


#6090

FromÖö Tiib <ootiib@hot.ee>
Date2015-12-30 11:28 -0800
Message-ID<3bed0922-bb93-464d-9f44-aa66f28c134d@googlegroups.com>
In reply to#6088
Your own argument is stupid.

It is irrelevant for a user of real-time critical incorrect program
what way it burns down: by giving incorrect answers or by throwing
out run-time errors.

Developer can compile with gcc -ftrapv option if he wants integer
overflow to be detected run-time in C or C++. Developers use it
for testing. However giving defective safety-critical software to user
with such run-time checks is still as bad. It just runs slightly slower
but is still as incorrect.


On Wednesday, 30 December 2015 21:03:14 UTC+2, Ramine  wrote:
> Hello,
> 
> 
> You are making your argument stupid..
> 
> Because we must have a way in the compiler to discipline the
> programmer to not make a mistake, you are saying that in C and C++
> you have to test for your logic yourself to not overflow
> or underflow, that's not good, because in FreePascal
> and Delphi and Ada, if you want the compiler to discipline
> you to not make an error of logic that makes you overflow
> or underflow a signed or unsigned int, you can compile your program
> in FreePascal with -Co compiler option and after that you can locally
> catch the exception of overflow or underflow and reraise an exception
> to detect the faulty function that caused it, or you can globally
> catch the exception, but you can not do that in C++ and C , so
> this is why in my opinion C and C++ are not suitable for
> realtime safety critical systems.
> 
> 
> 
> Thank you,
> Amine Moulay Ramdane.
> 
> 
> 
> On 12/30/2015 10:50 AM, Richard Heathfield wrote:
> > On 30/12/15 21:39, Ramine wrote:
> >
> > [Subject line: Read again about my objection about C++ and C]
> >
> > Since your knowledge of good C++ programming style is so limited that
> > you still use 'using namespace std', can you persuade us that your views
> > on C and C++ are worth anything?
> >
> > <snip>
> >
> >> So what remains about C and C++ is that in C++ and C you can
> >> not at runtime catch the exception of signed int or unsigned int
> >> overflow or underflow ,
> >
> > In C and C++, it is not possible to overflow or underflow unsigned
> > integer types, so there is no way for the exception to be generated.
> > Even with signed integer types, there is no requirement on architectures
> > to generate an exception for overflow, and C does not mandate that
> > implementations carry out software checks, for the excellent reason that
> > programmers who design their software in such a way that overflow cannot
> > happen should not be penalised by extra checks every time they add two
> > numbers together:
> >
> > int quadratic(int x, int a, int b, int c)
> > {
> >    return a * x * x + b * x + c;
> > }
> >
> > int foo()
> > {
> >    y = quadratic(3, 2, -3, 4);
> >    z = quadratic(2, 3, -1, 6);
> >    return y + z;
> > }
> >
> > For such code, it would be folly to impose a run-time penalty.
> >
> >> this is a weakness in C++ and C ,
> >
> > No, it isn't.
> >

[toc] | [prev] | [next] | [standalone]


#6095

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 19:48 +0000
Message-ID<n61ca9$mjc$1@dont-email.me>
In reply to#6090
On 30/12/15 22:41, Ramine wrote:
> On 12/30/2015 11:28 AM, Öö Tiib wrote:
>> Your own argument is stupid.
>>
>> It is irrelevant for a user of real-time critical incorrect program
>> what way it burns down: by giving incorrect answers or by throwing
>> out run-time errors.
>>
>> Developer can compile with gcc -ftrapv option if he wants integer
>
>
> Read here, the -ftrapv is not good:

Translation: you once read something that you interpreted as meaning 
that -ftrapv is not good. Well, I once read that Elvis is alive and well 
and flipping burgers in an Alabama diner. So what?

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]


#6101

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 19:51 +0000
Message-ID<n61cfu$mjc$3@dont-email.me>
In reply to#6090
On 30/12/15 22:49, Ramine wrote:
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv, read here:

Feel free to summarise the article in your own words.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]


#6108

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 20:07 +0000
Message-ID<n61dcn$qma$3@dont-email.me>
In reply to#6090
On 30/12/15 22:52, Ramine wrote:
>
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv is not good, read here:

What do you think you're playing at? Enough already!

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]


#6091

Fromfir <profesor.fir@gmail.com>
Date2015-12-30 11:34 -0800
Message-ID<dcb786c1-e942-4be2-a91c-de42ebdef3ec@googlegroups.com>
In reply to#6088
W dniu środa, 30 grudnia 2015 20:03:14 UTC+1 użytkownik Ramine napisał:
> Hello,
> 
> 
> You are making your argument stupid..
> 
> Because we must have a way in the compiler to discipline the
> programmer to not make a mistake, you are saying that in C and C++
> you have to test for your logic yourself to not overflow
> or underflow, that's not good, because in FreePascal
> and Delphi and Ada, if you want the compiler to discipline
> you to not make an error of logic that makes you overflow
> or underflow a signed or unsigned int, you can compile your program
> in FreePascal with -Co compiler option and after that you can locally
> catch the exception of overflow or underflow and reraise an exception
> to detect the faulty function that caused it, or you can globally
> catch the exception, but you can not do that in C++ and C , so
> this is why in my opinion C and C++ are not suitable for
> realtime safety critical systems.
> 
your reasoning is worth a ram..

1) the jump from the lack of integer overflow check in a compiler to reasoning than c and c++ are "not suitable for  realtime safety critical systems" is an idiot reasoning (what with a thousand of other properties - they do not matter?)
2) this integer check has not much to c/c++ you may use a small compiler extension to
turn it on - this depends on compiler,
\i wonder if "pascal" language says pascal compiler must have it becouse it is a pascal
3) not to mention other things
4) really great news ramine, youre enlighting a whole world by this precious knowledge
5) stop spamming the groups uninteligent spammer,

[toc] | [prev] | [next] | [standalone]


#6093

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 19:41 +0000
Message-ID<n61bsv$l1r$1@dont-email.me>
In reply to#6088
On 30/12/15 22:03, Ramine wrote:
> Hello,

Ah! Welcome to comp.programming!

> You are making your argument stupid..

That's an interesting conversational gambit. Let's see how far it gets you.

> Because we must have a way in the compiler to discipline the
> programmer to not make a mistake,

It is not possible, in the general case, for the compiler to prevent the 
programmer from making mistakes, because the compiler doesn't know what 
the programmer is supposed to be doing.

> you are saying that in C and C++
> you have to test for your logic yourself to not overflow
> or underflow,

You have to know about the issue, yes, and you have to take sensible 
precautions when you're up against limits. The pay-off is performance. 
In almost all cases (but not quite all), the precaution is not required, 
so why impose that penalty /all/ the time? Why not trust the programmer 
to put the checks in when they are required?


> that's not good, because in FreePascal
> and Delphi and Ada, if you want the compiler to discipline
> you to not make an error of logic that makes you overflow
> or underflow a signed or unsigned int, you can compile your program
> in FreePascal with -Co compiler option and after that you can locally
> catch the exception of overflow or underflow and reraise an exception
> to detect the faulty function that caused it, or you can globally
> catch the exception,

To summarise your argument:

1) FreePascal and Delphi and Ada allow you to include runtime overflow 
checks.
2) Therefore, not providing runtime overflow checks is bad.

You might want to consider signing up for an Elementary Logic course.

Firstly, as I have already explained, doing such checks automatically 
has a runtime overhead that in almost all cases is not required, so it's 
mostly just a waste of clocks.

Secondly, and you'll laugh when you hear this, by far the most popular C 
and C++ compiler is gcc, which *does* allow you to set up runtime 
arithmetic overflow checking if you want to.

> but you can not do that in C++ and C , so

Well, you can if you want, but normally you don't want because it's 
normally a complete waste of time.

> this is why in my opinion C and C++ are not suitable for
> realtime safety critical systems.

(a) Your opinion doesn't count for much where the facts are concerned - 
C and C++ implementations are perfectly free to provide such checking, 
some implementations /do/ provide such checking, and of course they do 
so /optionally/;
(b) The reason it's optional is that it's very often not a sensible 
option. There's no point in weighing down code with runtime checks that 
are never going to fire.

What /is/ sometimes a good idea is to enable such checks during testing, 
and design some test cases to expose any overflow issues.

<snip>

One other thing - please learn why top-posting is such a stupid, stupid, 
stupid idea. Thank you.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]


#6098

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 19:51 +0000
Message-ID<n61ceo$mjc$2@dont-email.me>
In reply to#6093
On 30/12/15 22:46, Ramine wrote:

<snip>

> Read here, the -ftrapv is not good:

That is your only comment? You made exactly the same comment (and no 
other) in the last article you posted. It was stupid then and it's 
stupid now.

Instead of shooting from the hip, try actually *reading* what people 
write. You might - and I realise this is a long shot - you might 
actually learn something.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]


#6105

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 20:06 +0000
Message-ID<n61dbf$qma$1@dont-email.me>
In reply to#6093
On 30/12/15 22:49, Ramine wrote:
>
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv, read here:

You only have to post it once, you know.

The cited book is by Robert Seacord, whom I recall very clearly. I had 
long discussions with him on Usenet and in email, about the time he was 
writing "The CERT C Coding Standard" (in fact, you will find my name in 
the acknowledgements for that work, although not in the work you cited). 
I did not find the experience a particularly fruitful one, however, 
because - like you - he doesn't really know how to listen. Consequently, 
the CERT C Coding Standard is flawed in several important respects. I 
currently have no reason to doubt that his book on "Secure Coding in C 
and C++" is just as flawed.

In the current case, we see the problem right away:

int x = /* nondeterministic value */

Obviously it doesn't compile, which isn't a great start. But more 
importantly, what on earth does he mean by "nondeterministic value"? 
Does he mean this?

int x;
x = x + 100 - 1000;

If he does mean that, well, overflow is the least of his problems!

And if he doesn't, what /does/ he mean?

If x has a nondeterministic value, we have no business doing any 
arithmetic at all with x until it has been properly initialised!

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]


#6107

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-12-30 20:06 +0000
Message-ID<n61dc4$qma$2@dont-email.me>
In reply to#6093
On 30/12/15 22:51, Ramine wrote:
>
> Hello,
>
> Sorry , here is the right link, the gcc -ftrapv is not good, read here:

Same argument as before.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web