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

Groups > comp.unix.programmer > #1071 > unrolled thread

C Code "sanity checking" tools

Back to article view | Back to comp.unix.programmer

Contents

  C Code "sanity checking" tools Martin Crouch <spamspamspam@spaml.com> - 2011-08-08 12:00 +0100
    Re: C Code "sanity checking" tools Richard Kettlewell <rjk@greenend.org.uk> - 2011-08-08 12:09 +0100
      Re: C Code "sanity checking" tools Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net> - 2011-08-09 08:50 +0200
        Re: C Code "sanity checking" tools Måns Rullgård <mans@mansr.com> - 2011-08-09 10:55 +0100
          Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-09 14:15 +0100
          Re: C Code "sanity checking" tools Nomen Nescio <nobody@dizum.com> - 2011-08-10 01:58 +0200
          Re: C Code "sanity checking" tools Nomen Nescio <nobody@dizum.com> - 2011-08-10 12:29 +0200
        Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-09 14:17 +0100
          Re: C Code "sanity checking" tools Keith Thompson <kst-u@mib.org> - 2011-08-09 09:17 -0700
            Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-09 17:36 +0100
              Re: C Code "sanity checking" tools Keith Thompson <kst-u@mib.org> - 2011-08-09 12:19 -0700
                Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-09 20:36 +0100
                  Re: C Code "sanity checking" tools Michael Press <rubrum@pacbell.net> - 2011-08-09 19:24 -0700
                    Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-10 10:27 +0100
                      Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-10 14:01 +0100
                        Re: C Code "sanity checking" tools "io_x" <a@b.c.invalid> - 2011-08-13 09:42 +0200
                        Re: C Code "sanity checking" tools Keith Thompson <kst-u@mib.org> - 2011-08-13 16:04 -0700
                          Re: C Code "sanity checking" tools Rainer Weikusat <rweikusat@mssgmbh.com> - 2011-08-14 19:46 +0100
    Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-08 23:12 +1200
      Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-08 15:35 +0100
        Re: C Code "sanity checking" tools Martin Crouch <spamspamspam@spaml.com> - 2011-08-08 16:05 +0100
          Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-08 22:57 +0100
            Re: C Code "sanity checking" tools Måns Rullgård <mans@mansr.com> - 2011-08-08 23:32 +0100
        Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-09 08:03 +1200
          Re: C Code "sanity checking" tools Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-08-08 22:51 +0100
            Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-09 10:01 +1200
      Re: C Code "sanity checking" tools jt@toerring.de (Jens Thoms Toerring) - 2011-08-08 22:06 +0000
        Re: C Code "sanity checking" tools Ian Collins <ian-news@hotmail.com> - 2011-08-09 10:18 +1200
          Re: C Code "sanity checking" tools jt@toerring.de (Jens Thoms Toerring) - 2011-08-08 23:25 +0000
    Re: C Code "sanity checking" tools Nobody <nobody@nowhere.com> - 2011-08-08 14:01 +0100
      Re: C Code "sanity checking" tools Måns Rullgård <mans@mansr.com> - 2011-08-08 14:47 +0100
        Re: C Code "sanity checking" tools Martin Crouch <spamspamspam@spaml.com> - 2011-08-08 16:08 +0100
          Re: C Code "sanity checking" tools Marc <marc.glisse@gmail.com> - 2011-08-08 15:39 +0000
        Re: C Code "sanity checking" tools William Ahern <william@wilbur.25thandClement.com> - 2011-08-08 10:20 -0700
        Re: C Code "sanity checking" tools Nobody <nobody@nowhere.com> - 2011-08-09 00:59 +0100
    Re: C Code "sanity checking" tools mathog <dmathog@gmail.com> - 2011-08-08 08:48 -0700

Page 1 of 2  [1] 2  Next page →

#1071 — C Code "sanity checking" tools

Hi,

If I write some code like this:

#include <stdio.h>
int main(void)
{
  char mystring[5];

  printf("String:%s\n",mystring);

  return 0;
}

It compiles okay (no warnings),  but when runs it has undefined results 
because I've not put anything into mystring before attempting to print 
it, so it gets whatever garbage is left in memory.

Are there any "pre-compiler" code analysis tools out there that would 
pick up this sort of problem?  The platform is sparc Solaris 10.

I know I can use dbx with the -check all flag to run it in debug mode, 
but it would be nice to have a tool that can scan the source and flag up 
a warning without having to execute every branch of the code in a debugger.

Any suggestions please?

Thanks.

[toc] | [next] | [standalone]

#1072

Martin Crouch <spamspamspam@spaml.com> writes:
> If I write some code like this:
>
> #include <stdio.h>
> int main(void)
> {
>  char mystring[5];
>
>  printf("String:%s\n",mystring);
>
>  return 0;
> }
>
> It compiles okay (no warnings),  but when runs it has undefined
> results because I've not put anything into mystring before attempting
> to print it, so it gets whatever garbage is left in memory.
>
> Are there any "pre-compiler" code analysis tools out there that would
> pick up this sort of problem?  The platform is sparc Solaris 10.
>
> I know I can use dbx with the -check all flag to run it in debug mode,
> but it would be nice to have a tool that can scan the source and flag
> up a warning without having to execute every branch of the code in a
> debugger.
>
> Any suggestions please?

You're looking for a static analysis tool.  You can find a list at:

  http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis

Some of them are rather expensive.

-- 
http://www.greenend.org.uk/rjk/

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

#1093

> Martin Crouch <spamspamspam@spaml.com> writes:
> > If I write some code like this:
> >
> > #include <stdio.h>
> > int main(void)
> > {
> >  char mystring[5];
> >
> >  printf("String:%s\n",mystring);
> >
> >  return 0;
> > }
> >
> > It compiles okay (no warnings),  but when runs it has undefined
> > results because I've not put anything into mystring before attempting
> > to print it, so it gets whatever garbage is left in memory.
> >
> > Are there any "pre-compiler" code analysis tools out there that would
> > pick up this sort of problem?  The platform is sparc Solaris 10.

Yes, Ada language will help with this sort of issue. C isn't safe, it
expects you to take responsibility for what you write. 

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

#1094

Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
writes:

>> Martin Crouch <spamspamspam@spaml.com> writes:
>> > If I write some code like this:
>> >
>> > #include <stdio.h>
>> > int main(void)
>> > {
>> >  char mystring[5];
>> >
>> >  printf("String:%s\n",mystring);
>> >
>> >  return 0;
>> > }
>> >
>> > It compiles okay (no warnings),  but when runs it has undefined
>> > results because I've not put anything into mystring before attempting
>> > to print it, so it gets whatever garbage is left in memory.
>> >
>> > Are there any "pre-compiler" code analysis tools out there that would
>> > pick up this sort of problem?  The platform is sparc Solaris 10.
>
> Yes, Ada language will help with this sort of issue. C isn't safe, it
> expects you to take responsibility for what you write. 

And Ada expects the compiler to take responsibility.  Do you fully trust
those who wrote the compiler and runtime support?

-- 
Måns Rullgård
mans@mansr.com

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

#1095

Måns Rullgård <mans@mansr.com> writes:

> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
> writes:
>
>>> Martin Crouch <spamspamspam@spaml.com> writes:
>>> > If I write some code like this:
>>> >
>>> > #include <stdio.h>
>>> > int main(void)
>>> > {
>>> >  char mystring[5];
>>> >
>>> >  printf("String:%s\n",mystring);
>>> >
>>> >  return 0;
>>> > }
>>> >
>>> > It compiles okay (no warnings),  but when runs it has undefined
>>> > results because I've not put anything into mystring before attempting
>>> > to print it, so it gets whatever garbage is left in memory.
>>> >
>>> > Are there any "pre-compiler" code analysis tools out there that would
>>> > pick up this sort of problem?  The platform is sparc Solaris 10.
>>
>> Yes, Ada language will help with this sort of issue. C isn't safe, it
>> expects you to take responsibility for what you write. 
>
> And Ada expects the compiler to take responsibility.  Do you fully trust
> those who wrote the compiler and runtime support?

No, but I trust them more than I trust myself.  Not because they are
bound to be smarter, but because thousands of people are on the look-out
for bugs in the compiler's run-time checks.  The one piece of code that
checks array bounds is being tested millions of times a day and the
results are being scrutinised by thousands of programmers.  If I could
get that sort of scrutiny of my own code, I'd never use lint or valgrind
again!

-- 
Ben.

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

#1104

Måns Rullgård <mans@mansr.com> wrote:

> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
> writes:
> 
> >> Martin Crouch <spamspamspam@spaml.com> writes:
> >> > If I write some code like this:
> >> >
> >> > #include <stdio.h>
> >> > int main(void)
> >> > {
> >> >  char mystring[5];
> >> >
> >> >  printf("String:%s\n",mystring);
> >> >
> >> >  return 0;
> >> > }
> >> >
> >> > It compiles okay (no warnings),  but when runs it has undefined
> >> > results because I've not put anything into mystring before attempting
> >> > to print it, so it gets whatever garbage is left in memory.
> >> >
> >> > Are there any "pre-compiler" code analysis tools out there that would
> >> > pick up this sort of problem?  The platform is sparc Solaris 10.
> >
> > Yes, Ada language will help with this sort of issue. C isn't safe, it
> > expects you to take responsibility for what you write. 
> 
> And Ada expects the compiler to take responsibility.  Do you fully trust
> those who wrote the compiler and runtime support?

Not fully but certainly more than I trust people who write C compilers and
runtimes. Good Ada implementations save lots of debugging time. In the end
you really don't have to trust anyone but yourself, but if you use Ada you
still get the benefit of a properly designed system that views a project as
a whole instead of many separate parts and spots many common errors for you
before generating a broken or error-prone executable.

In other words just because you have a smart partner who's good at spotting
problems doesn't mean you give up any control. You can choose to listen to
him or not. But if you don't have a smart partner then all you have is
yourself. Extra eyes are usually a good thing.

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

#1107

Måns Rullgård <mans@mansr.com> wrote:

> And Ada expects the compiler to take responsibility.  Do you fully trust
> those who wrote the compiler and runtime support?
> 

No, but I'll take the assistance. Here are two scenarios. The first one is
analagous to the C program posted. Ada flags the error the OP asked about.

-*- mode: compilation; default-directory: "~/" -*-
Compilation started at Tue Aug 09 08:34:14

GNAT 4.3.3
Copyright 1992-2007, Free Software Foundation, Inc.


Compiling: mystring.adb (source file time stamp: 2011-08-09 08:34:14)

     1. with Ada.Text_IO; use Ada.Text_IO;
     2.
     3. procedure Mystring is
     4.    Mystring : String(1 .. 5);
           |
        >>> warning: variable "Mystring" is read but never assigned

     5.    
     6. begin
     7.    Put_Line("String: " & Mystring);
     8. end Mystring;

 8 lines: No errors, 1 warning

Compilation finished at Tue Aug 09 08:34:15

 --
 --

This one shows a common error that would result in a nice segfault or other
nasty failure in C but is flagged at compilation time in Ada and during
runtime by Ada. True this example will be flagged by most C compilers but if
you separate the declaration from the assignment it won't be. Ada will not
let you hurt yourself in this kind of scenario.

-*- mode: compilation; default-directory: "~/" -*-
Compilation started at Tue Aug 09 08:37:37

GNAT 4.3.3
Copyright 1992-2007, Free Software Foundation, Inc.


Compiling: mystring.adb (source file time stamp: 2011-08-09 08:37:37)

     1. with Ada.Text_IO; use Ada.Text_IO;
     2.
     3. procedure Mystring is
     4.    Mystring : String(1 .. 5) := "Hello!";
                                        1       3
        >>> warning: wrong length for array of subtype of "Standard.String" defined at line 4
        >>> warning: "Constraint_Error" will be raised at run time

     5.
     6.
     7. begin
     8.    Put_Line("String: " & Mystring);
     9. end Mystring;

 9 lines: No errors, 2 warnings

Compilation finished at Tue Aug 09 08:37:38

ada@host:~$ ./mystring

raised CONSTRAINT_ERROR : mystring.adb:4 length check failed

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

#1096

Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
writes:
>> Martin Crouch <spamspamspam@spaml.com> writes:
>> > If I write some code like this:
>> >
>> > #include <stdio.h>
>> > int main(void)
>> > {
>> >  char mystring[5];
>> >
>> >  printf("String:%s\n",mystring);
>> >
>> >  return 0;
>> > }
>> >
>> > It compiles okay (no warnings),  but when runs it has undefined
>> > results because I've not put anything into mystring before attempting
>> > to print it, so it gets whatever garbage is left in memory.
>> >
>> > Are there any "pre-compiler" code analysis tools out there that would
>> > pick up this sort of problem?  The platform is sparc Solaris 10.
>
> Yes, Ada language will help with this sort of issue. C isn't safe,

http://www.di.unito.it/~damiani/ariane5rep.html

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

#1098

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
> writes:
[...]
>> Yes, Ada language will help with this sort of issue. C isn't safe,
>
> http://www.di.unito.it/~damiani/ariane5rep.html

Are you suggesting that the use of Ada was somehow responsible for the
Ariane 5 failure?

Of course it's possible to write unsafe code in any language.
I presume that's why Fritz wrote "will help with" rather than
"will solve".

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

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

#1099

Keith Thompson <kst-u@mib.org> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
>> writes:
> [...]
>>> Yes, Ada language will help with this sort of issue. C isn't safe,
>>
>> http://www.di.unito.it/~damiani/ariane5rep.html
>
> Are you suggesting that the use of Ada was somehow responsible for the
> Ariane 5 failure?

To a degree: What was responsible for the Ariane failure was that
the specification stated that the processer of the functional unit
in question was to be halted in case of a malfunction: It was assumed
that 'malfunctions' would only be caused by hardware problems and
that, in this case, the redundant other functional unit could just
take over. But redundant functional units don't help against software
errors because several functional units exposed to same
condition-triggering-a-software-error will obviously all fail
immediately at the same time. In this particular case, a 16bit
temperature counter overflowed. Because Ada was being used, the
runtime checked for this overflow and triggered an exception which -
conforming with the specification - caused the affected CPU to be
halted.

A similar programming error in a C program, in a (AFAIR) functional
unit which was past the point of being used and just kept running
because nobody bothered to stop it after it had stopped to be useful
wouldn't have cause any effect: The temperature count would just have
wrapped around, possibly, a couple of times.

The bottom line is that no amount of compiler catankerousness will
protect reliably against human neglect and/or stupidity and that "if
no errors were made and all goes all", any programming language will
be entirely adequate.

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

#1100

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
>>> writes:
>> [...]
>>>> Yes, Ada language will help with this sort of issue. C isn't safe,
>>>
>>> http://www.di.unito.it/~damiani/ariane5rep.html
>>
>> Are you suggesting that the use of Ada was somehow responsible for the
>> Ariane 5 failure?
>
> To a degree: What was responsible for the Ariane failure was that
> the specification stated that the processer of the functional unit
> in question was to be halted in case of a malfunction: It was assumed
> that 'malfunctions' would only be caused by hardware problems and
> that, in this case, the redundant other functional unit could just
> take over.
[snip]

As I understand it, the root cause of the failure was that
management decided to use software written for the Ariane 4
without modification.  It was written correctly for the Ariane 4;
the kind of out-of-range value that was seen most likely *would*
have indicated a hardware failure.

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

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

#1101

Keith Thompson <kst-u@mib.org> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>>> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
>>>> writes:
>>> [...]
>>>>> Yes, Ada language will help with this sort of issue. C isn't safe,
>>>>
>>>> http://www.di.unito.it/~damiani/ariane5rep.html
>>>
>>> Are you suggesting that the use of Ada was somehow responsible for the
>>> Ariane 5 failure?
>>
>> To a degree: What was responsible for the Ariane failure was that
>> the specification stated that the processer of the functional unit
>> in question was to be halted in case of a malfunction: It was assumed
>> that 'malfunctions' would only be caused by hardware problems and
>> that, in this case, the redundant other functional unit could just
>> take over.
> [snip]
>
> As I understand it, the root cause of the failure was that
> management decided to use software written for the Ariane 4
> without modification. It was written correctly for the Ariane 4;
> the kind of out-of-range value that was seen most likely *would*
> have indicated a hardware failure.

One of the nice properties of software-induced disasters is that no
one is ever responsible for them, except maybe 'some unknown
programmer wo left the company a decade ago'. You understood
'correctly' that this is the gut of the failure report: It happened to
work on an earlier model. Clearly, by that time, no problem existed!

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

#1105

In article <877h6mpeb2.fsf@sapphire.mobileactivedefense.com>,
 Rainer Weikusat <rweikusat@mssgmbh.com> wrote:

> Keith Thompson <kst-u@mib.org> writes:
> > Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> >> Keith Thompson <kst-u@mib.org> writes:
> >>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> >>>> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
> >>>> writes:
> >>> [...]
> >>>>> Yes, Ada language will help with this sort of issue. C isn't safe,
> >>>>
> >>>> http://www.di.unito.it/~damiani/ariane5rep.html
> >>>
> >>> Are you suggesting that the use of Ada was somehow responsible for the
> >>> Ariane 5 failure?
> >>
> >> To a degree: What was responsible for the Ariane failure was that
> >> the specification stated that the processer of the functional unit
> >> in question was to be halted in case of a malfunction: It was assumed
> >> that 'malfunctions' would only be caused by hardware problems and
> >> that, in this case, the redundant other functional unit could just
> >> take over.
> > [snip]
> >
> > As I understand it, the root cause of the failure was that
> > management decided to use software written for the Ariane 4
> > without modification. It was written correctly for the Ariane 4;
> > the kind of out-of-range value that was seen most likely *would*
> > have indicated a hardware failure.
> 
> One of the nice properties of software-induced disasters is that no
> one is ever responsible for them, except maybe 'some unknown
> programmer wo left the company a decade ago'. You understood
> 'correctly' that this is the gut of the failure report: It happened to
> work on an earlier model. Clearly, by that time, no problem existed!

I get a sense that you did not read the document.
In a previous message you spoke of a "temperature
counter" whereas the overflow was from a horizontal
speed conversion from 64 bit floating point to
16 bit fixed. 

The report documented several points of failure
including the review process. They did mention
an unnamed programmer (who, I am sure, could
be identified) who did not document why the
particular variable was not protected.

-- 
Michael Press

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

#1106

Michael Press <rubrum@pacbell.net> writes:
> In article <877h6mpeb2.fsf@sapphire.mobileactivedefense.com>,
>  Rainer Weikusat <rweikusat@mssgmbh.com> wrote:
>
>> Keith Thompson <kst-u@mib.org> writes:
>> > Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> >> Keith Thompson <kst-u@mib.org> writes:
>> >>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> >>>> Fritz Wuehler <fritz@spamexpire-201108.rodent.frell.theremailer.net>
>> >>>> writes:
>> >>> [...]
>> >>>>> Yes, Ada language will help with this sort of issue. C isn't safe,
>> >>>>
>> >>>> http://www.di.unito.it/~damiani/ariane5rep.html
>> >>>
>> >>> Are you suggesting that the use of Ada was somehow responsible for the
>> >>> Ariane 5 failure?
>> >>
>> >> To a degree: What was responsible for the Ariane failure was that
>> >> the specification stated that the processer of the functional unit
>> >> in question was to be halted in case of a malfunction: It was assumed
>> >> that 'malfunctions' would only be caused by hardware problems and
>> >> that, in this case, the redundant other functional unit could just
>> >> take over.
>> > [snip]
>> >
>> > As I understand it, the root cause of the failure was that
>> > management decided to use software written for the Ariane 4
>> > without modification. It was written correctly for the Ariane 4;
>> > the kind of out-of-range value that was seen most likely *would*
>> > have indicated a hardware failure.
>> 
>> One of the nice properties of software-induced disasters is that no
>> one is ever responsible for them, except maybe 'some unknown
>> programmer wo left the company a decade ago'. You understood
>> 'correctly' that this is the gut of the failure report: It happened to
>> work on an earlier model. Clearly, by that time, no problem existed!
>
> I get a sense that you did not read the document.

The reason why I wrote 'as far as I remember' was that I did read it
in 2004 or so. And - strange as this may seem - human memory isn't
absolutely reliable. But that's a rather tangential point: A 16-bit
variable overflowed. A runtime check for this caused the CPU to be
halted.

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

#1110

Rainer Weikusat <rweikusat@mssgmbh.com> writes:

[...]

>>> >>>> http://www.di.unito.it/~damiani/ariane5rep.html

[...]

> But that's a rather tangential point: A 16-bit
> variable overflowed. A runtime check for this caused the CPU to be
> halted.

Nevertheless, I'd like to clarify my original statement after
rereading (the relevant parts of) the text: Using a particular
programming language does not protect against "cannot happen"-coding
and the Ada-code involved here had needed explicit overflow checks,
combined with a sensible strategy for dealing with overflows, in
exactly the same way as code which had been written in C had also
needed them.

Related: People are really good at getting wrong whatever they
possibly can get wrong and this implies that nothing which isn't
completely automated is 'safe' in the sense that 'human error' has
been eliminated as a source of risks, meaning "but we have solved the
dangling else problem!" and similar statements are red herrings, IOW
'We must do something. This is something ...', if I may quote that.

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

#1139

"Rainer Weikusat" <rweikusat@mssgmbh.com> ha scritto nel messaggio
news:87r54tto76.fsf@sapphire.mobileactivedefense.com...
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
>>>> >>>> http://www.di.unito.it/~damiani/ariane5rep.html
>
> [...]
>
>> But that's a rather tangential point: A 16-bit
>> variable overflowed. A runtime check for this caused the CPU to be
>> halted.
>
> Nevertheless, I'd like to clarify my original statement after
> rereading (the relevant parts of) the text: Using a particular
> programming language does not protect against "cannot happen"-coding

all can happen

> and the Ada-code involved here had needed explicit overflow checks,
> combined with a sensible strategy for dealing with overflows, in
> exactly the same way as code which had been written in C had also
> needed them.
>
> Related: People are really good at getting wrong whatever they
> possibly can get wrong and this implies that nothing which isn't
> completely automated is 'safe' in the sense that 'human error' has
> been eliminated as a source of risks, meaning "but we have solved the
> dangling else problem!" and similar statements are red herrings, IOW
> 'We must do something. This is something ...', if I may quote that.

i, a not professionist of programming, possible one troll, i think
the solution is "difensive programming"
and too a standard way to make the local error not
to propragate out of the controll of the
programmer
so for each function check errors:
if( fare(args)== -1) return error;
and each function have to chach all the possible
and impossible error for return if its state
is in error or ok

the only problem is impossible to cach "all errors"
so defensive programming: many of them :)

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

#1146

Rainer Weikusat <rweikusat@mssgmbh.com> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>
> [...]
>
>>>> >>>> http://www.di.unito.it/~damiani/ariane5rep.html
>
> [...]
>
>> But that's a rather tangential point: A 16-bit
>> variable overflowed. A runtime check for this caused the CPU to be
>> halted.
>
> Nevertheless, I'd like to clarify my original statement after
> rereading (the relevant parts of) the text: Using a particular
> programming language does not protect against "cannot happen"-coding
> and the Ada-code involved here had needed explicit overflow checks,
> combined with a sensible strategy for dealing with overflows, in
> exactly the same way as code which had been written in C had also
> needed them.
[...]

Yes, adding additional explicit overflow checks to the Ariane
4 code might have prevented the Ariane 5 failure.  It would also
have cost additional CPU time, code space, and perhaps other scarce
resources, to implement those checks.  The omission of the checks
was the result of a deliberate decision, based on the fact that
that particular value physically could not exceed a certain range,
and that therefore the expense of checking it was unneeded.

Documenting the reason for omitting that particular check *might*
also have prevented the Ariane 5 failure -- but I get the impression
that the documentation would not have been read even if it had
existed.  (This could easily be a false impression.)

-- 
Keith Thompson (The_Other_Keith) kst-u@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"

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

#1148

Keith Thompson <kst-u@mib.org> writes:
> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>> Rainer Weikusat <rweikusat@mssgmbh.com> writes:
>>
>> [...]
>>
>>>>> >>>> http://www.di.unito.it/~damiani/ariane5rep.html
>>
>> [...]
>>
>>> But that's a rather tangential point: A 16-bit
>>> variable overflowed. A runtime check for this caused the CPU to be
>>> halted.
>>
>> Nevertheless, I'd like to clarify my original statement after
>> rereading (the relevant parts of) the text: Using a particular
>> programming language does not protect against "cannot happen"-coding
>> and the Ada-code involved here had needed explicit overflow checks,
>> combined with a sensible strategy for dealing with overflows, in
>> exactly the same way as code which had been written in C had also
>> needed them.
> [...]
>
> Yes, adding additional explicit overflow checks to the Ariane
> 4 code might have prevented the Ariane 5 failure.  It would also
> have cost additional CPU time, code space, and perhaps other scarce
> resources, to implement those checks.  The omission of the checks
> was the result of a deliberate decision,

Indeed. The deliberate descision was - how new and uncommon - to
ignore the problem of possibly 'invalid' external inputs because the
Ada runtime already provided what the specification mandated, namely,
halt the CPU in case of any error. Given that rockets of this type
aren't exactly manufactured in great quantities, are you sure that
this hypothetic additional per-rocket cost was anywhere near the
amount of money needed to build and start this really expensive
firecracker? Especially considering that the work had to be done
anyway, after the 'el cheapo'-approache proved to be unworkable in a
fairly spectacular way?

And how's that related to the "C isn't safe while Ada ..." assertion I
was addressing?

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

#1073

On 08/ 8/11 11:00 PM, Martin Crouch wrote:
> Hi,
>
> If I write some code like this:
>
> #include<stdio.h>
> int main(void)
> {
>    char mystring[5];
>
>    printf("String:%s\n",mystring);
>
>    return 0;
> }
>
> It compiles okay (no warnings),  but when runs it has undefined results
> because I've not put anything into mystring before attempting to print
> it, so it gets whatever garbage is left in memory.
>
> Are there any "pre-compiler" code analysis tools out there that would
> pick up this sort of problem?  The platform is sparc Solaris 10.

Unit tests (written first).

-- 
Ian Collins

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

#1076

Ian Collins <ian-news@hotmail.com> writes:

> On 08/ 8/11 11:00 PM, Martin Crouch wrote:

>> If I write some code like this:
>>
>> #include<stdio.h>
>> int main(void)
>> {
>>    char mystring[5];
>>
>>    printf("String:%s\n",mystring);
>>
>>    return 0;
>> }
>>
>> It compiles okay (no warnings),  but when runs it has undefined results
>> because I've not put anything into mystring before attempting to print
>> it, so it gets whatever garbage is left in memory.
>>
>> Are there any "pre-compiler" code analysis tools out there that would
>> pick up this sort of problem?  The platform is sparc Solaris 10.
>
> Unit tests (written first).

I don't think unit tests should be the first line of defence here.  It's
too common to find a forgiving environment where, say, an uninitialised
string happens to be a null string, or where a buffer overrun is silent.

-- 
Ben.

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

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.unix.programmer

csiph-web