Hello all.

As you may know, several standards mandate the use of certified or
'proven in use' compilers in safety-critical systems. To date, I've
been using 'proven in use' compilers for those systems. Now, I'm
upgrading to a new 32-bit platform and my olde yet fantastic 16-bit C
compiler cannot cope with it.

I've been looking for 'certified C compilers' (do they even exist ?)
via Google. All I've been able to find are Ada validated and/or
certified compilers / run time systems, and also certifiable RTOSes.

I've also found C compilers which claim to have passed certain test
suites (Metaware, Plum Hall, Perennial, ...)

I don't need an RTOS, just a C compiler with a very limited library
support (no file system, no console, no math; just some byte-copying
stuff and low low level I/O).

My target would be Pentium-based, multiprocessor (yeps) and
monotasking.

What do you use (even with different target architectures)? What would
you recommend?

--
Ignacio G.T.

"Ignacio G.T." wrote:
> 
> As you may know, several standards mandate the use of certified or
> 'proven in use' compilers in safety-critical systems. To date, I've
> been using 'proven in use' compilers for those systems. Now, I'm
> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit
> C compiler cannot cope with it.
> 
> I've been looking for 'certified C compilers' (do they even exist ?)
> via Google. All I've been able to find are Ada validated and/or
> certified compilers / run time systems, and also certifiable RTOSes.

And with good reason.  The C language is inherently unsafe, which
is one of the reasons languages with much higher safety (there is
no absolute guarantee) have been designed.  Ada is one such. 
Pascal is another, with more insecurities than Ada, and less
power, but much simpler.

AFAIK there is no organization which certifies C compilers to
comply with the ISO standards (which does not make the language
safe).  I believe such does exist for Ada.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

CBFalconer wrote:
> "Ignacio G.T." wrote:
>>
>> As you may know, several standards mandate the use of certified or
>> 'proven in use' compilers in safety-critical systems. To date, I've
>> been using 'proven in use' compilers for those systems. Now, I'm
>> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit
>> C compiler cannot cope with it.
>>
>> I've been looking for 'certified C compilers' (do they even exist ?)
>> via Google. All I've been able to find are Ada validated and/or
>> certified compilers / run time systems, and also certifiable RTOSes.
>
> And with good reason.  The C language is inherently unsafe, which
> is one of the reasons languages with much higher safety (there is
> no absolute guarantee) have been designed.  Ada is one such.
> Pascal is another, with more insecurities than Ada, and less
> power, but much simpler.
>
> AFAIK there is no organization which certifies C compilers to
> comply with the ISO standards (which does not make the language
> safe).  I believe such does exist for Ada.

I would contend that there is no such thing as an inherently safe language,
as all languages are really translators of the designers intentions.  No
language can make up for faulty requirements, design or testing.  Ada is
considered to be safer than C because of constructs and type checking
provided by the language.  In "safety-critical" circles the hot language
seems to be SPARK which was designed with safety-critical in mind.  Despite
it short comings, C is becoming more prevalent, not less, in safety-critical
software.

For a somewhat erudite view on safety-critical, there is a mailing list run
out of the University of York, UK (safety-critical@cs.york.ac.uk).   The
issue of languages is a common topic there.
The real issue of any safety-critical design is one of documentation and
testing.  There are some pointers and articales about this on our website.
http://www.validatedsoftware.com/white_papers.html.

In the US, one of the highest levels of safety-critical is the RTCA's
DO-178B Level A, which is used for software in avionics devices that could
result in catastrophic loss of an aircraft.  In this standard, DO-178B
certified software is preferred, but not required, for all tools (compilers,
linkers, test software, etc.).  The use of non-certified compilers is
compensated for by proper testing of all of the object code, and
traceability of the code and all related tests to the original requirements.

-- 
Scott
Validated Software Corp.

On Wed, 17 Dec 2003 08:59:16 -0700, "Not Really Me"
<scott@exoXYZtech.com> wrote:

> would contend that there is no such thing as an inherently safe language,
>as all languages are really translators of the designers intentions.  No
>language can make up for faulty requirements, design or testing.  Ada is
>considered to be safer than C because of constructs and type checking
>provided by the language.  In "safety-critical" circles the hot language
>seems to be SPARK which was designed with safety-critical in mind.  Despite
>it short comings, C is becoming more prevalent, not less, in safety-critical
>software.

For safety-critical systems, the programmer and system designer are
more important than the language. In past years, I wrote a lot of
safety-critical code, almost all in assembler, with no protection at
all from the language.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

"Alan Balmer" <albalmer@att.net> wrote in message
news:am11uv4fivo9a5ehd20vk0li0vdtulfcog@4ax.com...
>
> For safety-critical systems, the programmer and system designer are
> more important than the language. In past years, I wrote a lot of
> safety-critical code, almost all in assembler, with no protection at
> all from the language.
>
> --

Agreed. The professionalism and experience of the people are more important
than the language, tools *or process* in producing any kind of decent
software. The sooner this is rediscovered, the safer we'll all be in our
planes, trains, ships and cars!

--
Peter Bushell
www.software-integrity.com

On Wed, 17 Dec 2003 08:59:16 -0700, "Not Really Me"
<scott@exoXYZtech.com> wrote:
>
>I would contend that there is no such thing as an inherently safe language,
>as all languages are really translators of the designers intentions.  No
>language can make up for faulty requirements, design or testing.  Ada is
>considered to be safer than C because of constructs and type checking
>provided by the language.  In "safety-critical" circles the hot language
>seems to be SPARK which was designed with safety-critical in mind.  Despite
>it short comings, C is becoming more prevalent, not less, in safety-critical
>software.

What happened to the VIPER? A micro designed in the UK
about 15/20? years ago. I remember hearing assurances
that this was ideal for safety critical stuff because it was
"mathematically correct" or similar?

Mike Harding

On Wed, 17 Dec 2003 11:45:41 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

>"Ignacio G.T." wrote:
>> 
>> As you may know, several standards mandate the use of certified or
>> 'proven in use' compilers in safety-critical systems. To date, I've
>> been using 'proven in use' compilers for those systems. Now, I'm
>> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit
>> C compiler cannot cope with it.
>> 
>> I've been looking for 'certified C compilers' (do they even exist ?)
>> via Google. All I've been able to find are Ada validated and/or
>> certified compilers / run time systems, and also certifiable RTOSes.
>
>And with good reason.  The C language is inherently unsafe, which
>is one of the reasons languages with much higher safety (there is
>no absolute guarantee) have been designed.  Ada is one such. 
>Pascal is another, with more insecurities than Ada, and less
>power, but much simpler.
>
>AFAIK there is no organization which certifies C compilers to
>comply with the ISO standards (which does not make the language
>safe).  I believe such does exist for Ada.

From a medical equipment point of view, the tool (being the C Compiler
in this case) has to be demonstrated to be appropriate for use and
that appropriate mitigations are in place in the event of it's
failure. The issue of whether it is "inherently unsafe" and thus
unsuitable to use,  is a developer decision. The FDA guidelines on 3rd
Party tools mandates a risk analysis be performed on the system and
thus this would lead to fault analysis of the components used. The
fault in the compiler, such as producing incorrect code, would have a
mitigation. In any case, anyone developing software for
safety-critical systems would have their own acceptance criteria for
the compiler and not soley rely on a piece of paper saying that it's
ISO C compliant or whatever.

A don't disagree that probably Ada and Pascal are better languages to
program in but their use restricts the choices of microprocessors that
can be used. Pragmatically the device that is to be developed has to
be commercially viable.  Also the experience depth of those software
engineers who know Pascal and Ada are limited.

The approach of using C or any language in a safety-critical
application is to ensure an appropriate degree of testing, commiserate
to the level of criticality, is applied to all levels of testing from
unit, integration and system. For example, for the level of
criticality, if 100% structural coverage in unit testing is desired
then this may mean that the software should be designed for
testability. This in my mind is the more important aspect, rather than
whether the compiler is C or Ada (even if Ada were "certified" safe).

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

Ignacio G.T. wrote:
> Hello all.
> 
> As you may know, several standards mandate the use of certified or
> 'proven in use' compilers in safety-critical systems. To date, I've
> been using 'proven in use' compilers for those systems. Now, I'm
> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit C
> compiler cannot cope with it.
> 
> I've been looking for 'certified C compilers' (do they even exist ?)
> via Google. All I've been able to find are Ada validated and/or
> certified compilers / run time systems, and also certifiable RTOSes.
> 
> I've also found C compilers which claim to have passed certain test
> suites (Metaware, Plum Hall, Perennial, ...)
> 
> I don't need an RTOS, just a C compiler with a very limited library
> support (no file system, no console, no math; just some byte-copying
> stuff and low low level I/O).
> 
> My target would be Pentium-based, multiprocessor (yeps) and
> monotasking.
> 
> What do you use (even with different target architectures)? What would
> you recommend?

You wish to make a safety critical system with C in a
multiprocessor environment yet not with multitasking ?

To start with, even with a certified compiler, how are you
going to verify, to debug the system ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

In article <3fe00b82.90228601@News.CIS.DFN.DE>, Ignacio G.T. <igtorque.r
emove@evomer.yahoo.es> writes
>Hello all.
>
>As you may know, several standards mandate the use of certified or
>'proven in use' compilers in safety-critical systems. To date, I've
>been using 'proven in use' compilers for those systems. Now, I'm
>upgrading to a new 32-bit platform and my olde yet fantastic 16-bit C
>compiler cannot cope with it.

What is the target?

>I've been looking for 'certified C compilers' (do they even exist ?)
No.

>via Google. All I've been able to find are Ada validated and/or
>certified compilers / run time systems, and also certifiable RTOSes.

Ada has a certification system C and C++ compilers don't

>I've also found C compilers which claim to have passed certain test
>suites (Metaware, Plum Hall, Perennial, ...)

That is not ISO C complience though.

>My target would be Pentium-based, multiprocessor (yeps) and
>monotasking.
>What do you use (even with different target architectures)? What would
>you recommend?

Comencu.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <3FE026A8.3CD6A3A@yahoo.com>, CBFalconer
<cbfalconer@yahoo.com> writes
>"Ignacio G.T." wrote:
>> 
>> As you may know, several standards mandate the use of certified or
>> 'proven in use' compilers in safety-critical systems. To date, I've
>> been using 'proven in use' compilers for those systems. Now, I'm
>> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit
>> C compiler cannot cope with it.
>> 
>> I've been looking for 'certified C compilers' (do they even exist ?)
>> via Google. All I've been able to find are Ada validated and/or
>> certified compilers / run time systems, and also certifiable RTOSes.
>
>And with good reason.  The C language is inherently unsafe, which
>is one of the reasons languages with much higher safety (there is
>no absolute guarantee) have been designed.  Ada is one such. 
>Pascal is another, with more insecurities than Ada, and less
>power, but much simpler.


If you read Safer C by Les Hatton you will discover that Ada and Pascal
are in practice no safer than C 

>AFAIK there is no organization which certifies C compilers to
>comply with the ISO standards (which does not make the language
>safe).  I believe such does exist for Ada.

this is correct. At the moment only one C compiler claims to be ISO C
compliant.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ken Lee <postmaster@noname.com> wrote:
> The approach of using C or any language in a safety-critical
> application is to ensure an appropriate degree of testing, commiserate
> to the level of criticality, is applied to all levels of testing from
> unit, integration and system.

Quite a lot of people use C in automotive systems. Somethings can be done
which reduce risk. The first is to use a subset of the language usually
something like the MISRA C standard. There are tools availible from several
companies which check compliance against such standards.

The other thing is to either only use minimal or no optimisation at all so
the mapping of C to machine code is as exact as possible.

Of course this only facilitates the testing that must be done it doesn't
remove the need for it.

-p
-- 
Paul Gotch
CoreSight Tools
Development Systems ARM Limited.

This message is intended for the addressee(s) only and may contain
information that is the property of, and/or subject to a confidentiality
agreement between the intended recipient(s), their organisation and/or the
ARM Group of Companies. If you are not an intended recipient of this
message, you should not read, copy, forward or otherwise distribute or
further disclose the information in it; misuse of the contents of this
message may violate various laws in your state, jurisdiction or
country. If you have received this message in error, please contact
the originator of this message via email and delete all copies of
this message from your computer or network, thank you.
---------------------------------------------------------------------

> > For safety-critical systems, the programmer and system designer are
> > more important than the language. In past years, I wrote a lot of
> > safety-critical code, almost all in assembler, with no protection at
> > all from the language.
> >
> > --
>
> Agreed. The professionalism and experience of the people are more
important
> than the language, tools *or process* in producing any kind of decent
> software. The sooner this is rediscovered, the safer we'll all be in our
> planes, trains, ships and cars!
>

Negative.  This is impractical in the real world except in small projects
like with 3 engineers or less or if you work as a lone consultant.  For
medium to big projects, it is the *process*.

CBFalconer <cbfalconer@yahoo.com> wrote in news:3FE026A8.3CD6A3A@yahoo.com:

> 
> The C language is inherently unsafe, which
> is one of the reasons languages with much higher safety (there is
> no absolute guarantee) have been designed.  Ada is one such. 
> Pascal is another, with more insecurities than Ada, and less
> power, but much simpler.
> 

Could you tell me why is C language inherently unsafe? And why Ada or 
Pascal are considered safer?


P.Krumins

Peteris Krumins wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote in news:3FE026A8.3CD6A3A@yahoo.com:
> 
> 
>>The C language is inherently unsafe, which
>>is one of the reasons languages with much higher safety (there is
>>no absolute guarantee) have been designed.  Ada is one such. 
>>Pascal is another, with more insecurities than Ada, and less
>>power, but much simpler.
>>
> 
> 
> Could you tell me why is C language inherently unsafe? And why Ada or 
> Pascal are considered safer?

  Mostly it is historical: C has always allowed 'enough rope to hang 
yourself', whilst other languages are more strict in type declaration,
paramater checking, and scope control as examples.
  Modern C's CAN (by option), of course, get close to the same, but the 
problem is that they do not REQUIRE it - so the issue becomes
one of programming discipline, and that's not a good place to put
all your safety critical eggs.
  The best recipe is a structured language AND strong programming & Test 
discipline.
  Included in that is the version control practice of mking sure you 
freeze the compiler version you developed/tested with.

-jg

"Not Really Me" <scott@exoXYZtech.com> wrote in message
news:x0%Db.16$_l6.25998@news.uswest.net...
> CBFalconer wrote:
> > "Ignacio G.T." wrote:
> >>
> >> As you may know, several standards mandate the use of certified or
> >> 'proven in use' compilers in safety-critical systems. To date, I've
> >> been using 'proven in use' compilers for those systems. Now, I'm
> >> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit
> >> C compiler cannot cope with it.
> >>
> >> I've been looking for 'certified C compilers' (do they even exist ?)
> >> via Google. All I've been able to find are Ada validated and/or
> >> certified compilers / run time systems, and also certifiable RTOSes.
> >
> > And with good reason.  The C language is inherently unsafe, which
> > is one of the reasons languages with much higher safety (there is
> > no absolute guarantee) have been designed.  Ada is one such.
> > Pascal is another, with more insecurities than Ada, and less
> > power, but much simpler.
> >
> > AFAIK there is no organization which certifies C compilers to
> > comply with the ISO standards (which does not make the language
> > safe).  I believe such does exist for Ada.
>
> I would contend that there is no such thing as an inherently safe language,
> as all languages are really translators of the designers intentions.  No
> language can make up for faulty requirements, design or testing.  Ada is
> considered to be safer than C because of constructs and type checking
> provided by the language.  In "safety-critical" circles the hot language
> seems to be SPARK which was designed with safety-critical in mind.  Despite
> it short comings, C is becoming more prevalent, not less, in safety-critical
> software.

SPARK is a subset of Ada.

"Peter Bushell" <DELETEnewsreplyALL@software-inCAPStegrity.com> wrote in message
news:3fe094f5$1_2@mk-nntp-2.news.uk.tiscali.com...
> "Alan Balmer" <albalmer@att.net> wrote in message
> news:am11uv4fivo9a5ehd20vk0li0vdtulfcog@4ax.com...
> >
> > For safety-critical systems, the programmer and system designer are
> > more important than the language. In past years, I wrote a lot of
> > safety-critical code, almost all in assembler, with no protection at
> > all from the language.
> >
> > --
>
> Agreed. The professionalism and experience of the people are more important
> than the language, tools *or process* in producing any kind of decent
> software. The sooner this is rediscovered, the safer we'll all be in our
> planes, trains, ships and cars!

Yes, BUT...

Various companies have, to varying degree of formality, done apples-to-apples
comparisons, in their respective domains of expertise.  They have learned that,
IN GENERAL, they get more bang for the buck out of high-order languages than
they do out of assembly language, using comparable teams.

Pratt & Whitney accidentally did an internal study, over the course of several
years, on jet engine controllers.  They were using roughly equivalent teams, and
the tasks to be accomplished were about the same.  The commercial side of the
house was using whatever they wanted to use; the military side of the house was
required to use Ada.  They kept metrics from all of the projects.  The metrics
guy crunched the numbers, and discovered that the Ada projects were getting
something like twice the programmer productivity, across the board, and 1/4 the
defect density, across the board, compared with the commercial side of the
house.

The commercial side of Pratt & Whitney now uses Ada for engine controllers.

In other words, yes, professionalism and experience matter, AND SO DO THE TOOLS.
Given equivalent teams, whether equally brilliant or equally absymal, the team
with the better tools will get the better results.

Peteris Krumins wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
> 
> > The C language is inherently unsafe, which
> > is one of the reasons languages with much higher safety (there is
> > no absolute guarantee) have been designed.  Ada is one such.
> > Pascal is another, with more insecurities than Ada, and less
> > power, but much simpler.
> 
> Could you tell me why is C language inherently unsafe? And why Ada
> or Pascal are considered safer?

Basically because of redundancy.  In Pascal you can say you are
dealing with a limited subset of things, and the compiler will
enforce this.  In C you are always dealing with integers, to all
practical purposes.  Ignoring floating point, everything else in C
is made up of integers with no restrictions, or pointers, again
with no real restrictions.

People can write Pascal (and Ada) code in terms of integers, and
avoid all the checks.  But this is pure foolishness.

In C you can fling pointers about with total abandon, and
sometimes make some sense out of the usage.  In Pascal such usage
is closely controlled, and a misused variable is very likely to be
uncovered early, rather than by its effects hours later.

Underneath the languages are very similar.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In article <3FE135EB.1F405B62@yahoo.com>, CBFalconer
<cbfalconer@yahoo.com> writes
>Peteris Krumins wrote:
>> CBFalconer <cbfalconer@yahoo.com> wrote:
>> 
>> > The C language is inherently unsafe, which
>> > is one of the reasons languages with much higher safety (there is
>> > no absolute guarantee) have been designed.  Ada is one such.
>> > Pascal is another, with more insecurities than Ada, and less
>> > power, but much simpler.
>> 
>> Could you tell me why is C language inherently unsafe? And why Ada
>> or Pascal are considered safer?
>
>Basically because of redundancy.  In Pascal you can say you are
>dealing with a limited subset of things, and the compiler will
>enforce this.  In C you are always dealing with integers, to all
>practical purposes.  Ignoring floating point, everything else in C
>is made up of integers with no restrictions, or pointers, again
>with no real restrictions.
>
>People can write Pascal (and Ada) code in terms of integers, and
>avoid all the checks.  But this is pure foolishness.
>
>In C you can fling pointers about with total abandon, and
>sometimes make some sense out of the usage.  In Pascal such usage
>is closely controlled, and a misused variable is very likely to be
>uncovered early, rather than by its effects hours later.
>

This is fine in theory. However good C compilers are VERY good.  I once
had to work in Modular2 because it was a "safe" language but the
compilers were so buggy and inconsistent it made a complete mockery of a
"safe" language.

The other thing is because C is the most popular language on the planet
there are many high quality testing tools for it. Unlike Pascal etc.

People use a subset of C , Ada etc for safety critical. When you come
down to subsets most languages are OK for safety critical.
 

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Wed, 17 Dec 2003 22:27:05 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>
>this is correct. At the moment only one C compiler claims to be ISO C
>compliant.
>

Which one ?
--
Ignacio G.T.

On Wed, 17 Dec 2003 22:11:45 GMT, Rene Tschaggelar <none@none.none>
wrote:

>
>
>Ignacio G.T. wrote:
>> Hello all.
>> 
>> As you may know, several standards mandate the use of certified or
>> 'proven in use' compilers in safety-critical systems. To date, I've
>> been using 'proven in use' compilers for those systems. Now, I'm
>> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit C
>> compiler cannot cope with it.
>> 
>> I've been looking for 'certified C compilers' (do they even exist ?)
>> via Google. All I've been able to find are Ada validated and/or
>> certified compilers / run time systems, and also certifiable RTOSes.
>> 
>> I've also found C compilers which claim to have passed certain test
>> suites (Metaware, Plum Hall, Perennial, ...)
>> 
>> I don't need an RTOS, just a C compiler with a very limited library
>> support (no file system, no console, no math; just some byte-copying
>> stuff and low low level I/O).
>> 
>> My target would be Pentium-based, multiprocessor (yeps) and
>> monotasking.
>> 
>> What do you use (even with different target architectures)? What would
>> you recommend?
>
>You wish to make a safety critical system with C in a
>multiprocessor environment yet not with multitasking ?
>
>To start with, even with a certified compiler, how are you
>going to verify, to debug the system ?

Not trying to advocate the use with or without multitasking, I would
have thought that a single-threaded application was much easier to
debug & verify for the following reasons:

1. Processes are more deterministic & predictable
2. To implement single threaded systems, a better understanding of
system timing is required.
3. Test harnesses are much easier to construct and even run on
non-target environments. Running unit tests on a PC-based enviroment
presents the developer with many advantages over target-based
verification, only if an OS port or clone doesn't need to be
installed.
4. A level of testing is removed as there are no acceptance testing or
mitigation required for the OS.

Of course it's horses for courses, and not all single-threaded
implementations are appropriate.

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

On Wed, 17 Dec 2003 22:11:45 GMT, Rene Tschaggelar <none@none.none>
wrote:

>
>You wish to make a safety critical system with C in a
>multiprocessor environment yet not with multitasking ?
>
>To start with, even with a certified compiler, how are you
>going to verify, to debug the system ?
>

Good point. We have done it with a 16 bit compiler, plus some ASM,
plus remote debugging via monitors. The n processors run the same code
(one task), and communicate with each other via common memory and
dedicated bus signals. The debugging could be done because we had the
source code of the monitor: we had to change it in order to start and
stop the n programs 'simultaneously', etc. It was a funny experience.
And it worked. By the way, the hardware was developed by ourselves.

Of course, we followed a strict process (CEN 50126 / 50128 / 50129)
which included (documents and code) inspections, rigurous C coding
procedures ('safe' subset without dynamic memory usage, very
restricted use of pointers, etc.), unit testing with 100% coverage
(this was hard), incremental integration, strict validation
procedures, etc, etc.

We have all of that. What we don't have right now is a tool-chain to
do the same job, but for 32-bit platforms. We know our 16-bit tools
pretty well (we've been working with them for 15 years, and all their
peculiarities -i.e., bugs- are known and well documented; that's what
I call 'proven in use'). I wish we could get a reliable tool-chain for
32-bit, just to reduce the costs of debugging them: our process will
(hopefully)  detect those bugs, but the fewer the bugs, the fewer the
cost.

--
Ignacio G.T.

On Thu, 18 Dec 2003 01:13:34 GMT, "Bill" <bill@a.b> wrote:

>> > For safety-critical systems, the programmer and system designer are
>> > more important than the language. In past years, I wrote a lot of
>> > safety-critical code, almost all in assembler, with no protection at
>> > all from the language.
>> >
>> > --
>>
>> Agreed. The professionalism and experience of the people are more
>important
>> than the language, tools *or process* in producing any kind of decent
>> software. The sooner this is rediscovered, the safer we'll all be in our
>> planes, trains, ships and cars!
>>
>
>Negative.  This is impractical in the real world except in small projects
>like with 3 engineers or less or if you work as a lone consultant.  For
>medium to big projects, it is the *process*.

Also coming from a medical equipment background, having a software
process is mandatory irrespective of the team size. Certainly in the
US, you can't sell medical equipment that uses a micro and is attached
to a patient, without documentation stating that you are following a
process. Perhaps one can get away with it in a 3rd world country where
morbidity is high, one can mask the defects of the equipment.

I'd imagine that developing safety-critical systems in general, would
require a Quality Process & System related to the degree of risk to
the end user.

In response to the previous poster, "professionalism and experience"
of the developer is a very inconsistent attribute. It relies on the
whims of a personal "process" to ensure a quality product. Possibly
with small groups it can be sustained but with larger teams an
appropriate quality system and software process is really required
--- provided we agree that the name of the game is producing a product
at the right quality & within the schedule scope. I say this as it is
always possible, given boundless resources & time to produce a "high"
quality product. Producing quality products within a limited time
scale is the constraint that electronic equipment manufacturers are
facing.

Often engineers blame the "process" for project over-runs and even
product defects. If this is the case then probably this would suggest
that the wrong quality system & process are being used.

The general rule is that if the software process in use doesn't add
value to producing good software  then you're using the wrong process.
A good process is habitual not confrontational.

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

Jim Granville wrote:
>  Mostly it is historical: C has always allowed 'enough rope to hang 
>yourself', whilst other languages are more strict in type declaration,
>paramater checking, and scope control as examples.
>  Modern C's CAN (by option), of course, get close to the same, but the 
>problem is that they do not REQUIRE it - so the issue becomes
>one of programming discipline, and that's not a good place to put
>all your safety critical eggs.
Indeed.  For safety critical systems it's essential that the subset of
the language you intend to use is clearly specified.  Using a decent
lint tool with strong type checking and the warning level set high can
also significantly improve type checking.

I think that the using a validated compiler can also provide a false
sense of security.  Throw in a few unchecked conversions and you can
easily make an inherently unsafe Ada program.  Plus a validated
compiler will only do what you tell it, rather than what you want it
to do.

>  The best recipe is a structured language AND strong programming & Test 
>discipline.
>  Included in that is the version control practice of mking sure you 
>freeze the compiler version you developed/tested with.
Agreed.

Andy

On 17 Dec 2003 22:55:46 GMT, paul.gotch@at-arm-dot.com wrote:

>Ken Lee <postmaster@noname.com> wrote:
>> The approach of using C or any language in a safety-critical
>> application is to ensure an appropriate degree of testing, commiserate
>> to the level of criticality, is applied to all levels of testing from
>> unit, integration and system.
>
>Quite a lot of people use C in automotive systems. Somethings can be done
>which reduce risk. The first is to use a subset of the language usually
>something like the MISRA C standard. There are tools availible from several
>companies which check compliance against such standards.

Sorry, but MISRA is not to C what SPARK is to Ada.

MISRA is a collection of seemingly-random, often contradictory
guidelines that attempt to steer the programmer away from the darker
corners of the language.  Some of the rules are good, some bad, some
indifferent, some are impossible to break (e.g., Rule 85, "don't call
a function that takes no parameters without an empty set of
parentheses"), and some are impossible to understand (e.g., Rule 29,
"The use of a tag shall agree with its declaration").

The best thing about MISRA is that it gives you permission to break
the rules if you have to.  And you _will_ have to.  For example, rule
3 says "break rule 1".  In almost exactly those words.

Following MISRA will not (in itself) result in better code.  It will
allow you to check off a MISRA box (if your customer has one).  That's
about it.

But tools.  Now _there's_ an idea.  Specifically lint.  Especially
Gimpel's PC-lint or FlexeLint.  Lint early.  Lint often.  Lint is your
friend.  (Now where have I heard that before?  ;-)

Note it is very important to _understand_ the messages lint is giving
you, not just work around or disable them.  You will learn a lot about
C and a lot about your code and how the compiler must translate it.
If you do this, you _will_ get better code.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On Wed, 17 Dec 2003 22:16:58 -0600, "John R. Strohm"
<strohm@airmail.net> wrote:

>> Agreed. The professionalism and experience of the people are more important
>> than the language, tools *or process* in producing any kind of decent
>> software. The sooner this is rediscovered, the safer we'll all be in our
>> planes, trains, ships and cars!
>
>Yes, BUT...
>
>Various companies have, to varying degree of formality, done apples-to-apples
>comparisons, in their respective domains of expertise.  They have learned that,
>IN GENERAL, they get more bang for the buck out of high-order languages than
>they do out of assembly language, using comparable teams.

Of course. That's been known for decades, and was obvious before any
studies were done. In fact, it is the reason high level languages were
invented. However, the topic of discussion here is not productivity,
but safety. The point is that safe software can be written in any
language, and no language can guarantee safe products if the designers
and programmers don't know how to make them safe.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Thu, 18 Dec 2003 01:13:34 GMT, "Bill" <bill@a.b> wrote:

>> > For safety-critical systems, the programmer and system designer are
>> > more important than the language. In past years, I wrote a lot of
>> > safety-critical code, almost all in assembler, with no protection at
>> > all from the language.
>> >
>> > --
>>
>> Agreed. The professionalism and experience of the people are more
>important
>> than the language, tools *or process* in producing any kind of decent
>> software. The sooner this is rediscovered, the safer we'll all be in our
>> planes, trains, ships and cars!
>>
>
>Negative.  This is impractical in the real world

What is? I don't follow.

> except in small projects
>like with 3 engineers or less or if you work as a lone consultant.  For
>medium to big projects, it is the *process*.
>
Process can be important, certainly, but I've never seen a process
which can crank out a failsafe system design without expert input.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On 18 Dec 2003 01:36:04 GMT, Peteris Krumins
<pkruminsREMOVETHIS@inbox.lv> wrote:

>CBFalconer <cbfalconer@yahoo.com> wrote in news:3FE026A8.3CD6A3A@yahoo.com:
>
>> 
>> The C language is inherently unsafe, which
>> is one of the reasons languages with much higher safety (there is
>> no absolute guarantee) have been designed.  Ada is one such. 
>> Pascal is another, with more insecurities than Ada, and less
>> power, but much simpler.
>> 
>
>Could you tell me why is C language inherently unsafe? And why Ada or 
>Pascal are considered safer?
>
Actually, it's the programmers who are unsafe, not the language. C
provides little to protect them against themselves, whereas Ada and
some other languages make it somewhat harder to write unsafe code.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Alan Balmer wrote:

> On Thu, 18 Dec 2003 01:13:34 GMT, "Bill" <bill@a.b> wrote:
>
>
> > except in small projects
> >like with 3 engineers or less or if you work as a lone consultant.  For
> >medium to big projects, it is the *process*.
> >
> Process can be important, certainly, but I've never seen a process
> which can crank out a failsafe system design without expert input.
>
> --
> Al Balmer
> Balmer Consulting
> removebalmerconsultingthis@att.net

While I doubt anyone would deny that a small team of top notch engineers and
programmers could produce a quality product with most any language or tools
(and with minimum process), the reality is that you rarely find this situation,
especially in large companies and on large projects.  What is more common is a
mix of say 10% top notch people, 20% (if you're lucky) near worthless people
and the rest average.  The challenge is to still turn out a quality product.
In this situation, process, language and tool choices make a big difference.
If the top people are running the show (if they're not � forget it!), these
things help them to achieve the goal using these average (and below average)
people in a way that makes the product quality more or less independent of the
individuals on the team.  This is what you must have for safety and mission
critical software.  In my 30 years in this business, I have seen plenty of
examples of this not being done right � and a few where it has been.

Jerry
--
---------------------------------------------------------------------------------

-- Jerry Petrey
-- Senior Principal Systems Engineer - Navigation (GPS/INS), Guidance, &
Control
-- Raytheon Missile Systems             - Member Team Ada & Team Forth
-- NOTE: please remove <NOSPAM> in email address to reply
---------------------------------------------------------------------------------

"Alan Balmer" <albalmer@att.net> wrote in message
news:auh3uvgq5a04rl6rvlc58028ol2kp6etl3@4ax.com...
> > except in small projects
> >like with 3 engineers or less or if you work as a lone consultant.  For
> >medium to big projects, it is the *process*.
> >
> Process can be important, certainly, but I've never seen a process
> which can crank out a failsafe system design without expert input.
>
> --

Thank you for stopping that run, Alan. Nowhere did I say that the process
didn't matter, but the following posts are testament to the fact that people
have become obsessed with it. I've come across many people who can write
acceptable C, several companies with good processes and some companies where
engineers actually get to follow the processes. In spite of all this, the
general quality of design I have seen is *appalling*. Nothing much has
changed in that area, lamentably, in the past 20 years!

--
Peter Bushell
www.software-integrity.com

On Thu, 18 Dec 2003 15:20:30 GMT, iddw@hotmail.com (Dave Hansen)
wrote:

>But tools.  Now _there's_ an idea.  Specifically lint.  Especially
>Gimpel's PC-lint or FlexeLint.  Lint early.  Lint often.  Lint is your
>friend.  (Now where have I heard that before?  ;-)
>
>Note it is very important to _understand_ the messages lint is giving
>you, not just work around or disable them.  You will learn a lot about
>C and a lot about your code and how the compiler must translate it.
>If you do this, you _will_ get better code.

Yes. I like lint. A valuable tool, once set up properly. However,
every user should be required to memorize your second paragraph and
recite it at least four times per day :-)

Some modern compilers do a pretty good job when set for max warnings.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

All else being equal, look at GreenHills.


-- 
#include <standard.disclaimer>
 _
Kevin D Quitt  USA 91387-4454         96.37% of all statistics are made up
  Per the FCA, this address may not be added to any commercial mail list

In article <3fe00b82.90228601@News.CIS.DFN.DE>
           igtorque.remove@evomer.yahoo.es "Ignacio G.T." writes:

> Hello all.
> 
> As you may know, several standards mandate the use of certified or
> 'proven in use' compilers in safety-critical systems. To date, I've
> been using 'proven in use' compilers for those systems. Now, I'm
> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit C
> compiler cannot cope with it.
> 
> I've been looking for 'certified C compilers' (do they even exist ?)
> via Google. All I've been able to find are Ada validated and/or
> certified compilers / run time systems, and also certifiable RTOSes.

I do not know of any certified C compilers for Safety-Critical applications.
 
> I've also found C compilers which claim to have passed certain test
> suites (Metaware, Plum Hall, Perennial, ...)

None of which would provide enough "real evidence" for safety critical
applications.
 
> I don't need an RTOS, just a C compiler with a very limited library
> support (no file system, no console, no math; just some byte-copying
> stuff and low low level I/O).
> 
> My target would be Pentium-based, multiprocessor (yeps) and
> monotasking.
> 
> What do you use (even with different target architectures)? What would
> you recommend?

Looking in IEC 61508 it seems that Assembler is still an acceptable
programming environment for such applications but you will need to
apply quite a lot of checking of the design intention translation
to final code.

IEC61508 and other safety critical systems development environments 
are leaning towards evidence based approaches. It may be that to get
to a basis of being able to use your new C compiler you may need to
do a lot of your own leg-work in building the evidence of the 
integrity of the compiler and follow suitable codes of practice and
reccommended sub-sets.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

In article <3fe094f5$1_2@mk-nntp-2.news.uk.tiscali.com>
           DELETEnewsreplyALL@software-inCAPStegrity.com  writes:

> "Alan Balmer" <albalmer@att.net> wrote in message
> news:am11uv4fivo9a5ehd20vk0li0vdtulfcog@4ax.com...
> >
> > For safety-critical systems, the programmer and system designer are
> > more important than the language. In past years, I wrote a lot of
> > safety-critical code, almost all in assembler, with no protection at
> > all from the language.
> >
> > --
> 
> Agreed. The professionalism and experience of the people are more important
> than the language, tools *or process* in producing any kind of decent
> software. The sooner this is rediscovered, the safer we'll all be in our
> planes, trains, ships and cars!

As long as we are looking at decent development processes, that will
produce sufficient evidence trails for each product, that a notified
body can audit and feel confident enough in the work you have done
then language matters not. It is just easier to produce the evidence
with some languages. Forth and Assembler happen to be reasonably easy
to certify due to visibility of resultant code and the effects of
regular testing of individual modules. It can all fall apart, however,
if the prcess is lax or the developers are un-professional.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

In article <3fe155df.209316468@News.CIS.DFN.DE>
           postmaster@noname.com "Ken Lee" writes:

> In response to the previous poster, "professionalism and experience"
> of the developer is a very inconsistent attribute. 

Professionalism, surely, demands that the engineers employ a development
process that stands the test by producing dependable systems. Whether it
is an individual engineer, or many teams, there should be a decent 
development process in place to manage any project from initial quotation
to de-commissioning at end of system life. For the lone engineer it means 
that his process should be acceptable to his clients.

> .... It relies on the
> whims of a personal "process" to ensure a quality product. Possibly
> with small groups it can be sustained but with larger teams an
> appropriate quality system and software process is really required
> --- provided we agree that the name of the game is producing a product
> at the right quality & within the schedule scope. 

Any development process for high integrity systems should be quite
visibly employed, leave a decent audit trail and prove that the
development has followed the prescribed path (whatever that path may 
be it must be as described in the development process description).

As for large teams;

I favour having more surgical teams. The number of people in one team
should be no more than 7. The team should have regular technical reviews
of each other's designs. Where the project is so large that more than 
one such team is required then the requirements should be factored such
that these teams can then deal with a more specific part of the 
requirements. This naturally requires the development of interfaces 
between the designs of each of the teams. There should also be some way 
of cross-reviewing the work of the teams (team a sits in review of team 
b's work etc).

> I say this as it is
> always possible, given boundless resources & time to produce a "high"
> quality product. Producing quality products within a limited time
> scale is the constraint that electronic equipment manufacturers are
> facing.

Time-scales have to remain reasonable. It is quite hard to tell a client
that their expectations are not realistic but it has to be done. However,
once a date is promised it must be met, barring the client deciding to 
add further requirements (which should be quoted separately including 
the knock on effects for the timescale).
 
> Often engineers blame the "process" for project over-runs and even
> product defects. If this is the case then probably this would suggest
> that the wrong quality system & process are being used.
>
> The general rule is that if the software process in use doesn't add
> value to producing good software  then you're using the wrong process.
> A good process is habitual not confrontational.

When I have seen that some companies QA manual runs to eight or more
volumes I know they are not following any of it. Such is an example
of the wrong process because it is not memorable enough. My own 
document is a mere 35 pages but has always stood me in good stead.
The whole process is simply represented on a single page in a 
flowchart which is also on my web-site.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

Chris Hills <chris@phaedsys.org> wrote in message news:<JIGwRLB5gN4$EAlI@phaedsys.demon.co.uk>...
> In article <3FE026A8.3CD6A3A@yahoo.com>, CBFalconer
> <cbfalconer@yahoo.com> writes
> >"Ignacio G.T." wrote:
> >> 
> >> As you may know, several standards mandate the use of certified or
> >> 'proven in use' compilers in safety-critical systems. To date, I've
> >> been using 'proven in use' compilers for those systems. Now, I'm
> >> upgrading to a new 32-bit platform and my olde yet fantastic 16-bit
> >> C compiler cannot cope with it.
> >> 
> >> I've been looking for 'certified C compilers' (do they even exist ?)
> >> via Google. All I've been able to find are Ada validated and/or
> >> certified compilers / run time systems, and also certifiable RTOSes.
> >
> >And with good reason.  The C language is inherently unsafe, which
> >is one of the reasons languages with much higher safety (there is
> >no absolute guarantee) have been designed.  Ada is one such. 
> >Pascal is another, with more insecurities than Ada, and less
> >power, but much simpler.
> 
> 
> If you read Safer C by Les Hatton you will discover that Ada and Pascal
> are in practice no safer than C 

Well, this article discusses a review, by the UK Ministry of Defense,
of code certified at DO-178B Level A.  Thus it is reasonable to
consider it an apples-vs-apples comparison.  The review found that Ada
code had only 10% of the residual errors of C code, and that SPARK
code had only 1% of the residual errors of C code.

http://www.sparkada.com/downloads/Mar2002Amey.pdf

Mike

On Thu, 18 Dec 2003 18:25:37 +0000 (UTC), peb@amleth.demon.co.uk
("Paul E. Bennett") wrote:

[text deleted]
>
>IEC61508 and other safety critical systems development environments 
>are leaning towards evidence based approaches. It may be that to get
>to a basis of being able to use your new C compiler you may need to
>do a lot of your own leg-work in building the evidence of the 
>integrity of the compiler and follow suitable codes of practice and
>reccommended sub-sets.

It amazes me why validation of the tools isn't done as a matter of
course for safety critical system -- if I read your post correctly.
Mind you it does look good on a FDA 510K submission that the tool used
has this-or-that certification but the legwork (in the medical devices
field) still has to be done.

Certainly for medical devices, the suitability of all tools that are
used in development has to be demonstrated. Certainly for compilers,
these would have to be factored into the risk analysis and appropriate
mitigations implemented. Also with something like compilers or code
generators, in-house acceptance tests & validation tests would have to
be run.

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

"Chris Hills" <chris@phaedsys.org> wrote in message
news:2wx$vaAnLV4$EAAj@phaedsys.demon.co.uk...

> This is fine in theory. However good C compilers are VERY good.  I once
> had to work in Modular2 because it was a "safe" language but the
> compilers were so buggy and inconsistent it made a complete mockery of a
> "safe" language.

I would -love- to be able to use Modula-2 today, but sadly it died the death
of the obscure ( I guess having a non-buggy M2 compiler spoiled me).  Having
to write "safe" code (isn't that the goal for all of us, whether it's for
life-support applications or not?) in C scares me to death.

Given the choice of the language looking out for you or not, I'll take the
language looking out for you.  What else is all this CPU horsepower for?

-MG.

On Thu, 18 Dec 2003 22:25:12 -0700, "Mike" <someone@somewhere.com>
wrote:

>"Chris Hills" <chris@phaedsys.org> wrote in message
>news:2wx$vaAnLV4$EAAj@phaedsys.demon.co.uk...
>
>> This is fine in theory. However good C compilers are VERY good.  I once
>> had to work in Modular2 because it was a "safe" language but the
>> compilers were so buggy and inconsistent it made a complete mockery of a
>> "safe" language.
>
>I would -love- to be able to use Modula-2 today, but sadly it died the death
>of the obscure ( I guess having a non-buggy M2 compiler spoiled me).  Having
>to write "safe" code (isn't that the goal for all of us, whether it's for
>life-support applications or not?) in C scares me to death.
>
>Given the choice of the language looking out for you or not, I'll take the
>language looking out for you.  What else is all this CPU horsepower for?
>
It's not for providing excuses. Telling the boss "it's not my fault,
the compiler should have fixed it" won't wash in my business.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Thu, 18 Dec 2003 22:25:12 -0700, "Mike" <someone@somewhere.com>
wrote:

[...]
>
>I would -love- to be able to use Modula-2 today, but sadly it died the death
>of the obscure ( I guess having a non-buggy M2 compiler spoiled me).  Having

There are a few still out there, e.g.,
http://www.designtools.co.nz/mod51.htm for the 8051.  You can probably
find more if you poke around the Modual-2 webring,
http://www.modulaware.com/m2wr/ though I'm not sure what you'll find
targetting embedded processors...

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

"Mike" <someone@somewhere.com> writes:
> Given the choice of the language looking out for you or not, I'll take the
> language looking out for you.  What else is all this CPU horsepower for?

You must belong to the Microsoft school of applications
development -- if some is good, a /lot/ more is better!  8-)

As with all work of this nature, there are tradeoffs.  It's
nice to have a lot of processing power, but if it's wasted
mostly "looking out for you" and little is left for doing
some real work, then you've missed the target.

In article <3fe153e7.174297546@News.CIS.DFN.DE>, Ignacio G.T. <igtorque.
remove@evomer.yahoo.es> writes
>On Wed, 17 Dec 2003 22:27:05 +0000, Chris Hills <chris@phaedsys.org>
>wrote:
>
>>
>>this is correct. At the moment only one C compiler claims to be ISO C
>>compliant.
>>
>
>Which one ?
AFAIK The Altium/Tasking Tricore compiler
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Alan Balmer <albalmer@att.net> wrote in message news:<h446uv4b18gdkbl99kgcipgrko1vcfb97s@4ax.com>...
> On Thu, 18 Dec 2003 22:25:12 -0700, "Mike" <someone@somewhere.com>
> wrote:
> 
> >"Chris Hills" <chris@phaedsys.org> wrote in message
> >news:2wx$vaAnLV4$EAAj@phaedsys.demon.co.uk...
> >
> >> This is fine in theory. However good C compilers are VERY good.  I once
> >> had to work in Modular2 because it was a "safe" language but the
> >> compilers were so buggy and inconsistent it made a complete mockery of a
> >> "safe" language.
> >
> >I would -love- to be able to use Modula-2 today, but sadly it died the death
> >of the obscure ( I guess having a non-buggy M2 compiler spoiled me).  Having
> >to write "safe" code (isn't that the goal for all of us, whether it's for
> >life-support applications or not?) in C scares me to death.
> >
> >Given the choice of the language looking out for you or not, I'll take the
> >language looking out for you.  What else is all this CPU horsepower for?
> >
> It's not for providing excuses. Telling the boss "it's not my fault,
> the compiler should have fixed it" won't wash in my business.

Who said anything about compilers *fixing* things?  Who said anything
about providing excuses?  Would you argue against using lint for the
same reasons?  In spite of what we all read on usenet, there are no
perfect programmers.  We should welcome any tools we can use to catch
mistakes, even though no tool will catch every mistake.

I tell my boss all the time that C is a garbage language, and that
using it (with imperfect programmers, the only kind they've been able
to hire) costs the company time and money.  Inertia is a powerful
thing, but they're starting to listen, just a bit.

Mike

On 19 Dec 2003 11:03:07 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>> >Given the choice of the language looking out for you or not, I'll take the
>> >language looking out for you.  What else is all this CPU horsepower for?
>> >
>> It's not for providing excuses. Telling the boss "it's not my fault,
>> the compiler should have fixed it" won't wash in my business.
>
>Who said anything about compilers *fixing* things?  Who said anything
>about providing excuses? 

I may be mis-interpreting you, but it seems you are saying that the
tools and the process are more important to safe code than the people
using them. I disagree.

> Would you argue against using lint for the
>same reasons?  In spite of what we all read on usenet, there are no
>perfect programmers.  We should welcome any tools we can use to catch
>mistakes, even though no tool will catch every mistake.
>
>I tell my boss all the time that C is a garbage language, and that
>using it (with imperfect programmers, the only kind they've been able
>to hire) costs the company time and money.  Inertia is a powerful
>thing, but they're starting to listen, just a bit.

It's not the language that's garbage, but your programmers. As it
happens, I have an excellent example in hand - a project which has
several components on Unix, written in C, and one component on
Windows, written with Delphi. For the last couple of weeks, the
project has been beating its head against problems in the Delphi code,
whereas the C code is WAD.

I'm not blaming Delphi. Don't expect your programmers to start
producing good code because you give them a different language.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Alan Balmer wrote:
> 
.... snip ...
> 
> It's not the language that's garbage, but your programmers. As it
> happens, I have an excellent example in hand - a project which has
> several components on Unix, written in C, and one component on
> Windows, written with Delphi. For the last couple of weeks, the
> project has been beating its head against problems in the Delphi code,
> whereas the C code is WAD.
> 
> I'm not blaming Delphi. Don't expect your programmers to start
> producing good code because you give them a different language.

However Delphi is effectively Cified Pascal, with most of the C
insecurities reinserted and most of the C shorthand removed.  It's
main claim to fame IMHO is a relatively clean way of creating
Windows GUI interfaces.  I consider it requires a great deal of
expertise to use both cleanly and accurately, although not as much
as C or C++.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Alan Balmer <albalmer@att.net> wrote in message news:<eum6uv0n6ad6q3u015bems4gqapeib2ooe@4ax.com>...
> On 19 Dec 2003 11:03:07 -0800, snarflemike@yahoo.com (Mike Silva)
> wrote:
> 
> >> >Given the choice of the language looking out for you or not, I'll take the
> >> >language looking out for you.  What else is all this CPU horsepower for?
> >> >
> >> It's not for providing excuses. Telling the boss "it's not my fault,
> >> the compiler should have fixed it" won't wash in my business.
> >
> >Who said anything about compilers *fixing* things?  Who said anything
> >about providing excuses? 
> 
> I may be mis-interpreting you, but it seems you are saying that the
> tools and the process are more important to safe code than the people
> using them. I disagree.

No, I'm simply arguing (along with others here, it appears) that all
the above have an impact.  And I am agreeing that CPU horsepower (in
the form of  better compilers for better languages) should be used to
catch as many problems as possible, as early as possible in the
development cycle, irrespective of any other factor such as process or
programmer ability.
> >
> >I tell my boss all the time that C is a garbage language, and that
> >using it (with imperfect programmers, the only kind they've been able
> >to hire) costs the company time and money.  Inertia is a powerful
> >thing, but they're starting to listen, just a bit.
> 
> It's not the language that's garbage, but your programmers. 

We'll just have to disagree on this one. :)  Our programmers are the
same as all the millions of programmers who have, by their imperfect
human nature, nurtured the lint band-aid on top of the C sore.  C
simply makes too many wrong choices to be a good tool for use by
normal human beings.  That it has been used heroically in many cases
is a tribute to the heroes, not the language.

Mike
(C programmer for 25 years)

Mike Silva wrote:
> Alan Balmer <albalmer@att.net> wrote in message 
> > snarflemike@yahoo.com (Mike Silva) wrote:
> >
.... snip ...
> > >
> > > I tell my boss all the time that C is a garbage language, and
> > > that using it (with imperfect programmers, the only kind they've
> > > been able to hire) costs the company time and money.  Inertia is
> > > a powerfulthing, but they're starting to listen, just a bit.
> >
> > It's not the language that's garbage, but your programmers.
> 
> We'll just have to disagree on this one. :)  Our programmers are the
> same as all the millions of programmers who have, by their imperfect
> human nature, nurtured the lint band-aid on top of the C sore.  C
> simply makes too many wrong choices to be a good tool for use by
> normal human beings.  That it has been used heroically in many cases
> is a tribute to the heroes, not the language.

I suspect one of the important reasons that C has won out over
Pascal as the primary application language is that it simply
complains less.  This allows the sub-standard programmer to write
things, and get error free compiles.  The fact that the result
doesn't work, or isn't portable, is not his fault.  After all, it
compiled, didn't it?

Of course the fact that the most popular so-called Pascal system
did not implement Pascal may also be connected.  This lost the
Pascal portability advantage.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Alan Balmer <albalmer@att.net> wrote in message news:<eum6uv0n6ad6q3u015bems4gqapeib2ooe@4ax.com>...

> 
> I may be mis-interpreting you, but it seems you are saying that the
> tools and the process are more important to safe code than the people
> using them. I disagree.

I think you'll find that Airbus, Boeing etc. disagree with you. 
Which would you rather fly on - an aircraft whose fly-by-wire code was
written by a single genius with no process or tools, or a group of
well-drilled dullards whose every step was automatically checked and
double-checked through a rigorous process.

These are the two ends of the scale, obviously, but I know which plane
I'd prefer to fly on.

Cheers
TW

On 20 Dec 2003 04:53:32 -0800, tedwood@ornette.freeserve.co.uk (Ted
Wood) wrote:

>Alan Balmer <albalmer@att.net> wrote in message news:<eum6uv0n6ad6q3u015bems4gqapeib2ooe@4ax.com>...
>
>> 
>> I may be mis-interpreting you, but it seems you are saying that the
>> tools and the process are more important to safe code than the people
>> using them. I disagree.
>
>I think you'll find that Airbus, Boeing etc. disagree with you. 
>Which would you rather fly on - an aircraft whose fly-by-wire code was
>written by a single genius with no process or tools, or a group of
>well-drilled dullards whose every step was automatically checked and
>double-checked through a rigorous process.
>
>These are the two ends of the scale, obviously, but I know which plane
>I'd prefer to fly on.

Me too. One where the man sitting up front can override the
bloody software if he wants to! :)

Mike Harding

On Thu, 18 Dec 2003 07:55:30 +1100, Mike Harding
<mike_harding1@nixspamhotmail.com> wrote:

>On Wed, 17 Dec 2003 08:59:16 -0700, "Not Really Me"
><scott@exoXYZtech.com> wrote:
>
>What happened to the VIPER? A micro designed in the UK
>about 15/20? years ago. I remember hearing assurances
>that this was ideal for safety critical stuff because it was
>"mathematically correct" or similar?
>

IIRC the design (at the time) had to be synchronous so that it could
be proven correct by automatic proof tools and the speed was limited
to a few MHz because of this.  Another problem was that they used a
diamond on sapphire process (for radiation hardness) that was
complicated and had very low yield.

George
==============================================
Send real email to GNEUNER2 at COMCAST dot NET

"George Neuner" <gneuner2@dont.spam.me> wrote in message
news:2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com...
> IIRC the design (at the time) had to be synchronous so that it could
> be proven correct by automatic proof tools and the speed was limited
> to a few MHz because of this.  Another problem was that they used a
> diamond on sapphire process (for radiation hardness) that was
> complicated and had very low yield.

I once had the misfortune to work on a safety critical project where the use
of interrupts was not permitted.
That was done because it was not possible to prove mathematically that code
containing interrupt service routines was correct.
Instead, polling was used. The resulting increase in code complexity to
ensure that asynchronous events were serviced in a timely manner was
frightening.
There is no doubt in my mind that the use of interrupts would have been
safer.
As for using C, it is a simple language that can be and is used safely by
many people.
I would venture to say that if someone can't use C safely, then they
certainly shouldn't be using a more complex language like C++.
As for Pascal, Modula 2, etc., IMHO they are next to useless in that
interesting place where software meets hardware.

Tanya

"tanya" <tanya.anne@bigpond.com> wrote in message
news:bs62ph$giu$1@newshost.mot.com...
> "George Neuner" <gneuner2@dont.spam.me> wrote in message
> news:2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com...
> > IIRC the design (at the time) had to be synchronous so that it could
> > be proven correct by automatic proof tools and the speed was limited
> > to a few MHz because of this.  Another problem was that they used a
> > diamond on sapphire process (for radiation hardness) that was
> > complicated and had very low yield.
>
> I once had the misfortune to work on a safety critical project where the
use
> of interrupts was not permitted.
> That was done because it was not possible to prove mathematically that
code
> containing interrupt service routines was correct.
> Instead, polling was used. The resulting increase in code complexity to
> ensure that asynchronous events were serviced in a timely manner was
> frightening.
> There is no doubt in my mind that the use of interrupts would have been
> safer.
> As for using C, it is a simple language that can be and is used safely by
> many people.
> I would venture to say that if someone can't use C safely, then they
> certainly shouldn't be using a more complex language like C++.
> As for Pascal, Modula 2, etc., IMHO they are next to useless in that
> interesting place where software meets hardware.
>
> Tanya
>
>

What a breath of fresh air! Thank you, Tanya.

--
Peter Bushell
www.software-integrity.com

On Mon, 22 Dec 2003 10:14:48 -0000, "Peter Bushell"
<DELETEnewsreplyALL@software-inCAPStegrity.com> wrote:

>"tanya" <tanya.anne@bigpond.com> wrote in message
>news:bs62ph$giu$1@newshost.mot.com...
>> "George Neuner" <gneuner2@dont.spam.me> wrote in message
>> news:2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com...
>> > IIRC the design (at the time) had to be synchronous so that it could
>> > be proven correct by automatic proof tools and the speed was limited
>> > to a few MHz because of this.  Another problem was that they used a
>> > diamond on sapphire process (for radiation hardness) that was
>> > complicated and had very low yield.
>>
>> I once had the misfortune to work on a safety critical project where the
>use
>> of interrupts was not permitted.
>> That was done because it was not possible to prove mathematically that
>code
>> containing interrupt service routines was correct.
>> Instead, polling was used. The resulting increase in code complexity to
>> ensure that asynchronous events were serviced in a timely manner was
>> frightening.
>> There is no doubt in my mind that the use of interrupts would have been
>> safer.
>> As for using C, it is a simple language that can be and is used safely by
>> many people.
>> I would venture to say that if someone can't use C safely, then they
>> certainly shouldn't be using a more complex language like C++.
>> As for Pascal, Modula 2, etc., IMHO they are next to useless in that
>> interesting place where software meets hardware.
>>
>> Tanya
>>
>>
>
>What a breath of fresh air! Thank you, Tanya.

Me too :)

Mike Harding

"tanya" <tanya.anne@bigpond.com> wrote in message
news:bs62ph$giu$1@newshost.mot.com...

> As for Pascal, Modula 2, etc., IMHO they are next to useless in that
> interesting place where software meets hardware.

Can you explain, possibly enlightened with an example, why Pascal would be
next to useless in that interesting place where software meets hardware?

Meindert

tanya wrote:
> 
.... snip ...
> 
> I once had the misfortune to work on a safety critical project
> where the use of interrupts was not permitted.

That is certifiably insane.  However I can see banning edge
triggered interrupts.
>
.... snip ...
>
> As for using C, it is a simple language that can be and is used
> safely by many people.
> I would venture to say that if someone can't use C safely, then
> they certainly shouldn't be using a more complex language like
> C++. As for Pascal, Modula 2, etc., IMHO they are next to
> useless in that interesting place where software meets hardware.

Far from it.  The file abstraction of ISO Pascal allows almost
anything to be connected (and I have done so, from interrupts to
networks to devices).  Those file drivers are probably not going
to be written in Pascal.  This serves the function of splitting
off system dependencies very nicely, and preserves the safety
aspect of a better structured language.

Cs problems largely arise out of making it a structured assembler,
capable of coping with anything at all.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On Sat, 20 Dec 2003 12:20:08 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

[...]
>
>I suspect one of the important reasons that C has won out over
>Pascal as the primary application language is that it simply
>complains less.  This allows the sub-standard programmer to write
[...]

I don't think so (though that doesn't mean you're wrong ;-)

I did most of my academic programming (from around 1979-1983) in
Pascal.  I had studied other languages (as required by the curriculum)
and liked nothing else as well (though Lisp was fun).

My earliest embedded programming projects were in assembler (various
8- and 16-bit processors), PLM/80, and Jovial (J73B).

*The* number one thing that led me to prefer C for embedded
programming was the explicit bit manipulation operators.  In
particular, I remember a terribly frustrating (non-embedded)
application (written in Pascal) where I needed to mask out bits in
unsigned values.  There were no standard operators or library
functions.  I vaugely remember a horrible collection of case
statements and looping constructs.  It wasn't pretty.

The number two thing was the (mostly illusory) "efficiency" of the
language -- the "fact" that it was really a "high-level assembly
language.

The number one reason I've stuck with it is the ubiquity of C.  The
only processors I can think of that don't have at least two sorta-C
compilers targetting them are 4-bitters.

>
>Of course the fact that the most popular so-called Pascal system
>did not implement Pascal may also be connected.  This lost the
>Pascal portability advantage.

Another problem I had with Pascal was the loss of modularity.  The
entire program resides in a single text file.  That may no longer be
true, but it was back in the early '80s.

I would have liked to have tried Modula-2, but I haven't ever had the
chance.  The only "Modula-2" compiler I had was FST for DOS, and
(IIRC) it wasn't really suitable for embedded use.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Dave Hansen wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
> 
> [...]
> >
> >I suspect one of the important reasons that C has won out over
> >Pascal as the primary application language is that it simply
> >complains less.  This allows the sub-standard programmer to write
> [...]
> 
> I don't think so (though that doesn't mean you're wrong ;-)
> 
.... snip ...
> 
> *The* number one thing that led me to prefer C for embedded
> programming was the explicit bit manipulation operators.  In
> particular, I remember a terribly frustrating (non-embedded)
> application (written in Pascal) where I needed to mask out bits in
> unsigned values.  There were no standard operators or library
> functions.  I vaugely remember a horrible collection of case
> statements and looping constructs.  It wasn't pretty.

In many (but not all) cases those things are best handled with
sets.  In my systems I did define an additional function
mask(integer, integer) : integer; for just that purpose.  Proper
definition of subranges and multiplications could combine bit
fields perfectly well.  The compiler converted most
multiplications by constants into shifts.

....snip ...
> 
> Another problem I had with Pascal was the loss of modularity.  The
> entire program resides in a single text file.  That may no longer be
> true, but it was back in the early '80s.

That no longer applies to extended (ISO10206) Pascal, and was
avoided by non-standardized extensions in most systems back when. 
Mine handled separate compilation by leaving out the main program
block, but not the final period.  Global data was handled by an
include file, since only the outer block did any space assignment
for globals.  Kludgy, but it worked.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On Sat, 20 Dec 2003 12:20:08 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

[...]
>
>I suspect one of the important reasons that C has won out over
>Pascal as the primary application language is that it simply
>complains less.  This allows the sub-standard programmer to write
[...]

That reminded me of a saying I once heard:

  Pascal makes you say "please", while C makes you say "I'm sorry".


-Robert Scott
 Ypsilanti, Michigan
(Reply through this forum, not by direct e-mail to me, as automatic reply address is fake.)

"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...

> As for using C, it is a simple language that can be and is used safely by
> many people.

I think a more interesting question is: given a particular quality of
programming talent and fixed amounts of time and money, how will
software written in C fare against software written in "better" (as
determined by safety-critical industry concensus) languages?  I think
the evidence is overwhelming that it will fare quite badly, meaning it
will cost more and/or take more time and/or and have more residual
errors.

Mike

On 22 Dec 2003 10:20:04 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...
>
>> As for using C, it is a simple language that can be and is used safely by
>> many people.
>
>I think a more interesting question is: given a particular quality of
>programming talent and fixed amounts of time and money, how will
>software written in C fare against software written in "better" (as
>determined by safety-critical industry concensus) languages?  I think
>the evidence is overwhelming that it will fare quite badly, meaning it
>will cost more and/or take more time and/or and have more residual
>errors.
>
Sounds interesting. Can you provide references to such evidence,
obtained under the stated conditions?

I'd also be interested in documentation of the ranking of languages
"as determined by safety-critical industry concensus."

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Mon, 22 Dec 2003 17:39:54 GMT, no-one@dont-mail-me.com (Robert
Scott) wrote:

>On Sat, 20 Dec 2003 12:20:08 GMT, CBFalconer <cbfalconer@yahoo.com>
>wrote:
>
>[...]
>>
>>I suspect one of the important reasons that C has won out over
>>Pascal as the primary application language is that it simply
>>complains less.  This allows the sub-standard programmer to write
>[...]
>
>That reminded me of a saying I once heard:
>
>  Pascal makes you say "please", while C makes you say "I'm sorry".

It's well-known that it's easier to ask forgiveness than permission.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On Mon, 22 Dec 2003 14:07:10 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

>tanya wrote:
>> 
>> As for using C, it is a simple language that can be and is used
>> safely by many people.
>> I would venture to say that if someone can't use C safely, then
>> they certainly shouldn't be using a more complex language like
>> C++. As for Pascal, Modula 2, etc., IMHO they are next to
>> useless in that interesting place where software meets hardware.
>
>Far from it.  The file abstraction of ISO Pascal allows almost
>anything to be connected (and I have done so, from interrupts to
>networks to devices).  Those file drivers are probably not going
>to be written in Pascal.  This serves the function of splitting
>off system dependencies very nicely, and preserves the safety
>aspect of a better structured language.

That's kinda the point ... you can't write the driver in Pascal and
thus have to give up all of the safety the language was intended to
provide.

Modula 2 sucked at bit banging although it did Pascal two better.  It
allowed "open ended" array parameters - the actual array size and
index bounds could be determined at runtime via library functions
which enabled array handling functions to be written generically.  It
also allowed data structures to be accessed as "array of word".
However, the size of a "word" was implementation dependent so this
feature was of limited value.

Modula 3, designed by DEC and having no relation to the Wirth
languages aside from some similarity of syntax, is a modern, strictly
typed, object oriented language designed for both application and
system level programming.  Modula 3 gives the programmer full access,
but in a controlled way.  Modula 3 divides the world into "safe" and
"unsafe" code.  "Safe" code does not allow pointers, can perform only
a defined "meaningful" subset of possible data conversions and is GC'd
by default.  "Unsafe" code must be segregated within a library module,
but can do pretty much anything it wants: access hardware, use
pointers, arbitrarily access memory and data structures, perform
arbitrary data conversions, bypass the GC and do custom memory
management, etc.  There are strict rules governing how data is to be
shared between "safe" and "unsafe" code.

Modula 3 is very similar to Ada without subtyping.


>Cs problems largely arise out of making it a structured assembler,
>capable of coping with anything at all.

Well ... C was intended to be a "portable assembler" for writing
operating systems.  That design goal required that it provide (nearly)
all the power of assembler while abstracting just far enough from the
machine to make programs easily retargetable.

No one was forced to use C for general purpose programming.  That
shift occurred  mostly because it was there, it could do what people
needed and very few good alternatives were available.  

George
==============================================
Send real email to GNEUNER2 at COMCAST dot NET

George Neuner wrote:
> On Mon, 22 Dec 2003 14:07:10 GMT, CBFalconer <cbfalconer@yahoo.com>
> wrote:
> 
> 
>>tanya wrote:
>>
>>>As for using C, it is a simple language that can be and is used
>>>safely by many people.
>>>I would venture to say that if someone can't use C safely, then
>>>they certainly shouldn't be using a more complex language like
>>>C++. As for Pascal, Modula 2, etc., IMHO they are next to
>>>useless in that interesting place where software meets hardware.
>>
>>Far from it.  The file abstraction of ISO Pascal allows almost
>>anything to be connected (and I have done so, from interrupts to
>>networks to devices).  Those file drivers are probably not going
>>to be written in Pascal.  This serves the function of splitting
>>off system dependencies very nicely, and preserves the safety
>>aspect of a better structured language.
> 
> 
> That's kinda the point ... you can't write the driver in Pascal and
> thus have to give up all of the safety the language was intended to
> provide.

No drivers ?
Nik Wirths Pascal was indeed close to useless. Intermediate and
current implementations allow you to write drivers. Why shouldn't
they ?

Rene
-- 
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

I realize this is a little OT but I was wondering if there are
other embedded controller developers that simply create
embedded devices and then hand it over to other companies
to do the sales and marketing for them?

Steve

On Mon, 22 Dec 2003 22:02:21 GMT, Steve Letkeman wrote:

> I realize this is a little OT but I was wondering if there are
> other embedded controller developers that simply create
> embedded devices and then hand it over to other companies
> to do the sales and marketing for them?
> 
> Steve

I did something along those lines. For a number of years, I had a limited
partnership with a larger company who marketed my stuff in exchange for a
share of the profits. One problem was that no one in their orginization
understood the technology. Since my entire market consisted of engineers
and technicians with sharply tuned bullshit filters, the old "a good
salesman can sell anything" credo didn't apply. It turned out that I ended
up writing all the meat of the ad copy - to avoid explaining embarrassing
statements like "several orders of megahertz better than the competition",
went along as technical rep on most important sales calls, and handled all
technical questions and a support. After a while I started wondering what I
was paying the sales force for.

Bob

> I did something along those lines. For a number of years, I had a limited
> partnership with a larger company who marketed my stuff in exchange for a
> share of the profits. One problem was that no one in their orginization
> understood the technology. Since my entire market consisted of engineers
> and technicians with sharply tuned bullshit filters, the old "a good
> salesman can sell anything" credo didn't apply. It turned out that I ended
> up writing all the meat of the ad copy - to avoid explaining embarrassing
> statements like "several orders of megahertz better than the competition",
> went along as technical rep on most important sales calls, and handled all
> technical questions and a support. After a while I started wondering what
I
> was paying the sales force for.
>
> Bob

Do you think it would make a difference if the product(s)
were being marketed to the masses as opposed to
the technical crowd?

oN 22-Dec-03, Steve Letkeman said:

> Do you think it would make a difference if the product(s)
> were being marketed to the masses as opposed to
> the technical crowd?

It might, but you're leaving yourself very vulnerable. You build up a
business and a clientele, but someone else has all the market data,
contact lists, etc.

-- 
Bill
Posted with XanaNews Version 1.15.8.4

> I realize this is a little OT but I was wondering if there are
> other embedded controller developers that simply create
> embedded devices and then hand it over to other companies
> to do the sales and marketing for them?

Yes, this is called being an invention house. Routine practice in some
industries (toys, for instance).

It is possible to write interrupt drivers so the math is the same as polled
code.

w..



tanya wrote:

> "George Neuner" <gneuner2@dont.spam.me> wrote in message
> news:2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com...
> > IIRC the design (at the time) had to be synchronous so that it could
> > be proven correct by automatic proof tools and the speed was limited
> > to a few MHz because of this.  Another problem was that they used a
> > diamond on sapphire process (for radiation hardness) that was
> > complicated and had very low yield.
>
> I once had the misfortune to work on a safety critical project where the use
> of interrupts was not permitted.
> That was done because it was not possible to prove mathematically that code
> containing interrupt service routines was correct.
> Instead, polling was used. The resulting increase in code complexity to
> ensure that asynchronous events were serviced in a timely manner was
> frightening.
> There is no doubt in my mind that the use of interrupts would have been
> safer.
> As for using C, it is a simple language that can be and is used safely by
> many people.
> I would venture to say that if someone can't use C safely, then they
> certainly shouldn't be using a more complex language like C++.
> As for Pascal, Modula 2, etc., IMHO they are next to useless in that
> interesting place where software meets hardware.
>
> Tanya

someone wrote:
> I realize this is a little OT but I was wondering if there are other
> embedded controller developers that simply create embedded devices and
> then hand it over to other companies to do the sales and marketing for
> them?

Lewin A.R.W. Edwards wrote:
> Yes, this is called being an invention house. Routine practice in some
> industries (toys, for instance).

Well it can't have done them any good.  When did you last see a new idea
in the toy industry?

Alan Balmer <albalmer@att.net> wrote in message news:<b5feuv06s2nmpakq0o1b7v0kpd450v3eli@4ax.com>...
> On 22 Dec 2003 10:20:04 -0800, snarflemike@yahoo.com (Mike Silva)
> wrote:
> 
> >"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...
> >
> >> As for using C, it is a simple language that can be and is used safely by
> >> many people.
> >
> >I think a more interesting question is: given a particular quality of
> >programming talent and fixed amounts of time and money, how will
> >software written in C fare against software written in "better" (as
> >determined by safety-critical industry concensus) languages?  I think
> >the evidence is overwhelming that it will fare quite badly, meaning it
> >will cost more and/or take more time and/or and have more residual
> >errors.
> >
> Sounds interesting. Can you provide references to such evidence,
> obtained under the stated conditions?

I think the Ada and SPARK communities can, which is why I've added
comp.lang.ada to this thread.  For example, here's reference to a
100:1 residual error reduction between C and SPARK, and a 10:1
reduction between C and Ada, with all code having been previously
certified to DO178B level A:

http://www.sparkada.com/downloads/Mar2002Amey.pdf

Some more interesting reading (note that MISRA acknowledges that there
are better languages than C for safety-critical work):

http://www.sparkada.com/downloads/misracatsil4reader.pdf

This document has a table of language recommendations (search for
"Language Recommendations (IEC 1508)" ).  C is only recommended for
SIL1, while it is not recommended for SIL3 and SIL4:

https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.doc

Mike

On Mon, 22 Dec 2003 21:49:44 GMT, Rene Tschaggelar <none@none.none>
wrote:

>George Neuner wrote:
>> 
>> That's kinda the point ... you can't write the driver in Pascal and
>> thus have to give up all of the safety the language was intended to
>> provide.
>
>No drivers ?
>Nik Wirths Pascal was indeed close to useless. Intermediate and
>current implementations allow you to write drivers.
>

You missed the point.  

We are talking about whether the syntax and semantics of a particular
language will allow certain functionality to be expressed.  The Pascal
language standard defines type rules and expression semantics which
prohibit certain operations necessary for low level programming and
does not define mechanisms for special use circumventions of those
rules.  Within the context of our discussion, Pascal can't be used to
write a driver.


> Why shouldn't they ?

Dealing with hardware requires the ability to address memory
arbitrarily, to manipulate arbitrary bit sequences as meaningful data
and to efficiently convert data to bits and vice versa.

Pascal doesn't allow unchecked type casting.  Compilers that support
it do so as a non portable extension.

The operational equivalent of casting, called "type overlay", requires
coercion between pointer types and conversion of non pointer types to
pointers.  Pascal's type rules don't allow converting non pointer
types to pointers or mixed types in pointer expressions (except for
"nil").  There is also no standard way to obtain the address of
anything.   Compilers that support these operations do so as non
portable extensions.

Pascal's variant records alone are no help for hardware banging - you
still need the support for type overlay so you can "map" the variant
type onto the hardware buffer.  

Implementations have always provided extensions to allow low level
programming - practically since Pascal was invented - because everyone
realized it was necessary.  But those extensions are *not* Pascal and
should not be treated as if they are part of the language.

Some Pascal derivatives do have syntax and sematics that can directly
express low level functionality - Ada, Modula 3 and Oberon come to
mind - there are probably others I don't know about because Pascal is
a popular base model for new language development.


George
==============================================
Send real email to GNEUNER2 at COMCAST dot NET

> > Yes, this is called being an invention house. Routine practice in some
> > industries (toys, for instance).
> 
> Well it can't have done them any good.  When did you last see a new idea
> in the toy industry?

Tamagotchi and Furby come to mind. The problem is that the marketing
structure through which these new ideas must pass first bites out most
of the innovation, then forces the product to be costed-down until
it's just another blinkenlight with a 3-second speech chip.

The toy industry is full of idiots, quite frankly. Some of them are
idiots merely because they work for a large company and such companies
encourage people to rise to the level of their incompetence. Some of
them are idiots because they are blinkered. Some of them just enjoy
being in a position to reject the creative work of others. Some of
them are just in it for the perks and kickbacks provided by suppliers.

A "nameless toy company, division of a nameless enormous consumer
conglomerate" with which I'm excessively familiar routinely pays
thousands of dollars for exclusive rights to ideas simply so they
won't go to another toy company. These ideas are interred in large
metal filing cabinets and never see the light of day because they
don't fit into a product line.

On Mon, 22 Dec 2003 23:45:20 GMT, Steve Letkeman wrote:

>> I did something along those lines. For a number of years, I had a limited
>> partnership with a larger company who marketed my stuff in exchange for a
>> share of the profits. One problem was that no one in their orginization
>> understood the technology. Since my entire market consisted of engineers
>> and technicians with sharply tuned bullshit filters, the old "a good
>> salesman can sell anything" credo didn't apply. It turned out that I ended
>> up writing all the meat of the ad copy - to avoid explaining embarrassing
>> statements like "several orders of megahertz better than the competition",
>> went along as technical rep on most important sales calls, and handled all
>> technical questions and a support. After a while I started wondering what
> I
>> was paying the sales force for.
>>
>> Bob
> 
> Do you think it would make a difference if the product(s)
> were being marketed to the masses as opposed to
> the technical crowd?

I've thought about that quite a bit and yes, I think a generic marketing
approach is better suited to a consumer product than an industrial or
technical one. I would recommend some sort of arrangement based on
performance, like percentage of sales, rather than a fee, and only give
exclusive marketing rights if they will guarantee a minimum number of sales
per year. Needless to say, this will weed out all but the true believers in
your product line. If you can't find an outfit willing to give you a
guarantee, which you probably can't, give them non-exclusive rights to
market your products, and incentivise(sp?) them buy discounting their cost,
and not undercutting them through your own or other sales channels.

Bob

On 22 Dec 2003 21:06:08 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>Alan Balmer <albalmer@att.net> wrote in message news:<b5feuv06s2nmpakq0o1b7v0kpd450v3eli@4ax.com>...
>> On 22 Dec 2003 10:20:04 -0800, snarflemike@yahoo.com (Mike Silva)
>> wrote:
>> 
>> >"tanya" <tanya.anne@bigpond.com> wrote in message news:<bs62ph$giu$1@newshost.mot.com>...
>> >
>> >> As for using C, it is a simple language that can be and is used safely by
>> >> many people.
>> >
>> >I think a more interesting question is: given a particular quality of
>> >programming talent and fixed amounts of time and money, how will
>> >software written in C fare against software written in "better" (as
>> >determined by safety-critical industry concensus) languages?  I think
>> >the evidence is overwhelming that it will fare quite badly, meaning it
>> >will cost more and/or take more time and/or and have more residual
>> >errors.
>> >
>> Sounds interesting. Can you provide references to such evidence,
>> obtained under the stated conditions?
>
>I think the Ada and SPARK communities can, which is why I've added
>comp.lang.ada to this thread.  For example, here's reference to a
>100:1 residual error reduction between C and SPARK, and a 10:1
>reduction between C and Ada, with all code having been previously
>certified to DO178B level A:
>
>http://www.sparkada.com/downloads/Mar2002Amey.pdf

An interesting article, though not for the residual error reduction
references, which are simply quotes of claims made by Lockheed, with
no background. However, the author makes some excellent points,
including one I don't see made often enough - that higher level
languages tend to increase abstraction but decrease predictability.
This is countered to a significant extent by using a well-chosen
language subset, like SPARK. In particular, this leads to the
possibility of static analyzers which are, in a sense, the logic
equivalent of lint's syntax checking.

In reference to "those who maintain that choice of programming
language does not matter, and that critical code can be written
correctly in any language", he says "The claim may be true in
principle but clearly is not commonly achieved in practice." Let me
interject that my position is that "critical code can be written
correctly in any language" (actually stronger than I would contend),
but not that "choice of programming language does not matter." I'd
also point out that there is probably more critical code written in
assembler and C than in Ada or SPARK :-)
>
>Some more interesting reading (note that MISRA acknowledges that there
>are better languages than C for safety-critical work):
>
>http://www.sparkada.com/downloads/misracatsil4reader.pdf
>
Sorry, but the MISRA recommendations and guidelines are so poorly done
that I can't accept them as even relevant. This is not just my
opinion, but that of some very well-respected authorities, and has
been discussed here on occasion.

>This document has a table of language recommendations (search for
>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>SIL1, while it is not recommended for SIL3 and SIL4:
>
>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.doc

This is one in a series of lectures. I would have some fun arguing
with the lecturer on some of his points, but he does include the
referenced tables from the IEC publication (which I'm too cheap to buy
:-)

I think I have to concede that, on the average, code quality can be
better with a well-chosen subset of a higher-level language other than
C. However, it's still my opinion that "average" programmers, as
described in these studies, shouldn't be writing safety-critical code.

Unfortunately, the material presented doesn't give me any idea of the
whole development process - I don't know if the code in question was
reviewed, linted, or even designed before coding ;-) It may have more
to do with other parts of the process than with the language. I won't
argue that C and poor process are often found in the same
neighborhood.

Since a large part of my work is maintenance of legacy systems, I'll
readily agree that the error rate I encounter is horrible. I'll also
claim that error rates of programs I've completely reworked are very
low. Further, most of the errors I find would have been prevented by
good practices, sticking to standard C where possible, and paying
attention to compiler warnings. In fairness to my predecessors, some
of this code was written before the standard, which excuses about 3%
of the problems I find.

Anyway, some very interesting reading. Thank you.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

tanya wrote:
> 
> I once had the misfortune to work on a safety critical project where the use
> of interrupts was not permitted.
> That was done because it was not possible to prove mathematically that code
> containing interrupt service routines was correct.

That remains true, but hardly anyone today strives to "prove 
mathematical" correctness. The problem is that Every Instruction 
could potentially be followed by All interrupt code, unless the
interrupts were known to be disabled in a block of code.  What
the instruction set designers Ought to have invented is a subroutine 
call that says turn-off-interrupts-and-call and a corresponding
return-and-restore interrupts, then code checkers would have shot.



> Instead, polling was used. The resulting increase in code complexity to
> ensure that asynchronous events were serviced in a timely manner was
> frightening.

But the results were more deterministic, even if latencies were 
worse. That is still the tradeoff, isn't it?

> There is no doubt in my mind that the use of interrupts would have been
> safer.

Most likely.

> As for using C, it is a simple language that can be and is used safely by
> many people.

No question.

> I would venture to say that if someone can't use C safely, then they
> certainly shouldn't be using a more complex language like C++.
> As for Pascal, Modula 2, etc., IMHO they are next to useless in that
> interesting place where software meets hardware.

BINGO!

Rick
Merrill

Alan Balmer <albalmer@att.net> wrote in message news:<eslguvk1fm9bbjs2hak84p2i2in77gv62d@4ax.com>...
> On 22 Dec 2003 21:06:08 -0800, snarflemike@yahoo.com (Mike Silva)
> wrote:

> >...For example, here's reference to a
> >100:1 residual error reduction between C and SPARK, and a 10:1
> >reduction between C and Ada, with all code having been previously
> >certified to DO178B level A:
> >
> >http://www.sparkada.com/downloads/Mar2002Amey.pdf
> 
> An interesting article, though not for the residual error reduction
> references, which are simply quotes of claims made by Lockheed, with
> no background. 

Just to clarify, the error reduction claims I was referring to were
those cited from a UK MoD study done by Aerosystems International. 
I'd like to be able to find that study, or a fuller summary, on line.

Mike

In article <eslguvk1fm9bbjs2hak84p2i2in77gv62d@4ax.com>, Alan Balmer <albalmer@att.net> writes:

> I think I have to concede that, on the average, code quality can be
> better with a well-chosen subset of a higher-level language other than
> C. However, it's still my opinion that "average" programmers, as
> described in these studies, shouldn't be writing safety-critical code.

Ah, but do you have a way of preventing that ?

(Not just on systems you build, but on those to which you entrust your
own safety.)

> Since a large part of my work is maintenance of legacy systems, I'll
> readily agree that the error rate I encounter is horrible. I'll also
> claim that error rates of programs I've completely reworked are very
> low.

One of the big flaws in replacing a software system outright is to
ignore the fact that requirement capture has been inadequate.

On 23 Dec 2003 14:33:11 -0600, Kilgallen@SpamCop.net (Larry Kilgallen)
wrote:

>> Since a large part of my work is maintenance of legacy systems, I'll
>> readily agree that the error rate I encounter is horrible. I'll also
>> claim that error rates of programs I've completely reworked are very
>> low.
>
>One of the big flaws in replacing a software system outright is to
>ignore the fact that requirement capture has been inadequate.

I'm not quite sure what you mean. In maintenance work, the only reason
to modify a program is because it doesn't, in some respect, meet
requirements, either the original requirements or new requirements
which have evolved. Requirements are rarely static during initial
development, let alone a few years down the road :-)

When I say "completely reworked", I don't mean to imply that I rewrite
programs from scratch. I make them ANSI compliant and warning free,
eliminate unused elements, eliminate globals as far as possible,
eliminate unsafe (often erroneous) practices and code,  restructure
and recode to make the code more maintainable, and  where possible
replace internal functions with standard C functions or functions from
our proven in-house libraries. At that point I can stand to read it,
and the real work begins <g>. After this, usually there is
considerable refactoring and often some replacement of algorithms.
Some testing is done during the process. A code review follows,
corrections are made if needed, and more formal unit testing is done
before turning the product over to QA.

Typically, during this process, I'll identify a dozen or more bugs in
an average thousand-line program. Some of them will be recognized by
our support people - "Gee, it's been doing that every couple of
months, but we couldn't reproduce it" , or more often "It's always
done this, but we have a workaround."

That last, incidentally, is a real problem for us. Our support people
are good, and often come up with workarounds to problems they never
tell us about. They enjoy being heroes to the customer, and can't be
persuaded that they'll never run out of work ;-)

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

In article <ujchuvkp5bmio83vf6t8c0hblkjvrasr60@4ax.com>, Alan Balmer <albalmer@att.net> writes:
> On 23 Dec 2003 14:33:11 -0600, Kilgallen@SpamCop.net (Larry Kilgallen)
> wrote:
> 
>>> Since a large part of my work is maintenance of legacy systems, I'll
>>> readily agree that the error rate I encounter is horrible. I'll also
>>> claim that error rates of programs I've completely reworked are very
>>> low.
>>
>>One of the big flaws in replacing a software system outright is to
>>ignore the fact that requirement capture has been inadequate.
> 
> I'm not quite sure what you mean. In maintenance work, the only reason
> to modify a program is because it doesn't, in some respect, meet
> requirements, either the original requirements or new requirements
> which have evolved. Requirements are rarely static during initial
> development, let alone a few years down the road :-)

For years the program has met some requirements that are "hidden".
Users depended upon certain features but they were never called out
as features in the documentation - they were useful interactions
between different documented features.

A good example is the VMS Mail program, which someone decided to
rewrite from Bliss into C, most likely because they favored C.
Now, ten years later, they are just getting rid of the MAIL/OLD
command that invoked the previous Bliss implementation.  They
had to carry it that long because of all the undocumented features
missing from the Bliss version.

> When I say "completely reworked", I don't mean to imply that I rewrite
> programs from scratch. I make them ANSI compliant and warning free,
> eliminate unused elements, eliminate globals as far as possible,
> eliminate unsafe (often erroneous) practices and code,  restructure
> and recode to make the code more maintainable, and  where possible
> replace internal functions with standard C functions or functions from
> our proven in-house libraries.

Ok, that is different.

Larry Kilgallen
Who subsequently rewrote a Bliss program into Ada, knowing
the lesson of VMS Mail, because the original Bliss design
was incompatible with new requirements.  That rewrite is
just now starting to hit the streets.  Wish it luck :-)

Simon Hosie:
> Well it can't have done them any good.  When did you last see a new
> idea in the toy industry?

Lewin A.R.W. Edwards wrote:
> Tamagotchi and Furby come to mind.

What's that, then?  About a five-year period?

Now that trading cards have gone digital, well that opens up a whole new
line of non-innovation.


> The problem is that the marketing structure through which these new
> ideas must pass first bites out most of the innovation, then forces
> the product to be costed-down until it's just another blinkenlight
> with a 3-second speech chip.
> [...]

So... what you're saying is that money is paid to develop a new product,
and then more money is paid to reduce that product to being essentially
the same as all the existing products?

That's certainly a familiar story.

Simon Hosie wrote:

> Simon Hosie:
>> Well it can't have done them any good.  When did you last see a new
>> idea in the toy industry?
> 
> Lewin A.R.W. Edwards wrote:
>> Tamagotchi and Furby come to mind.
> 
> What's that, then?  About a five-year period?
> 
> Now that trading cards have gone digital, well that opens up a whole new
> line of non-innovation.
> 
> 
>> The problem is that the marketing structure through which these new
>> ideas must pass first bites out most of the innovation, then forces
>> the product to be costed-down until it's just another blinkenlight
>> with a 3-second speech chip.
>> [...]
> 
> So... what you're saying is that money is paid to develop a new product,
> and then more money is paid to reduce that product to being essentially
> the same as all the existing products?
> 

In the toy industry the norm is for the inventor to develop the toy to the
stage where it is presentable to the toy companies and as often as not the
inventor then pays to cost reduce it.

Ian

In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
<snarflemike@yahoo.com> writes
>
>Some more interesting reading (note that MISRA acknowledges that there
>are better languages than C for safety-critical work):

That will change. 

>http://www.sparkada.com/downloads/misracatsil4reader.pdf

Praxis has a vested interest in not letting C be used for SIL 4

BTW 
slide 3 is erroneous.
slide 5 is also erroneous.

AFAIK Praxis are not "involved" with MISRA-C they may have been some
years ago in the original version but much work has been done since
then. AFAIK they have not taken much, if any part, in this.

AFAIK they did not make their SPADE C results available to the MISRA-C
working group who for the last 3 years have been working on MISRA-C2.

Praxis don't have a unique view of MISRA-C.  They are one of many who
were involved in MISRA-C1. They are not one of the main companies who
were promoting and working with it in the last 5 years.

Slide 6 is interesting. The quotes are out of context and misleading.
The Praxis presentation is clearly written with a (commercial) axe to
grind. I was at the MISRA-C 2002 forum. In fact I did one of the
presentations that has been misquoted.... 

As it goes on they rubbish C and surprise surprise come up with a
solution that is their tools.... :-) 

The Ada (tools) community must be rattled if it needs to spend time
trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
longer push a MISRA-C tool? 

Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
several major automotive companies, aerospace companies, also  members
of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
available at the end of Q1 2004


>This document has a table of language recommendations (search for
>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>SIL1, while it is not recommended for SIL3 and SIL4:
>
>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.do

Yet  C is used in some of the highest integrity systems around. Other
languages that are recommended hardly exist and certainly not on many
platforms.

Empirical evidence and a glance at 61508 may require a change in the
table D2.... BTW table D2 in the lecturers notes is NOT in 61598.

In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
copy of 61508, all 7 parts. We find a similar table to "D2" above:

            Sil1   Sil2   Sil3 Sil4
Ada          HR    HR      R    R
ADA (subset) HR    HR      HR   HR
C            R     -      NR    NR

as expected  BUT

C (subset, codinng standard and static analysis) 
             HR   HR      HR     HR


So whilst straight ADA *is* better than vanilla C. No one would debate
that!  Spark ADA is no better than C with a subset, coding standard and
using static analysis....  IE much the same constraints as SPARK ADA has
over ADA...

I know of projects using C in Railway, space, aero and medical projects.

PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
for these for many targets. BTW is there ADA for the PIC, AVR and 8015?

I come back to my comment previously that the ADA tools vendors must be
worried if they are spending this much effort trying to rubbish MISRA-C
which is an automotive guide.  Though it has gained widespread use
outside the automotive industry due to those involved with it.


Regards
        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
>several major automotive companies, aerospace companies, also  members
>of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
>available at the end of Q1 2004

Thanks for the good analysis. I'd like to keep up with news about
MISRA-C2. What's a good source?

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
wrote:

[...]
>
>PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
>for these for many targets. BTW is there ADA for the PIC, AVR and 8015?

Nit: it's "Pascal," "Modula-2," and "Ada."

The PIC I doubt. I'm hard-pressed to consider some of the "C"
compilers for PIC to be C.  As an alternative HLL, JAL (Just Another
Language) is kind of interesting.  http://www.voti.nl/jal/

The AVR is supported by GCC, so GNAT might work, though the runtime
support probably isn't there.  I haven't tried it in any case.

The 8015 I've never heard of.  I assume you mean 8051, to which I'd
have to say I haven't heard of one, though there is a Modula-2
compiler.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

In article <k8mjuvshdirlqkl5its6jbqr7hlthfk990@4ax.com>, Alan Balmer
<albalmer@att.net> writes
>On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
>wrote:
>
>>Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
>>several major automotive companies, aerospace companies, also  members
>>of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
>>available at the end of Q1 2004
>
>Thanks for the good analysis. I'd like to keep up with news about
>MISRA-C2. What's a good source?
>

Well come the new year comp.lang.c.misra  assuming I can get the
paperwork sorted.

Otherwise just ask me.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <3fe9f0d7.104475725@News.CIS.DFN.DE>, Dave Hansen
<iddw@hotmail.com> writes
>On Wed, 24 Dec 2003 16:46:19 +0000, Chris Hills <chris@phaedsys.org>
>wrote:
>
>[...]
>>
>>PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
>>for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
>
>Nit: it's "Pascal," "Modula-2," and "Ada."
>
>The PIC I doubt. I'm hard-pressed to consider some of the "C"
>compilers for PIC to be C.
:-) 
I know what you mean.

>The AVR is supported by GCC,
GCC is not usually suitable for 8 and 16 bit embedded systems. IT is a
generic compiler system that is not usually a patch onthe commercial
ones.. 

> so GNAT might work, though the runtime
>support probably isn't there.  I haven't tried it in any case.


>
>The 8015 I've never heard of.  I assume you mean 8051, to which I'd
>have to say I haven't heard of one, 

yes.... though some one will now tell us about the 8015 from 197* that
was around for 2.3 years :-)

>though there is a Modula-2
>compiler.

But is it any good? 

I once had to work on an embedded system using Mod2 a none of the
compilers supported the basic language in the same way.  Let alone
extensions.  It turned out that the most stable compiler was the least
standard :-( 

A theoretically good language is no use at all if the compiler
implementations are no good. 

At least with C there will usually be several commercial compilers and a
multitude of testing and checking tools.  

It's one thing having a compiler but what about the rest. How many ICE
support ADA? 

Regards
        Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Wed, 24 Dec 2003 20:41:41 +0000, Chris Hills <chris@phaedsys.org>
wrote:

>In article <3fe9f0d7.104475725@News.CIS.DFN.DE>, Dave Hansen
><iddw@hotmail.com> writes
[...]
>>The AVR is supported by GCC,
>GCC is not usually suitable for 8 and 16 bit embedded systems. IT is a
>generic compiler system that is not usually a patch onthe commercial
>ones.. 

Avr-gcc actually generates _very_ nice code for the AVR, better than
one commercial compiler I use, and comparable with another.  Of
course, unlike the 8051, the AVR was developed with HLL (esp. C) in
mind.  For example, it has 32 general-purpose registers.

[...re: 8051...]
>>though there is a Modula-2
>>compiler.
>
>But is it any good? 

You'd have to ask Mr. Granville.  Though I think I know what he'd say.
;-)

But as a datapoint, it was able to come within one instruction of my
handwritten assembly on a pathological checksum routine I posted back
in January of 1999 (seven instructions vs. six).  The Keil C compiler
I was usingat the time (v5.5 IIRC) was unable to do better than 13,
even when using the intrinsics for byte rotation and testing the carry
bit.

So from what little I've seen, I'd say it looks quite good.

>
>I once had to work on an embedded system using Mod2 a none of the
>compilers supported the basic language in the same way.  Let alone
>extensions.  It turned out that the most stable compiler was the least
>standard :-( 
>
>A theoretically good language is no use at all if the compiler
>implementations are no good. 

Fewer implementations implies fewer good implementations, true.  At
least the odds are reduced.  Fewer targetted platforms means your code
is less portable as well.

>
>At least with C there will usually be several commercial compilers and a
>multitude of testing and checking tools.  

I think I said it earlier in this thread: The only processors I'm
aware of that don't have a C or NQC (Not Quite C) compiler are
four-bitters.  It's ubiquitous.

But C can be, umm, subtle, and static checking tools (particularly
Lint) are IMHO _required_.  Sadly, they're not often used.

>
>It's one thing having a compiler but what about the rest. How many ICE
>support ADA? 

Nit: ICE is hardware.  And the various debuggers I've seen shipped
with most ICE systems don't support C particularly well either.

And I haven't used an ICE in years.  

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsys.demon.co.uk>...
> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
> <snarflemike@yahoo.com> writes
> >
> >Some more interesting reading (note that MISRA acknowledges that there
> >are better languages than C for safety-critical work):
> 
> That will change. 

I'd like to hear your thoughts on the noted 100:1 residual error
improvement between SPARK code and C code, all DO-178B level A.  Do
you think the C code examined did not use "a subset, coding standards
and static analysis"?  If they didn't, who does?  Is your claim that,
properly used, C can yield equivalent residual error rates as SPARK? 
If so, why do you think the code examined in the study was a 100 times
worse?

Mike

Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsys.demon.co.uk>...
>             Sil1   Sil2   Sil3 Sil4
> Ada          HR    HR      R    R
> ADA (subset) HR    HR      HR   HR
> C            R     -      NR    NR
> 
> as expected  BUT
> 
> C (subset, codinng standard and static analysis) 
>              HR   HR      HR     HR

I had a thought about this also.  In the Ada case we see a change from
R (recommended) to HR (highly recommended) at SIL3 and SIL4.  In the C
case we see a change from NR (not recommended), past - (no
recommendation) and R to HR.  To go from Ada to SPARK is one step
(i.e. good to best) while to go from C to SIL4-C is three steps (i.e.
worst to best).  How will that (3 step improvement vs. 1 step
improvement) manifest itself in the complexity, cost and lack of
errors in the tools, the expressiveness and ease of use of the
resulting language subset, etc, etc.

Mike

Ian Bell wrote:
> In the toy industry the norm is for the inventor to develop the toy to
> the stage where it is presentable to the toy companies and as often as
> not the inventor then pays to cost reduce it.

Would it be fair to say that the product has to be flashy enough to be
unbuildable (cheaply) just to make the sale?  What I see is people
developing a product that has saleable merit, then once the sale is made
and they have to make it real they end up retreating to the point of
making the same thing as everybody else.

In the end, I don't think the customer values whatever it is they say
they want.

Dave Hansen wrote:

> The AVR is supported by GCC, so GNAT might work, though the runtime
> support probably isn't there.  I haven't tried it in any case.

Please, there is a version of GNAT that requires zero run-time support. 
   In fact in the safety critical market it is favored as a base for 
SPARK, since then there is no need to validate the run-time.

But remember that you really have to think in terms of development host, 
target, and the ICE or other system used to download and run tests.  So 
the triplet you want may or may not be supported.

> The 8015 I've never heard of.  I assume you mean 8051, to which I'd
> have to say I haven't heard of one, though there is a Modula-2
> compiler.

There have been several Ada compilers that targetted 8-bit 
microprocessors.  However, I don't think anyone ever validated an 8051 
target due to capacity limitations.  There is an interesting discussion 
here, at length, about that topic (in 1995): 
http://www.adahome.com/News/Trip-Reports/TA95-email.html

There is evan a comment there (by me):

"AFAIK the smallest computers that Ada has been targeted to
include the 128-kbyte Western Digital P-machines, the Russian PDP-11
clones, and the RRSoft compiler which ran on 512K 8088 based
PC-clones.

However, in all these cases the compiler was self-hosted!

So certainly an 8051 target is very reasonable, it just remains
to be seen if anyone wants to do it."

I think the situation is still the same, although there are other 8-bit 
and even 4-bit microcontrollers with Ada targets.  So it may just be 
that programmers who choose Ada choose Motorola microprocessors, and 
vice-versa.  (In point of fact, I've never used an Intel microprocessor 
in an embedded system, but I have used many Motorola chips, and Z-80s.)

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Alan Balmer <albalmer@att.net> wrote in message news:<n4i3uvsm9jhs3uskjpip15a1ntisbep8r5@4ax.com>...
> On 18 Dec 2003 01:36:04 GMT, Peteris Krumins
> <pkruminsREMOVETHIS@inbox.lv> wrote:
> 
> >CBFalconer <cbfalconer@yahoo.com> wrote in news:3FE026A8.3CD6A3A@yahoo.com:
> >
> >> 
> >> The C language is inherently unsafe, which
> >> is one of the reasons languages with much higher safety (there is
> >> no absolute guarantee) have been designed.  Ada is one such. 
> >> Pascal is another, with more insecurities than Ada, and less
> >> power, but much simpler.
> >> 
> >
> >Could you tell me why is C language inherently unsafe? And why Ada or 
> >Pascal are considered safer?
> >
> Actually, it's the programmers who are unsafe, not the language. C
> provides little to protect them against themselves, whereas Ada and
> some other languages make it somewhat harder to write unsafe code.

I'm jumping into this discussion a bit late, but let me just try an
analogy that I have used at my workplace. I think C is to Ada as a
motorcycle is to a car. Yes, a motorcycle is likely to be more fun to
ride than a car is to drive. Also, an expert rider who rides
cautiously might even be able to ride safer than a bad driver can
drive. But we all know that, in general, motorcycles are not as safe
as cars. Not even close. And if you are trying to develop
safety-critical systems with C, that is comparable to using a
motorcycle for basic family transportation. Not the wisest thing to
do.

But that's just my opinion. If you want the opinions of experts at
DoD, MISRA, ARINC, NASA, and CENELEC, check out the one-page summary I
put together at http://RussP.org/Ada-recommend.pdf . Check out the
other links at my Ada page too while you're at it
(http://RussP.org/Ada.htm).

In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
<iddw@hotmail.com> writes
>On Wed, 24 Dec 2003 20:41:41 +0000, Chris Hills <chris@phaedsys.org>
>>
>>At least with C there will usually be several commercial compilers and a
>>multitude of testing and checking tools.  
>
>I think I said it earlier in this thread: The only processors I'm
>aware of that don't have a C or NQC (Not Quite C) compiler are
>four-bitters.  It's ubiquitous.

I like "NQC"....  it is a useful TLA as the standards people get in to a
tizz when you talk about the C that is on most 8/16 bit embedded
compilers. 

>But C can be, umm, subtle, and static checking tools (particularly
>Lint) are IMHO _required_.  Sadly, they're not often used.

There is NO EXCUSE for not using a static analyser on C. There are free
Lints,  Commercial ones i.e.   PC-Lint is only a couple 100 USD

I can't see ANY justification for not using some form of Lint with C.

>>It's one thing having a compiler but what about the rest. How many ICE
>>support ADA? 
>
>Nit: ICE is hardware.

Yes.... of course it is. It is an embedded debugging tool. Somewhat
relevant in a discussion on language support in an embedded NG

>  And the various debuggers I've seen shipped
>with most ICE systems don't support C particularly well either.
>And I haven't used an ICE in years.  
I have... several. 

ICE support C VERY well.  As well as (actually better) than simulators.

There is little of no similar support for most other languages.  There
is some for ADA... Years ago I saw some for Pascal and Modula2 but I
don't know any supporting them now.

If you don't use an ICE how do you debug and test?

Regards
  Chris

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <bebbba07.0312242000.7b6f33bc@posting.google.com>, Russ 
>But that's just my opinion. If you want the opinions of experts at
>DoD, MISRA,

that will change in 3 months time with MISRA-C2

> ARINC, NASA, and CENELEC,
61508 has C (with subset etc) as HR the same as Ada.
> check out the one-page summary I
>put together at http://RussP.org/Ada-recommend.pdf . Check out the

You will need to modify it.

Whilst looking though some notes I found a table  in the IEE Computing &
Control Engineering Journal Vol 11.1 The edition was loking at 61508 the
paper by R. Bell and PA Bennett.

The table shows failures in safety related systems  

44.1%  were due to specification faults
20.6 due to changes after commissioning

joint 3rd with 14.7% were:
design and implementation
operation and maintenance

there was also
5.9% on installation and commissioning.

So it's not down to the language as much as specification and
process.....  

See the Arianne 5 rocket project. The system failed 29 seconds in due to
Sw errors. the problem was not so much Ada but the way it was used and
the project managed. 

NB the project would have flown if C had been used because C is not
strongly typed and the same error would not have been generated.... OK..
I know, if they used C it would never have lifted off in the first
place.... :-)

With a good process in place and proper engineering removing the vast
majority of errors we start to discover the differences in languages is
less important. More important is how good the tools and support tools
for a language are. 

I know of one very high integrity system that is using C because the
quality of the compiler is very high and the support tools are
available. They are not available for Ada for the same target. they
could not have done the same level of testing and validation.






 



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <SLednTOvKejD0XeiRVn-gg@comcast.com>, Robert I. Eachus
<rieachus@comcast.net> writes
>Dave Hansen wrote:
>
>But remember that you really have to think in terms of development host, 
>target, and the ICE or other system used to download and run tests.  So 
>the triplet you want may or may not be supported.

Exactly my point. A theoretically good language is useless without the
support tools.... And those support tools haveto be of high quality as
well. 

>> The 8015 I've never heard of.  I assume you mean 8051, to which I'd
>> have to say I haven't heard of one, though there is a Modula-2
>> compiler.
>
>There have been several Ada compilers that targetted 8-bit 
>microprocessors.

I am surprised.

>  However, I don't think anyone ever validated an 8051 
>target due to capacity limitations. 
That is the problem. A non-validated Ada compiler would be no more value
than a good C compiler. Actually  a good C compiler eg the Keil C51 that
has been extensively used in safety related projects by a large number
of people would be better simply because of the empirical field usage
compared to a non-validated Ada compiler with a small user base..


> There is an interesting discussion 
>here, at length, about that topic (in 1995): 
>http://www.adahome.com/News/Trip-Reports/TA95-email.html

>There is evan a comment there (by me):
>"AFAIK the smallest computers that Ada has been targeted to
>include the 128-kbyte Western Digital P-machines, the Russian PDP-11
>clones, and the RRSoft compiler which ran on 512K 8088 based
>PC-clones.
>
>However, in all these cases the compiler was self-hosted!

That takes some doing!!!


>So certainly an 8051 target is very reasonable, it just remains
>to be seen if anyone wants to do it."

I doubt it. At least not in large enough numbers to justify it
especially as 61508 permits C  (subset, with coding standard and static
checking) to SIL-4

In effect a SPARK-C


>I think the situation is still the same, although there are other 8-bit 
>and even 4-bit microcontrollers with Ada targets.  So it may just be 
>that programmers who choose Ada choose Motorola microprocessors, and 
>vice-versa.  (In point of fact, I've never used an Intel microprocessor 
>in an embedded system, but I have used many Motorola chips, and Z-80s.)

Yes there are a LOT!!  They are mainly the 186 and 386. There are of
course the PC 104 systems but... Strangely due to the sort of projects
they 186 and 386 were used in there has been a lot of activity in that
field over the last 9 months.... However I doubt this interest will
continue (unless somewhere else gets invaded)



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <20619edc.0312241511.3a934503@posting.google.com>, Mike Silva
<snarflemike@yahoo.com> writes
>Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsy
>s.demon.co.uk>...
>>             Sil1   Sil2   Sil3 Sil4
>> Ada          HR    HR      R    R
>> ADA (subset) HR    HR      HR   HR
>> C            R     -      NR    NR
>> 
>> as expected  BUT
>> 
>> C (subset, codinng standard and static analysis) 
>>              HR   HR      HR     HR
>
>I had a thought about this also.  In the Ada case we see a change from
>R (recommended) to HR (highly recommended) at SIL3 and SIL4.  In the C
>case we see a change from NR (not recommended), past - (no
>recommendation) and R to HR.  To go from Ada to SPARK is one step
>(i.e. good to best) while to go from C to SIL4-C is three steps (i.e.
>worst to best).  

btw not "worst to best"  

I agree to a point. I think this reflects the engineering profession is
maturing and the support tools are coming of age.

>How will that (3 step improvement vs. 1 step
>improvement) manifest itself in the complexity, cost and lack of
>errors in the tools, the expressiveness and ease of use of the
>resulting language subset, etc, etc.

I think that there are now tools and methods in place that there were
not previously.  The sheer weight of the commercial pressure has
improved quality in the compilers and support tools. It has generated a
lot of safety related support for a language that was not originally
designed to be a safety critical language. 

This does not mean it can't be used for safety related projects just
that initially the users were not working in that sort of a field so the
mind set was not there. You could write appalling code in Ada but the
average practitioner has been taught Ada with a view to safety related
systems. The majority of C programmers were not.



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On 24 Dec 2003 14:59:57 -0800, snarflemike@yahoo.com (Mike Silva)
wrote:

>Chris Hills <chris@phaedsys.org> wrote in message news:<45cs9hAbLc6$EAAx@phaedsys.demon.co.uk>...
>> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
>> <snarflemike@yahoo.com> writes
>> >
>> >Some more interesting reading (note that MISRA acknowledges that there
>> >are better languages than C for safety-critical work):
>> 
>> That will change. 
>
>I'd like to hear your thoughts on the noted 100:1 residual error
>improvement between SPARK code and C code, all DO-178B level A.  Do
>you think the C code examined did not use "a subset, coding standards
>and static analysis"?  If they didn't, who does?  Is your claim that,
>properly used, C can yield equivalent residual error rates as SPARK? 

That seems obvious. It's possible to write a C program with *no*
residual errors. It may be easier to write a SPARK program with no
residual errors, but there's no law that says C programs have to have
more errors.

>If so, why do you think the code examined in the study was a 100 times
>worse?
>
Hard to tell, from the given data. Direct access to the study would be
needed. I would be surprised if the authors of the study didn't do
some analysis of causes.

-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

"Chris Hills" <chris@phaedsys.org> wrote in message
news:fUk12TA8gB7$EA$E@phaedsys.demon.co.uk...
> I doubt it. At least not in large enough numbers to justify it
> especially as 61508 permits C  (subset, with coding standard and static
> checking) to SIL-4
>
> In effect a SPARK-C

When you says static checking, do you include static checkers that can prove
that assertions are never volilated (within a set of assumptions)?  If so
then your C subset with static checking might be in effect a SPARK-C.  SPARK
supports some very nice formal verification techniques which you might be
overlooking.

-CRM

Chris Hills wrote:

I wonder how you can speak about a programing languages if you can't even
spell there names properly.

> I once had to work on an embedded system using Mod2 a none of the

It's Modula-2. If you are to lazy to type additional four characters you
should not be writing savety critical software.

> It's one thing having a compiler but what about the rest. How many ICE
> support ADA?

Ada is the name if a woman and not the American Denitist Association and as
such spelled capital "A", lower "d", lower "a" - "Ada".

With Regards

Martin.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Martin Krischik wrote:
> It's Modula-2. If you are to lazy to type additional four characters you
> should not be writing savety critical software.

It's "too" and "an" and "safety". If you are too lazy to use a spelling and
grammar checker, you should not be writing comments criticizing other peoples'
writing.

In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills <chris@phaedsys.org> writes:
> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
> <iddw@hotmail.com> writes

>>But C can be, umm, subtle, and static checking tools (particularly
>>Lint) are IMHO _required_.  Sadly, they're not often used.
> 
> There is NO EXCUSE for not using a static analyser on C.

Certainly there is an excuse -- it is not enforced by the compiler.

That is quite different from the situation with Ada.

In article <bcEFNEK9esyI@eisner.encompasserve.org>, Larry Kilgallen
<Kilgallen@SpamCop.net> writes
>In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills 
><chris@phaedsys.org> writes:
>> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
>> <iddw@hotmail.com> writes
>
>>>But C can be, umm, subtle, and static checking tools (particularly
>>>Lint) are IMHO _required_.  Sadly, they're not often used.
>> 
>> There is NO EXCUSE for not using a static analyser on C.
>
>Certainly there is an excuse -- it is not enforced by the compiler.
>
>That is quite different from the situation with Ada.

So it all has to be enforced by the compiler?

The main difference between C and ADa is that the average ADA programmer
is in a safety critical environment. The average C programmer is not. 

If C program development was *normally* taught as though it was going to
be used in a safety critical environment I think things would change. 



/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Hyman Rosen <hyrosen@mail.com> writes:

> Martin Krischik wrote:
> > It's Modula-2. If you are to lazy to type additional four characters you
> > should not be writing savety critical software.
> 
> It's "too" and "an" and "safety". If you are too lazy to use a
> spelling and grammar checker, you should not be writing comments
> criticizing other peoples' writing.

:-)

Well said, Hyman.

It's true that Ada is correctly spelt "Ada", not "ADA" or "ADa", but
come on.  Why do we need to make a big deal about it?  Ada has some
advantages over C, but beating people up over the spelling isn't going
to convince anybody of anything.

- Bob

P.S. for those interested in Ada trivia: In the December 22 issue of
Newsweek, there's a photo of Tony Blair standing in front of a portrait
of Ada.  That's the Ada for whom the language was named.  Page 32.

Chris Hills <chris@phaedsys.org> writes:

> In article <bcEFNEK9esyI@eisner.encompasserve.org>, Larry Kilgallen
> <Kilgallen@SpamCop.net> writes
> >In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills 
> ><chris@phaedsys.org> writes:
> >> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
> >> <iddw@hotmail.com> writes
> >
> >>>But C can be, umm, subtle, and static checking tools (particularly
> >>>Lint) are IMHO _required_.  Sadly, they're not often used.
> >> 
> >> There is NO EXCUSE for not using a static analyser on C.
> >
> >Certainly there is an excuse -- it is not enforced by the compiler.
> >
> >That is quite different from the situation with Ada.
> 
> So it all has to be enforced by the compiler?

No, it doesn't.  I agree with you that (in principle) there's nothing
wrong with running 'lint' or whatever in addition to the compiler.
However, 'lint' (in the case of C) doesn't have enough information
to perform the checks that are routinely done by Ada compilers.

The issue is not (primarily) which tool does the analysis (the compiler
versus lint).  The issue is how much information about the intent of the
programmer is contained in the source code.

> The main difference between C and ADa is that the average ADA programmer
> is in a safety critical environment. The average C programmer is not. 

I think it's a mistake to assume that that "average" Ada programmer is
doing safety critical work.  Ada (and/or SPARK) are good in that
environment, but Ada is also quite good for writing run-of-the-mill
non-safety-critical programs, too.  I don't know the statistics, so I
can't say about "average", but the program I'm working on right now
is not safety critical, or even real-time or embedded, but I get some
productivity benefit from Ada's ability to allow me to express various
(compile-time-checkable) constraints.

So I don't agree that the "main" difference between C and Ada is their
environment.

(Boy, I guess the spelling police will really get after you for spelling
"Ada" wrong twice in the same sentence -- "ADa" and "ADA".  Sheesh.  ;-))

> If C program development was *normally* taught as though it was going to
> be used in a safety critical environment I think things would change. 

Probably.  But to learn Ada, you have to first learn to write "Hello,
world", and then learn some more simple stuff, and so on.  Same with C.
Nobody learns to write real-time/embedded/high-integrity/safety-critical
stuff on the first try.

- Bob

In article <p$OIcVFWHL7$EA6t@phaedsys.demon.co.uk>, Chris Hills <chris@phaedsys.org> writes:
> In article <bcEFNEK9esyI@eisner.encompasserve.org>, Larry Kilgallen
> <Kilgallen@SpamCop.net> writes
>>In article <$km9afA3DB7$EAYO@phaedsys.demon.co.uk>, Chris Hills 
>><chris@phaedsys.org> writes:
>>> In article <3fea086c.110513550@News.CIS.DFN.DE>, Dave Hansen
>>> <iddw@hotmail.com> writes
>>
>>>>But C can be, umm, subtle, and static checking tools (particularly
>>>>Lint) are IMHO _required_.  Sadly, they're not often used.
>>> 
>>> There is NO EXCUSE for not using a static analyser on C.
>>
>>Certainly there is an excuse -- it is not enforced by the compiler.
>>
>>That is quite different from the situation with Ada.
> 
> So it all has to be enforced by the compiler?
> 
> The main difference between C and ADa is that the average ADA programmer
> is in a safety critical environment. The average C programmer is not. 
> 
> If C program development was *normally* taught as though it was going to
> be used in a safety critical environment I think things would change. 

Whereas I think that so long as the infrastructure leaves certain things
to be done "by hand" there will be skimping.

Consider all the regulation and oversight required for drug safety tests.

Several people have asserted the argument that the large
number of users of a given tool implies quality in that tool.

I don't buy it.  By this logic, MS Windows should be
absolutely flawproof, and the infamous Pentium Divide bug
should never have happened.

No amount of usage can make up for design flaws.  Popularity
is much less about technical qualities than it is about
marketing.  C, Windows, x86 chips have substantial market
share, which is not the same as saying that they have
substantial quality by design.

			dave

Chris Hills <chris@phaedsys.org> writes:

> That is the problem. A non-validated Ada compiler would be no more value
> than a good C compiler. 

That's a pretty strong statement, and I would argue demonstrably
false. The public GNAT compiler 3.15p is non-validated (in the
strictest technical sense; that specific version does not come with a
validation certificate).

The version of Ada most likely to run on 8 bit machines would have no
tasking, no exceptions, and possibly no floating or fixed point, or
dynamic dispatching. That would still be a far better language than C!
Packages, generics, strong typing in general, aggregates,
representation clauses; none of these make demands on the run-time
environment, but all are very powerful programming language features.

> Actually a good C compiler eg the Keil C51 that has been extensively
> used in safety related projects by a large number of people would be
> better simply because of the empirical field usage compared to a
> non-validated Ada compiler with a small user base..

Well, if by "better" you solely mean "more trusted", or possibly "more
thoroughly tested", I would agree. But I'd still use the Ada compiler,
and write thorough unit tests. I don't trust _any_ compiler to not
have bugs when running _my_ code.

-- 
-- Stephe

Chris Hills <chris@phaedsys.org> wrote in message news:<vUh5muAofB7$EAZb@phaedsys.demon.co.uk>...
> In article <bebbba07.0312242000.7b6f33bc@posting.google.com>, Russ 
> >But that's just my opinion. If you want the opinions of experts at
> >DoD, MISRA,
> 
> that will change in 3 months time with MISRA-C2
> 
> > ARINC, NASA, and CENELEC,
>  61508 has C (with subset etc) as HR the same as Ada.
> > check out the one-page summary I
> >put together at http://RussP.org/Ada-recommend.pdf . Check out the
> 
> You will need to modify it.
> 
> Whilst looking though some notes I found a table  in the IEE Computing &
> Control Engineering Journal Vol 11.1 The edition was loking at 61508 the
> paper by R. Bell and PA Bennett.
> 
> The table shows failures in safety related systems  
> 
> 44.1%  were due to specification faults

That's interesting, and I should probably look up this paper (is it
online?). After thinking about it a bit, however, this result is not
too surprising. After all, it seems to me that "specification fault"
is a rather general term. What does it mean? Is it perhaps a catch-all
term for everything other than the software development process
itself?

I work in an engineering environment. Engineers come up with ideas,
which are then often translated into software. Sometimes the
translation process (design/programming) is done directly by the
engineer, but more often it is done by communicating the idea to a
programmer or software engineer. Any defect in the idea itself or in
its communication to the programmer falls under the category of
"specification fault," it seems to me. Being an aerospace engineer
myself, I like to think of myself as an important part of the process.
If our portion of the errors was too small, I'd think that perhaps we
engineers were not taking enough risks with our ideas. So I'm proud
that we're at the 44% level. ;^)

What I am getting at, in a roundabout way, is that, as you probably
realize, "specification faults" have nothing to do with the choice of
programming language. That's an engineering problem. So it is as
irrelevant to the choice of language as, say, drug abuse in the
workplace, just to give an off-the wall example. Would you argue that
the choice of programming language is of minimal importance if half of
the critical errors were due to drugged programmers? Of course not. So
why are you implying that language choice is unimportant because
engineering is important?

> 20.6 due to changes after commissioning

Is that what we sometimes call "maintenance"? My impression is that
Ada excels in this stage.

> joint 3rd with 14.7% were:
> design and implementation
> operation and maintenance
> 
> there was also
> 5.9% on installation and commissioning.
> 
> So it's not down to the language as much as specification and
> process.....  

Of course it isn't. If the engineering isn't done right, the best
programmers and software engineers in the world are unlikely to
salvage the project.

> See the Arianne 5 rocket project. The system failed 29 seconds in due to
> Sw errors. the problem was not so much Ada but the way it was used and
> the project managed. 
> 
> NB the project would have flown if C had been used because C is not
> strongly typed and the same error would not have been generated.... OK..
> I know, if they used C it would never have lifted off in the first
> place.... :-)

Are you claiming that the Arianne 5 wouldn't have failed
catastrophically if the same bug had occurred in C code? If so, that's
definitely interesting. I'm certainly not knowledgable enough here to
comment, but I'm sure others on this forum are.

> With a good process in place and proper engineering removing the vast
> majority of errors we start to discover the differences in languages is
> less important. More important is how good the tools and support tools
> for a language are. 

You lost me there. As I explained above, I agree that the choice of
language has little effect on the engineering. But the point is that
the choice of language has a strong effect on the software design and
development process. Isn't that what we're talking about here? If not,
sorry, wrong number.

"Martin Krischik" <krischik@users.sourceforge.net> wrote in message
news:5802069.JsgInS3tXa@linux1.krischik.com...
> Chris Hills wrote:
>
>
> > I once had to work on an embedded system using Mod2 a none of the
>
> It's Modula-2. If you are to lazy to type additional four characters you
> should not be writing

->savety<-

> critical software.

Robert A Duff <bobduff@shell01.TheWorld.com> wrote in 
news:wccekur4151.fsf@shell01.TheWorld.com:

> Chris Hills <chris@phaedsys.org> writes:
>> So it all has to be enforced by the compiler?
> 
> No, it doesn't.  I agree with you that (in principle) there's nothing
> wrong with running 'lint' or whatever in addition to the compiler.
> However, 'lint' (in the case of C) doesn't have enough information
> to perform the checks that are routinely done by Ada compilers.

Two simple examples are array bounds checking and scalar range checking.

The C standard explicitly permits accessing one element beyond the end
of an array. Neither the C compiler nor lint can determine if an array
index is outside the bounds of the array. Ada compilers detect static
references beyond the end of an array every time.

Examples:

int foo[10];

int i;

for(i = 0; i < 100; ++i)
{
   foo[i] = i;
}

Although human inspection clearly identifies the for loop indices
to be beyond the bounds of the array, neither the C compiler nor lint
will detect the problem. Since the problem can be clearly identified
using human inspection one might assume this is a problem one would
never see. Unfortunately, the definition of the array may occur many
dozens or even hundreds of lines of code away from the "for" loop.
The definition and the "for" loop may even be located in different 
source files, making the likelihood of human identification very low.

type my_index is range 0..9;
type My_Array_Type is array(my_index) of integer;

foo : My_Array_Type;

for num in 0..99 loop
   foo(num) := num;
end loop;

All Ada compilers will correctly identify the error in the for loop.
The type of "num" is not the same as the type of the index, because
the range of values defined for "num" are not all within the range of
values in my_index. This detection will happen properly no matter how
far the definition is separated from the "for" loop.

Another problem, at least in my uses of lint in the past, was the
settings for lint. You can set lint sensitivity from very low to
very high. The lowest settings for lint miss a number of errors, while
the highest settings for lint often produce a number of false error
indications. It is not always obvious which lint setting to use for
the best level of error identification with a minimum of false error 
messages.

Jim Rogers

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns945DE49836882jimmaureenrogers@204.127.36.1...
> Robert A Duff <bobduff@shell01.TheWorld.com> wrote in
> news:wccekur4151.fsf@shell01.TheWorld.com:
>
> > Chris Hills <chris@phaedsys.org> writes:
> >> So it all has to be enforced by the compiler?
> >
> > No, it doesn't.  I agree with you that (in principle) there's nothing
> > wrong with running 'lint' or whatever in addition to the compiler.
> > However, 'lint' (in the case of C) doesn't have enough information
> > to perform the checks that are routinely done by Ada compilers.
>
> Two simple examples are array bounds checking and scalar range checking.
>
> The C standard explicitly permits accessing one element beyond the end
> of an array. Neither the C compiler nor lint can determine if an array
> index is outside the bounds of the array. Ada compilers detect static
> references beyond the end of an array every time.
>
> Examples:
>
> int foo[10];
>
> int i;
>
> for(i = 0; i < 100; ++i)
> {
>    foo[i] = i;
> }
>
> Although human inspection clearly identifies the for loop indices
> to be beyond the bounds of the array, neither the C compiler nor lint
> will detect the problem. Since the problem can be clearly identified



While most C compilers and lint won't find this, there are static analysis
tools that can. Granted the
tools may be able to do a better job on Ada code because there is more
information to work with but
simple cases like you presented here (even if the loop was "far away:" from
foo) can be detected
by tools like Programming Research QA C (No Ada Available) and Polyspace
(Ada available)..

Perhaps even by the LDRA static analysis tools (Ada available) though I have
less to go on for this tool.

"Jeff C," <nolongersafeto@userealemailsniff.com> wrote in
news:yA9Hb.488862$275.1387889@attbi_s53: 

> While most C compilers and lint won't find this, there are static
> analysis tools that can. Granted the
> tools may be able to do a better job on Ada code because there is more
> information to work with but
> simple cases like you presented here (even if the loop was "far away:"
> from foo) can be detected
> by tools like Programming Research QA C (No Ada Available) and
> Polyspace (Ada available)..

Of course, static analysis for any language has its limitations.
For example, what tool exists for C that will reliably identify
the following problem:

int foo[10];

int total(int *a)
{
   int i;
   int sum = 0;
   for(i = 0; i < 100; ++i)
   {
      sum += a[i];
   }
   return sum;
}

Of course, the common C idiom is to pass a limit value along
with the array reference.

int total(int *a, int limit)
{
   int i;
   int sum = 0;
   for(i = 0; i < limit; +=i)
   {
      sum += a[i];
   }
   return sum;
}

The problem is that there is no explicit relationship between
the value passed to the formal parameter "limit" and the number
of elements in the array. It is up to the programmer to ensure
correctness in this detail.

Ada, on the other hand, provides a completely safe syntax to
deal with such problems.

type my_index is range 0..9;

type my_array is array(my_index range <>) of integer;

function total(a : my_array) return integer is
   sum : integer := 0;
begin
   for i in a'range loop
      sum := sum + a(i);
   end loop;
   return sum;
end total;

The Ada run-time will produce a correct iteration through
the array passed to total every time. The compiler will detect
any attempt to pass an parameter that is not of the type my_array.

This is clearly not a case that can be fully handled using static
analysis. Nevertheless, it must be handled correctly for all valid
cases. In Ada it can be proven that the iterations will always be
correct. In C there is no such proof possible. You must rely upon
the skills and attention of the programmer.

When reliability engineers encounter a system relying upon human
actions the commonly accepted error rate, assuming properly trained
humans, is 1 in 1000. Such an error rate is unacceptably low for
most safety critical systems. An error rate of 1 in 1000 is a
reliability rate of 0.999. Safety critical systems commonly
require reliability rates on the order of 0.999999. This is
three orders of magnitude higher than can be achieved through
reliance on human correctness.

Jim Rogers

Hyman Rosen wrote:

> Martin Krischik wrote:
>> It's Modula-2. If you are to lazy to type additional four characters you
>> should not be writing savety critical software.
> 
> It's "too" and "an" and "safety". If you are too lazy to use a spelling
> and grammar checker,

I am not lo lazy for that. It's just that sending an english post thue a
german spell checker won't help.

> you should not be writing comments criticizing other
> peoples' writing.

I would never comment on sombodies general spelling. Mine is bad enough.
Only in this case it was the spelling of what we here call an "Eigenname".
A name which starts in englich with a capital letter.

Also, if you never read enough about Ada to know how it is spelled, how do
you know enough about its features.

Did you know about:

type Month is new Integer range 1 .. 12;
for Month'Size is 8;

and how will you do it in C?

Use an unsigned short int. Well an short int is usualy 16 bit not 8.

Use an unsigned char? Well it is 8 bit - but is is a character not a number.

If you are lucky you have real C99 compiler with byte. But byte is still
0 .. 255 wich is more the 20 times range needed. That means - in savety
critical software - you have to "assert" the value before using it.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

James Rogers wrote:

snip
> 
> type my_index is range 0..9;
> type My_Array_Type is array(my_index) of integer;
> 
> foo : My_Array_Type;
> 
> for num in 0..99 loop
>    foo(num) := num;
> end loop;
> 
> All Ada compilers will correctly identify the error in the for loop.
> The type of "num" is not the same as the type of the index, because
> the range of values defined for "num" are not all within the range of
> values in my_index. This detection will happen properly no matter how
> far the definition is separated from the "for" loop.
> 

I know nothing about ada so this is a genuine query rather than a ctiticism. 
The above example is fine as long as literals are used - even a C compiler
could be devised to make this check - but what happens when the array index
is computed?

Ian

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns945DE49836882jimmaureenrogers@204.127.36.1...
> The C standard explicitly permits accessing one element beyond the end
> of an array.

Careful! All that the standard guarantees is that the address of the one
element beyond the should compare in the expected fashion with the addresses
of the other array elements. For example, if we have

    int foo[10];
    int* bar = foo + 10;

then the C standard will guarantee that

    bar > foo + i

for any i in the range 0 .. 9 inclusive. Although the standard guarantees
the behavior of a pointer one past the end of an array, it explicitly does
NOT guarantee anything about accessing an element past the end of an array.
An attempt to read or write *bar leads to unpredictable results.

> Neither the C compiler nor lint can determine if an array
> index is outside the bounds of the array.

It depends. I would imagine that some C compilers and lint might catch
something like this:

    int foo[10];
    ...
    j = foo[10];

The real problem is that once an array is passed to a function, length
information is lost. This is one area where the C++ vector template made a
real advance. Of course, Ada had the approach to arrays all along, in that
it never divorced the length from the array data.

In article <aA4Hb.15723$Fg.396@lakeread01>, David Emery <demery@cox.net>
writes
>Several people have asserted the argument that the large
>number of users of a given tool implies quality in that tool.
>
>I don't buy it.  By this logic, MS Windows should be
>absolutely flawproof, and the infamous Pentium Divide bug
>should never have happened.

We are in comp.arch.embedded...... Ms Desktop tools are not relevant.
Besides AFAIK their license excludes any safety critical use.

>No amount of usage can make up for design flaws.  Popularity
>is much less about technical qualities than it is about
>marketing.  C, Windows, x86 chips have substantial market
>share, which is not the same as saying that they have
>substantial quality by design.

Correct for the desktop tools but among *Embedded* tools it does
especially where the aim is to go for the high reliability market. 

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> writes:

> James Rogers wrote:
> 
> snip
> > 
> > type my_index is range 0..9;
> > type My_Array_Type is array(my_index) of integer;
> > 
> > foo : My_Array_Type;
> > 
> > for num in 0..99 loop
> >    foo(num) := num;
> > end loop;
> > 
> > All Ada compilers will correctly identify the error in the for
> > loop.  The type of "num" is not the same as the type of the index,
> > because the range of values defined for "num" are not all within
> > the range of values in my_index. This detection will happen
> > properly no matter how far the definition is separated from the
> > "for" loop.
> 
> I know nothing about ada so this is a genuine query rather than a
> ctiticism.  The above example is fine as long as literals are used -
> even a C compiler could be devised to make this check - but what
> happens when the array index is computed?

You mean as in

  type my_index is range 0 .. some_variable;

-- yes, Ada compilers will perform the check.

Actually the code wasn't actually compiled by whoever posted it, a
crime on c.l.a: you either have to say

  for Num in 0 .. 99 loop
     Foo (My_Index (Num)) := Num;
  end loop;

(which GNAT doesn't see as a problem until execution time) or 

   for Num in My_Index range 0 .. 99 loop
      Foo (Num) := Integer (Num);
   end loop;

to which GNAT says

constraints.adb:10:35: warning: static value out of range of type "My_Index" defined at line 3
constraints.adb:10:35: warning: "Constraint_Error" will be raised at run time

(this is the "99").

In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
:James Rogers> foo : My_Array_Type;
:> 
:> for num in 0..99 loop
:>    foo(num) := num;
:> end loop;
:> 
:> All Ada compilers will correctly identify the error in the for loop.
:> [...]
: 
: I know nothing about ada so this is a genuine query rather than a ctiticism. 
: The above example is fine as long as literals are used - even a C compiler
: could be devised to make this check - but what happens when the array index
: is computed?

Wouldn't that become a famous compiler that finds out, at compile
time, which value a certain variable is going to have? :-)

If you want a hole in your foot, you can make one, though it might
not be easy:

with Interfaces;
with Ada.Integer_Text_IO; use Ada;

procedure t is
   --  read a positive value from standard input and create an
   -- array of that size, which is filled (hopping excessively)

   procedure rubber_buffer(limit: Positive) is

      subtype Index is Positive range 1 .. limit;
      -- a range constraint on Positive, determined at call time

      buffer: array(Index) of Interfaces.Unsigned_8;
      -- storage for 1 .. limit 8bit quantities

   begin
      --  demonstration of constraint_error

      off_buffer:  -- k grows too large for a buffer index

          for k in Index'first .. 2 * Index'last loop
             buffer(k) := 42;  -- index check failed, at run time
          end loop off_buffer;

      off_index_range:  -- k gets too large for Index subtype's range

          for
            k in Index'first .. Index(2 * Index'last)
                                --  range check failed, at run time
          loop
             buffer(k) := 42;
          end loop off_index_range;

   end rubber_buffer;

   n: Positive;
   --  upper limit of 1-based buffer, read at run time

begin
   Integer_Text_IO.get(n);
   rubber_buffer(n);
end t;


That's why language-defined array constructs such as
the 'range attribute are useful. You can write

  for k in buffer'range loop
     buffer(k) := 42;
  end loop;

(or in this case more simply, using language defined `others'

  buffer := (others => 42);)

no matter what the buffer's index range currently is.


-- Georg

Simon Wright wrote:

> Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> writes:
> 
>> James Rogers wrote:
>> 
>> snip
>> > 
>> > type my_index is range 0..9;
>> > type My_Array_Type is array(my_index) of integer;
>> > 
>> > foo : My_Array_Type;
>> > 
>> > for num in 0..99 loop
>> >    foo(num) := num;
>> > end loop;
>> > 
>> > All Ada compilers will correctly identify the error in the for
>> > loop.  The type of "num" is not the same as the type of the index,
>> > because the range of values defined for "num" are not all within
>> > the range of values in my_index. This detection will happen
>> > properly no matter how far the definition is separated from the
>> > "for" loop.
>> 
>> I know nothing about ada so this is a genuine query rather than a
>> ctiticism.  The above example is fine as long as literals are used -
>> even a C compiler could be devised to make this check - but what
>> happens when the array index is computed?
> 
> You mean as in
> 
>   type my_index is range 0 .. some_variable;
> 
> -- yes, Ada compilers will perform the check.
> 

That was not what I had in mind and seems to me to be rather dodgy code.  i
was thinking more of the return value of some function being used as an
index to the array.

Ian

Georg Bauhaus wrote:

> In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
> :James Rogers> foo : My_Array_Type;
> :> 
> :> for num in 0..99 loop
> :>    foo(num) := num;
> :> end loop;
> :> 
> :> All Ada compilers will correctly identify the error in the for loop.
> :> [...]
> : 
> : I know nothing about ada so this is a genuine query rather than a
> : ctiticism. The above example is fine as long as literals are used - even
> : a C compiler could be devised to make this check - but what happens when
> : the array index is computed?
> 
> Wouldn't that become a famous compiler that finds out, at compile
> time, which value a certain variable is going to have? :-)
> 

Ah, so Ada is no better than C in that respect?

Ian

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> wrote in message
news:3feda44e_3@mk-nntp-1.news.uk.worldonline.com...
> James Rogers wrote:
>
> snip
> >
> > type my_index is range 0..9;
> > type My_Array_Type is array(my_index) of integer;
> >
> > foo : My_Array_Type;
> >
> > for num in 0..99 loop
> >    foo(num) := num;
> > end loop;
> >
> > All Ada compilers will correctly identify the error in the for loop.
> > The type of "num" is not the same as the type of the index, because
> > the range of values defined for "num" are not all within the range of
> > values in my_index. This detection will happen properly no matter how
> > far the definition is separated from the "for" loop.
> >
>
> I know nothing about ada so this is a genuine query rather than a
ctiticism.
> The above example is fine as long as literals are used - even a C compiler
> could be devised to make this check - but what happens when the array
index
> is computed?
>
> Ian

The Ada programmer usually uses the range attribute of the array variable
for these cases.

declare
    type My_Integer_Array is array (Positive range <>) of Integer;
    -- Type of array with bounds that are of type Positive (Positive
Integers)

    function Compute_Array return My_Integer_Array is
        -- returns an array of variable size
    ...
    end Compute_Array;

    My_Array : My_Integer_Array := Compute_Array;

    Sum      : Integer := 0;
begin
    -- Summation of add via array iteration
    For I in My_Array'Range loop
        Sum := Sum + My_Array(I);
    end loop;
end;

If you used a literal range in this case, you would trigger a runtime
constraint_error exception (index check failed) if your literal range is not
contained with the array's range.

However, there are other ways that an array range can be computed.

with Ada.Integer_Text_IO;
use  Ada.Integer_Text_IO;

procedure DynamicType is

   LowerBound : Integer;
   UpperBound : Integer;

begin

   Get(LowerBound);
   Get(UpperBound);

   declare

      type New_Bounds is range LowerBound..UpperBound;

      My_Array : array(New_Bounds) of Integer := (others => 1);

      Sum      : Integer := 0;

   begin

      for I in 1..10 loop  -- This will not compile because the compiler
                           -- cannot safety compute the correct type for the
                           -- literal range.
         Sum := My_Array(I);
      end loop;

      Put(Sum);
   end;
end DynamicType;

In practice most Ada programmers don't use literals because array's have
attributes such as 'range, 'first, and 'last, which offer a better
alternative to literals or even constants.

"Georg Bauhaus" <sb463ba@l1-hrz.uni-duisburg.de> wrote in message
news:bskd67$6me$1@a1-hrz.uni-duisburg.de...
> In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
> :James Rogers> foo : My_Array_Type;
> :>
> :> for num in 0..99 loop
> :>    foo(num) := num;
> :> end loop;
> :>
> :> All Ada compilers will correctly identify the error in the for loop.
> :> [...]
> :
> : I know nothing about ada so this is a genuine query rather than a
ctiticism.
> : The above example is fine as long as literals are used - even a C
compiler
> : could be devised to make this check - but what happens when the array
index
> : is computed?
>
> Wouldn't that become a famous compiler that finds out, at compile
> time, which value a certain variable is going to have? :-)
>
> If you want a hole in your foot, you can make one, though it might
> not be easy:


Again, tools like this do exist. One can argue over how well they work but
they do exist.
Tools like Polyspace Verifier can at times tell you statically that you have
a problem in your code.

For example the following psuedo code fragment would likely be flagged as a
potential error by polyspace

A, b : float;
C : integer;
D : array(1 .. 10) of float;

begin
 A := random_float;
 B := cos(a);
 C := integer(C * 9.0) + 1;
  D(C) := 0;
end;


while code like


A, b : float;
C : integer;
D : array(1 .. 10) of float;

begin
 A := random_float;
 B := cos(a);
 C := integer(C * 9.0) + 1;
  if C >= D'first and C <= D'last then
    D(C) := 0;
  end if;
end;


Would not generate an error during static analysis. (at least not for the
obvious error I intended to introduce in the first case ... :)

These tools exist now and have existed for some years.

"Ian Bell" <ian@ruffrecordsDOTworldonline.co.uk> wrote in message
news:3fedbbf0_3@mk-nntp-1.news.uk.worldonline.com...
> Simon Wright wrote:
>
> > Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> writes:
> >
> >> James Rogers wrote:
> >>
> >> snip
> >> >
> >> > type my_index is range 0..9;
> >> > type My_Array_Type is array(my_index) of integer;
> >> >
> >> > foo : My_Array_Type;
> >> >
> >> > for num in 0..99 loop
> >> >    foo(num) := num;
> >> > end loop;
> >> >
> >> > All Ada compilers will correctly identify the error in the for
> >> > loop.  The type of "num" is not the same as the type of the index,
> >> > because the range of values defined for "num" are not all within
> >> > the range of values in my_index. This detection will happen
> >> > properly no matter how far the definition is separated from the
> >> > "for" loop.
> >>
> >> I know nothing about ada so this is a genuine query rather than a
> >> ctiticism.  The above example is fine as long as literals are used -
> >> even a C compiler could be devised to make this check - but what
> >> happens when the array index is computed?
> >
> > You mean as in
> >
> >   type my_index is range 0 .. some_variable;
> >
> > -- yes, Ada compilers will perform the check.
> >
>
> That was not what I had in mind and seems to me to be rather dodgy code.  i
> was thinking more of the return value of some function being used as an
> index to the array.

Ada performs array bounds checking (logically) on every array reference, and
raises an exception if the array index is out of range, unless the programmer
disables it.  Every Ada toolset I have seen defaults to enabling array bounds
checking.  I am not certain but I *THINK* ANSI/MIL-STD-1815A (1983) requires the
toolset to work that way.

For something like this,

  for num in a'range loop
    a(num) = num;
  end loop;

the compiler can determine that num cannot go out of range, and suppress the
check.

For something like

   a(some_function(x,y,z)) = treasure; -- as opposed to trash

the compiler probably can't make that determination, and must compile in a test.

On Sat, 27 Dec 2003 17:08:43 +0000, Ian Bell 
<ian@ruffrecordsDOTworldonline.co.uk> wrote:

> That was not what I had in mind and seems to me to be rather dodgy 
> code.  i
> was thinking more of the return value of some function being used as an
> index to the array.

Ian,

Depends on the relationship of the subtype of the function result to that 
of the index type of the array.

If they're of the same subtype, or of subtypes derived from the same type 
("compatible"), and have the same range, the indexing operation will work 
because an out of range value would have raised an exception before the 
function result returned.

If the subtypes are derived from the same type, but have different ranges, 
a runtime check is performed to make sure the function result is within 
the stated index range.

Finally, if they're incompatible subtypes (not derived from the same 
ancestor type), you'll get a compile time error, unless you explicitly 
convert the function result to a compatible subtype of the index type 
(then the runtime check will be used as in the second case).

The checks can be explictly suppressed.

James Rogers <jimmaureenrogers@att.net> wrote:

[...]

>int foo[10];
>
>int i;
>
>for(i = 0; i < 100; ++i)
>{
>   foo[i] = i;
>}
>
>Although human inspection clearly identifies the for loop indices
>to be beyond the bounds of the array, neither the C compiler nor lint
>will detect the problem. Since the problem can be clearly identified

I guess that PC-Lint _will_ detect this even if you use a pointer to
an array or a upper limit as parameter etc., I already have seen
PC-Lint warnings about possible out of bounds access in similar cases.
If there is any doubt, I can verify it if I'm in the office again.

>using human inspection one might assume this is a problem one would
>never see. Unfortunately, the definition of the array may occur many
>dozens or even hundreds of lines of code away from the "for" loop.

Lint can check the whole application, not only single modules.

Oliver
-- 
Oliver Betz, Muenchen

In article <z+se8hAfAb7$EAYZ@phaedsys.demon.co.uk>, Chris Hills <chris@phaedsys.org> writes:

> We are in comp.arch.embedded...... Ms Desktop tools are not relevant.

Some of us are in comp.lang.ada.

Ian Bell wrote:

> Ah, so Ada is no better than C in that respect?

No, Ada is much better than C in that respect.  The concept that Ada 
supports but C doesn't is best expressed described by example:

function Identity(N: Positive) return Matrix is
   Result: Matrix(1..N, 1..N) := (others => (others => 0.0));
begin
   for I in Matrix(1)'Range loop
     Result(I,I) := 1.0;
   end loop;
   return Result;
end Identity;

The size of the matrix returned will often be determined at run-time, 
but both the compiler and any static checking tools can verify that 
there are no potential out-of-range assignments here. This sort of 
"statically matching" constraints, where the constraints are dynamic but 
can be statically determined to be identical is formalized in RM 4.9.1. 
  There are certain cases in Ada where statically matching subtypes are 
required, but in general Ada programmers tend to use statically matching 
subtypes even where they are not required.  It not only makes for more 
efficient code, since the compiler can remove constraint checks, but it 
means that if the code is changed elsewhere, the change does not need to 
be propagated.  This makes code maintenance much easier.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Stephen Leake wrote:

> The version of Ada most likely to run on 8 bit machines would have no
> tasking, no exceptions, and possibly no floating or fixed point, or
> dynamic dispatching. That would still be a far better language than C!
> Packages, generics, strong typing in general, aggregates,
> representation clauses; none of these make demands on the run-time
> environment, but all are very powerful programming language features.

Actually, there is no reason not to support fixed-point, although I 
probably wouldn't support decimal types.  There is no reason to omit 
exceptions, but I might not support exception occurances (RM 11.4.1). 
And again there is no reason not to support dynamic dispatching, but I 
would certainly limit the number of tasks and the size of task stacks.

But the key question is, "Does the compiler pass all the validation 
tests that I care about?"  This is what the VSR really addresses.  Right 
now it is normal for a validation to list hundreds of tests as 
"non-applicable."  Of course, most of these are for floating-point with 
digits > 14.

Having said all that, I can't really get excited about validating Ada 
compilers for the i8051 or for that matter the Z-80.  Every time I have 
used a chip that "small" on a project, complete test coverage of the 
machine code was not that hard to do.  Typically the chip implements a 
finite-state machine with at most a couple of dozen states, and it is 
easier to tie the generated code to the state diagram in the 
specification than to prove both the source code and the compiler.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
:> Wouldn't that become a famous compiler that finds out, at compile
:> time, which value a certain variable is going to have? :-)
:> 
: 
: Ah, so Ada is no better than C in that respect?

In the dynamic Matrix example by R. Eachus a number of dynamic things
can indeed be statically studied, it seems. This implies there is a
measure for how much can be "found out" at compile time, given the
features of language X.  (In the above sentence I was only trying to
say that there is _no_ real world compiler that can possibly solve
the general problem of finding variables' values at runtime, for some
program in any programming language, given some input :-) But that is
not relevant here I think.)

Splint is an indicator too.  Considering maxSet/maxRead (array bounds, at
least some), require/ensure (Eiffel contracts), modifies (in, out, in out
parameter modes), etc., I suddenly feel very much at home in the language
that tries to look like C, though not quite.
Splint programs can only be translated by a compiler using the trick
of hiding the new language in C comments. I guess that the additional
information in the comments is then not available to the C compiler,
so the C compiler can only profit from users who try to redesign
their software, but it cannot itself profit from the comments...

Will there be profit if a true Splint compiler will evaluate
the additional information in the comments? Would the language
look like, well, not C, semantically? :-)


-- Georg

In article <wp6gcQns6pRu@eisner.encompasserve.org>, Larry Kilgallen
<Kilgallen@SpamCop.net> writes
>In article <z+se8hAfAb7$EAYZ@phaedsys.demon.co.uk>, Chris Hills 
><chris@phaedsys.org> writes:
>
>> We are in comp.arch.embedded...... Ms Desktop tools are not relevant.
>
>Some of us are in comp.lang.ada.

Repent!
:-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
:> You mean as in
:> 
:>   type my_index is range 0 .. some_variable;
:> 
:> -- yes, Ada compilers will perform the check.
:> 
: 
: That was not what I had in mind and seems to me to be rather dodgy code.  i
: was thinking more of the return value of some function being used as an
: index to the array.

That should depend on what the compiler can find out about the
function.  For example, if there is "type Index is range 0..359;",
then if a function is specified to return values of a constrained
subtype of Index ranging from 0..179, and a buffer has been allocated for
some Index subtype's values ranging from 180..359, the compiler will
warn if you use the function's values as indices to the array,
_although_ in C terms the array index values and the function return
values are indistinguishable (both unsigned shorts for example).
I.e.
   type Index is range 0..359;
   subtype First_Half is Index range 0..179;
   subtype Second_Half is Index range 180..359;

   buffer: array(First_Half) of Some_Decimal_Type;

   function some_val return Second_Half;
   --  Second_Half values at random

....

    27.    if buffer(some_val) > 10.0 then
                     |
        >>> warning: value not in range of type "First_Half" defined at line 6
        >>> warning: "Constraint_Error" will be raised at run time

Alan Balmer wrote:

> That seems obvious. It's possible to write a C program with *no*
> residual errors. It may be easier to write a SPARK program with no
> residual errors, but there's no law that says C programs have to have
> more errors.

But is it possible to write a C program and an Ada program which 
implement the same algorithm with no residual errors?

My experience indicates that it is not.  This is not saying that you 
can't build an Ada to C translator, or a C to Ada translator, although 
the first has been done several times, and the second would be much 
harder.  The problem is that if I have a C program "in hand" and go to 
translate it into Ada, there are usually hundreds of questions that I 
end up asking.  Some of them may be answered in the specificiation for 
the C program--assuming that such a specification exists.

The net result is that even if I start out to write identical programs 
in C and Ada, the Ada program ends up much more tightly specified. 
Whether these additional specifications are meaningful in terms of the 
intent of the program, or are just "accidental" overspecification due to 
the fact that Ada asks the question and it is easier to answer it than 
dodge it, the Ada and C programs implement two different specifications. 
  (Or to be formal, the set of specifications that the C program 
satisfies will normally be a superset of those satisfied by the 
"equivalent" Ada program.)

Does this make the C program better?  I don't think so.  I am much more 
concerned that set of specifications satisfied includes the "real" 
specification, which often includes requirements omitted from the 
original written specification.  Ada does a much better job of 
identifying these implicit requirements and getting them formalized.

The best example of this problem doesn't involve Ada at all.  The French 
developed a programming language used for the Airbus A320, and it took 5 
crashes for omissions in the specification to be identified and fixed.

One problem was that the autopilot would maintain a specified hight 
above ground between waypoints until the last waypoint before landing. 
Then it would put the plane into the glidepath for the destination 
runway.  The problem occurred when the last waypoint set was not in the 
glide path, the 'correction' that occurred when the waypoint was passed 
could result in a stall, or in the case of a landing in mountainous 
territory diving to the glide path which was underground at the last way 
point.

Airbus originally diagnosed the cause of the crashes as the pilots 
selecting the 'wrong' descent mode.  But as I said, it was not pilot 
error, but a missing specification.  The glide path for the runway was 
assumed to be everywhere above ground.  More correctly it was assumed 
that the last waypoint would be the outer beacon for the intended 
runway.  But there are cases where that is not possible, and in those 
cases, the A320 could be deadly. And in the crash which resulted in the 
problem being detected, the outer marker beacon was situated on a 
mountain which extended into the glide path.

As far as I am concerned Airbus's contribution to the analysis of a 
crash near Strasbourg, France January 20, 1992 was criminal.  If you 
look at all the "weasel words" in retrospect, they knew that it couldn't 
have been the pilot error they suggested.  (Autopilot in wrong mode.) 
The "rapid" descent that left one second between the altitude warning 
and the crash was at over a 50% angle over descending terrain.  Somehow 
I don't think the flight crew "overlooked" the rapid descent--other than 
looking through the cockpit window below their feet.

As it was, it took two more crashes before an investigation concluded 
that at least two previous crashes, and probably all four were due to 
missing requirements in the specifications for the provably correct 
code.  For example, in the first crash at a French airshow, a lot of 
attention was focused on whether the engines spooled up "quick enough" 
when the crew selected abort/go around.  A later crash in Japan in a 
similar situation, but a "real" landing attempt showed that engine speed 
  wasn't the problem.  The Japanese plane didn't strike trees with its 
tail: "Finally, the engine stalled after the angle of ascent increased 
to 53 degrees, and the plane fell towards the ground, crashing 
tail-first."  As any pilot can tell you trying to increase altitude in 
any flight mode, but certainly when close to the ground, pulling the 
nose much above level is a deadly error. Beyond a certain AoA (angle of 
attack) the plane will slow down requiring more AoA (or throttle) to 
stay level. Go back and look at the first A320 crash, and it is clear 
that a human pilot would have not have increased the AoA to go around, 
and in (more) level flight the tail would not have hit the trees.

Sorry to spend so many electrons and photons on this, but it is an issue 
that should not be overlooked.  Formal proofs of correctness are 
worthless if the requirements are not complete.  I like a language that 
asks the questions that the specification forgot.
-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

James Rogers wrote:
> 
.... snip ...
> 
> When reliability engineers encounter a system relying upon human
> actions the commonly accepted error rate, assuming properly trained
> humans, is 1 in 1000. Such an error rate is unacceptably low for
> most safety critical systems. An error rate of 1 in 1000 is a
> reliability rate of 0.999. Safety critical systems commonly
> require reliability rates on the order of 0.999999. This is
> three orders of magnitude higher than can be achieved through
> reliance on human correctness.

And even then, 1000 such 6 nines reliable systems together can be
expected to have a combined reliability of 0.999.  Now consider
the count of individual transistors in a moderately complex
processor.

There are two basic methods of improving the end product
reliability:  Improve the component reliability, and reduce the
number of components.  This argues heavily against using a Pentium
when a PIC will do.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"Robert I. Eachus" <rieachus@comcast.net> writes:

> Stephen Leake wrote:
> 
> > The version of Ada most likely to run on 8 bit machines would have no
> > tasking, no exceptions, and possibly no floating or fixed point, or
> > dynamic dispatching. That would still be a far better language than C!
> > Packages, generics, strong typing in general, aggregates,
> > representation clauses; none of these make demands on the run-time
> > environment, but all are very powerful programming language features.
> 
> Actually, there is no reason not to support fixed-point, although I
> probably wouldn't support decimal types.  There is no reason to omit
> exceptions, but I might not support exception occurances (RM 11.4.1).

I was quoting the restrictions imposed by GNAT's undocumented 'pragma
No_Runtime', which is admittedly serving a somewhat different purpose.

The runtime support for fixed point is simple, but it is not zero.
Same for exceptions. Runtime support for "zero cost" exceptions is
more complex.

> And again there is no reason not to support dynamic dispatching, 

I don't know if pragma No_Runtime eliminates this; I never tried it
(since it's undocumented, the only way to discover if a feature is
prevented is to try it. Well, one could read the source.).

> <snip>
> Having said all that, I can't really get excited about validating Ada
> compilers for the i8051 or for that matter the Z-80.  Every time I
> have used a chip that "small" on a project, complete test coverage of
> the machine code was not that hard to do.  Typically the chip
> implements a finite-state machine with at most a couple of dozen
> states, and it is easier to tie the generated code to the state
> diagram in the specification than to prove both the source code and
> the compiler.

Right. That's the approach I would take; test the application code
thoroughly, so you find any compiler bugs.

-- 
-- Stephe

Chris Hills <chris@phaedsys.org> wrote in message news:<W4TqREA2bf7$EA9g@phaedsys.demon.co.uk>...
> In article <wp6gcQns6pRu@eisner.encompasserve.org>, Larry Kilgallen
> <Kilgallen@SpamCop.net> writes
> >In article <z+se8hAfAb7$EAYZ@phaedsys.demon.co.uk>, Chris Hills 
> ><chris@phaedsys.org> writes:
> >
> >> We are in comp.arch.embedded...... Ms Desktop tools are not relevant.
> >
> >Some of us are in comp.lang.ada.
> 
> Repent!

How do you think I got *into* comp.lang.ada?!

> :-)

Me too!

Mike Silva wrote:
[snip]
>>>
>>>http://www.sparkada.com/downloads/Mar2002Amey.pdf
>>
>>An interesting article, though not for the residual error reduction
>>references, which are simply quotes of claims made by Lockheed, with
>>no background. 
> 
> 
> Just to clarify, the error reduction claims I was referring to were
> those cited from a UK MoD study done by Aerosystems International. 
> I'd like to be able to find that study, or a fuller summary, on line.
> 
> Mike

The study was only fully reported at a private MoD briefing.  The 
nearest thing to a public version is in a recent article by Andy German 
(of Qinetiq) in a recent issue of Crosstalk.  The Andy German paper 
covers experiencess of static analysis of a large number of air systems 
and shows similar (but not quite so extreme) trends to the C130J figures.

Peter

I would much rather concentrate on technical issues here (for example, 
why deep static analysis of _any_ general-purpose langauge is 
impossible; or, why systems of integrities in the better-than 10e-6 
failures per hour class _require_ deep static analysis); however, I 
can't let Chris Hill's petulent little rant below pass unchallenged!

Chris Hills wrote:
> In article <20619edc.0312222106.3b369547@posting.google.com>, Mike Silva
> <snarflemike@yahoo.com> writes
> 
>>Some more interesting reading (note that MISRA acknowledges that there
>>are better languages than C for safety-critical work):
> 
> 
> That will change. 
> 
> 
>>http://www.sparkada.com/downloads/misracatsil4reader.pdf
> 
> 
> Praxis has a vested interest in not letting C be used for SIL 4

Praxis has a long-held commitment to using the best technology available 
and to advancing the state of the software industry as a whole.  Our 
objection to using C for SIL 4 is that it is unsuited to that task.  The 
majority of the proponents of the use of C in this role are C tool 
vendors; are they too governed only by vested interest?

> 
> BTW 
> slide 3 is erroneous.
> slide 5 is also erroneous.
> 

> AFAIK Praxis are not "involved" with MISRA-C they may have been some
> years ago in the original version but much work has been done since
> then. AFAIK they have not taken much, if any part, in this.
> 

Neither slide is erroneous. They are clearly dated 2002 and are factually
correct for that date.  We had two members on the original MISRA-C 
committee
and attended every workshop and committee meeting until the beginning of
this year.  We still monitor the mailing list and will contribute again 
when
we have something to say.

> AFAIK they did not make their SPADE C results available to the MISRA-C
> working group who for the last 3 years have been working on MISRA-C2.

Wrong.  We did.  Unfortunately the rather stern view we took of what was 
needed to make C fully-analyseable (basically, a Pascal subset in C 
syntax) was not seen as being compatible with the apparent aim of the 
comittee: as much C as possible with the minimal restrictions needed to 
plug the biggest holes.

> 
> Praxis don't have a unique view of MISRA-C.  They are one of many who
> were involved in MISRA-C1. They are not one of the main companies who
> were promoting and working with it in the last 5 years.

The slide clearly states that this is Rod's personal view and he (with 
appalling semantics) qualifies the "unique" with "almost".  I think is 
is at least defensible to say that Praxis's experience as: implementors 
of world class critical systems, language designers; and tool vendors 
_does_ give us a different (even unique) perspective from most other 
contributors none of which (AFAIK) has done _all_ of these things.

> 
> Slide 6 is interesting. The quotes are out of context and misleading.
> The Praxis presentation is clearly written with a (commercial) axe to
> grind. I was at the MISRA-C 2002 forum. In fact I did one of the
> presentations that has been misquoted.... 

Perhaps you can recall the context in which Less Hatton's shack/swamp 
comment can be interpreted in a positive way?

> 
> As it goes on they rubbish C and surprise surprise come up with a
> solution that is their tools.... :-) 

We don't rubbish C.  We rubbish magic where logic is to be preferred. 
We have well-articulated reasons for saying that C is not well suited 
for constructing high-integrity systems.  The proponents of C for this 
purpose never seem to present their reasons.  All we ever hear are: 
"there are lots of C programmers around"; "we only ever employ the best 
people and they don't make those kinds of mistakes"; and, the falsehood, 
"C, with suitable support tools, is as good as anything else".

We don't take this view because we have alternative tools, we have 
alternative tools because we take this view!

> 
> The Ada (tools) community must be rattled if it needs to spend time
> trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
> longer push a MISRA-C tool? 

Again we are not trying to rubbish MISRA-C.  We continue to believe that 
  it is useful enterprise.  If people want to use C for smaller, 
safety-related systems then having a widely-supported coding standard is 
a "good thing".  We will continue to rubbish the promotion of that 
coding standard to application domains for which it unsuitable.

We no longer promote a MISRA-C tool because the widely-differing 
behaviour of our and competing tools and the high level of ambiguity in 
the MISRA-C rules showed that the market was too immature for tools 
claiming to enforce MISRA-C compliance.  We preferred, in that 
situation, to say nothing rather than make claims that could not be 
defended by logic and by reasoned argument.  I hope that MISRA-C2 will 
be  better; however, my long experience of designing unambiguous and 
analyseable programming languages leads me to believe that it won't.

> 
> Since the 2002 meeting MISRA-C2 has been reviewed by the SAE and JSAE
> several major automotive companies, aerospace companies, also  members
> of WG14 the ISO-C panel and met with approval. MISRA-C2 will be
> available at the end of Q1 2004
> 
> 
> 
>>This document has a table of language recommendations (search for
>>"Language Recommendations (IEC 1508)" ).  C is only recommended for
>>SIL1, while it is not recommended for SIL3 and SIL4:
>>
>>https://www.cis.strath.ac.uk/teaching/ug/classes/52.422/programming.languages.do
> 
> 
> Yet  C is used in some of the highest integrity systems around. Other
> languages that are recommended hardly exist and certainly not on many
> platforms.
> 
> Empirical evidence and a glance at 61508 may require a change in the
> table D2.... BTW table D2 in the lecturers notes is NOT in 61598.
> 
> In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
> copy of 61508, all 7 parts. We find a similar table to "D2" above:
> 
>             Sil1   Sil2   Sil3 Sil4
> Ada          HR    HR      R    R
> ADA (subset) HR    HR      HR   HR
> C            R     -      NR    NR
> 
> as expected  BUT
> 
> C (subset, codinng standard and static analysis) 
>              HR   HR      HR     HR
> 
> 
> So whilst straight ADA *is* better than vanilla C. No one would debate
> that!  Spark ADA is no better than C with a subset, coding standard and
> using static analysis....  IE much the same constraints as SPARK ADA has
> over ADA...

Fundamental misconception.  SPARK is wholly unambiguous and therefore 
analyseable in a formal and mathematical sense.  An un-annotated subset 
of C _cannot_ have this property.  Analysis of such a language can, 
therefore, ony result in the _detection_ of certain kinds of error, it 
cannot _prove_ that they have been eliminated.

> 
> I know of projects using C in Railway, space, aero and medical projects.

Use, even widespread use, does not imply suitability.

> 
> PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
> for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
> 

Agreed.  Modula-2, in particular, was a nice language from which a 
secure, SPARK-like sublanguage could have been constructed.  Pity it, 
unlike Ada, never achieved critical mass.

> I come back to my comment previously that the ADA tools vendors must be
> worried if they are spending this much effort trying to rubbish MISRA-C
> which is an automotive guide.  Though it has gained widespread use
> outside the automotive industry due to those involved with it.
> 

I have pooh-poohed this pooh-poohing enough already!

> 
> Regards
>         Chris
> 

have a Happy New Year


Peter

In article <bsm4hq$ea20f$1@ID-69815.news.uni-berlin.de>, Peter Amey
<peter.amey@praxis-cs.co.uk> writes
>
>
>Mike Silva wrote:
>[snip]
>>>>
>>>>http://www.sparkada.com/downloads/Mar2002Amey.pdf
>>>
>>>An interesting article, though not for the residual error reduction
>>>references, which are simply quotes of claims made by Lockheed, with
>>>no background. 
>> 
>> 
>> Just to clarify, the error reduction claims I was referring to were
>> those cited from a UK MoD study done by Aerosystems International. 
>> I'd like to be able to find that study, or a fuller summary, on line.
>> 
>> Mike
>
>The study was only fully reported at a private MoD briefing.  The 
>nearest thing to a public version is in a recent article by Andy German 
>(of Qinetiq) in a recent issue of Crosstalk.  The Andy German paper 
>covers experiencess of static analysis of a large number of air systems 
>and shows similar (but not quite so extreme) trends to the C130J figures.
>
>Peter
>
Hi Peter,

I have just downloaded your paper. Interesting and well worth reading. 

Regards
        Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <bsmagl$e5ajv$1@ID-69815.news.uni-berlin.de>, Peter Amey
<peter.amey@praxis-cs.co.uk> writes
>
>I would much rather concentrate on technical issues here 
OK

>(for example, 
>why deep static analysis of _any_ general-purpose langauge is 
>impossible; 

Interesting.... can you explain? Perhaps as a separate thread? 

>or, why systems of integrities in the better-than 10e-6 
>failures per hour class _require_ deep static analysis); 

Is that a contradiction or do you mean that you need static analysis but
it can never be 100%? 

>> Praxis has a vested interest in not letting C be used for SIL 4
>
>Praxis has a long-held commitment to using the best technology available 
>and to advancing the state of the software industry as a whole. 
That's got to be from the marketing dept :-)


> Our 
>objection to using C for SIL 4 is that it is unsuited to that task.
On its own I would agree. 

>  The 
>majority of the proponents of the use of C in this role are C tool 
>vendors; are they too governed only by vested interest?

Good point. However you could argue the same for Ada hence the
development of Spark Ada. I think that all that is happening is that
there is (thank god) a realisation that unfettered C *IS* dangerous and
it should be used with various tools not least a static analyser. Who
would buy a word processor these days that does not have a spell
chequer?

>> AFAIK Praxis are not "involved" with MISRA-C they may have been some
>> years ago in the original version but much work has been done since
>> then. AFAIK they have not taken much, if any part, in this.
>Neither slide is erroneous. They are clearly dated 2002 and are factually
>correct for that date.  We had two members on the original MISRA-C 
>committee
The original committee stopped along while ago. 

>and attended every workshop and committee meeting until the beginning of
>this year.  
>We still monitor the mailing list and will contribute again 
>when
>we have something to say.

That explains why I have not seen any one from Praxis in the last year
or two. 


>> AFAIK they did not make their SPADE C results available to the MISRA-C
>> working group who for the last 3 years have been working on MISRA-C2.
>
>Wrong.  We did. 

Can you send it to me? It would be useful to go over it (again?) before
we lock down C2

> Unfortunately the rather stern view we took of what was 
>needed to make C fully-analyseable (basically, a Pascal subset in C 
>syntax) was not seen as being compatible with the apparent aim of the 
>comittee: as much C as possible with the minimal restrictions needed to 
>plug the biggest holes.

Yes. We have to work with the language we have.  Also the view was taken
(generally) that if we went from C to (almost) Pascal in one go we would
loose the audience.  MISRA-C1 was so successful because it was user
friendly. A LOT of companies are using it. Their C has improved....
MISRA-C2 is a step further. Hopefully all the current MISRA users will
move to it.  MISRA-C3 will be another step forward.

You don't run a marathon by running 26 miles on day one of training.

>> Praxis don't have a unique view of MISRA-C.  They are one of many who
>> were involved in MISRA-C1. They are not one of the main companies who
>> were promoting and working with it in the last 5 years.
>
>The slide clearly states that this is Rod's personal view and he (with 
>appalling semantics)

Whereas mine English is perrfek :-) 

> qualifies the "unique" with "almost".  I think is 
>is at least defensible to say that Praxis's experience as: implementors 
>of world class critical systems, language designers; and tool vendors 
>_does_ give us a different (even unique) perspective from most other 
>contributors none of which (AFAIK) has done _all_ of these things.

OK. Though there are others involved who would argue their corner...  IT
would make a fun discussion over a bottle of scotch one night but
probably not for public consumption.


>> Slide 6 is interesting. The quotes are out of context and misleading.
>> The Praxis presentation is clearly written with a (commercial) axe to
>> grind. I was at the MISRA-C 2002 forum. In fact I did one of the
>> presentations that has been misquoted.... 
>
>Perhaps you can recall the context in which Less Hatton's shack/swamp 
>comment can be interpreted in a positive way?

:-) 
I think he referring to C99  he has used that analogy at several ISO C
meetings. This is why  we are still working with C90 at the moment. 

>> As it goes on they rubbish C and surprise surprise come up with a
>> solution that is their tools.... :-) 
>
>We don't rubbish C.  We rubbish magic where logic is to be preferred. 
>We have well-articulated reasons for saying that C is not well suited 
>for constructing high-integrity systems.  The proponents of C for this 
>purpose never seem to present their reasons.  All we ever hear are: 
>"there are lots of C programmers around"; "we only ever employ the best 
>people and they don't make those kinds of mistakes"; and, the falsehood, 
>"C, with suitable support tools, is as good as anything else".
>
>We don't take this view because we have alternative tools, we have 
>alternative tools because we take this view!

Logical. I think part of the problem is that Ada is usually (always?)
taught in a high integrity context.  C is usually taught is an appalling
way.

I have had one lecturer tell me he taught C but used cin and cout in
strad of print and scanf as they were too difficult and anyway C was
simply a sub-set of C++....  (another candidate for a thread of it's own
:-)

>> The Ada (tools) community must be rattled if it needs to spend time
>> trying to rubbish MISRA-C. Perhaps it is just sour grapes as they no
>> longer push a MISRA-C tool? 
>
>Again we are not trying to rubbish MISRA-C.  We continue to believe that 
> it is useful enterprise.

Yes if they must use C at least we can improve the usage.

>  If people want to use C for smaller, 
>safety-related systems then having a widely-supported coding standard is 
>a "good thing".  We will continue to rubbish the promotion of that 
>coding standard to application domains for which it unsuitable.

Fair enough. 

>We no longer promote a MISRA-C tool because the widely-differing 
>behaviour of our and competing tools and the high level of ambiguity in 
>the MISRA-C rules showed that the market was too immature for tools 
>claiming to enforce MISRA-C compliance.  

That I can't disagree with. In fact part of my presentation at the 2002
MISRA forum was the problem that there is no MISRA-C certification of
tools anyone could interpret as they saw fit and claim what they like.
SOme claimed things there were not (in my view) supportable

>We preferred, in that 
>situation, to say nothing rather than make claims that could not be 
>defended by logic and by reasoned argument.  
Yes.. things have been made a little difficult by some of the claims...
"we test 100% of MISRA"*

*That is we test 100% of the rules we thing our tool can test.... :-(

>I hope that MISRA-C2 will 
>be  better; 

Hopefully. There are a few things in the pipeline that will be announced
in Feb/March

>however, my long experience of designing unambiguous and 
>analyseable programming languages leads me to believe that it won't.

It will be better. How much better we will have to see but anything that
improves the general level of embedded C programming has to be a Good
Thing (tm) 


>> Yet  C is used in some of the highest integrity systems around. Other
>> languages that are recommended hardly exist and certainly not on many
>> platforms.
>> 
>> Empirical evidence and a glance at 61508 may require a change in the
>> table D2.... BTW table D2 in the lecturers notes is NOT in 61598.
>> 
>> In CEI/IEC 61508:1998 Part 7 Table C1 (page 79), yes I do have my own
>> copy of 61508, all 7 parts. We find a similar table to "D2" above:
>> 
>>             Sil1   Sil2   Sil3 Sil4
>> Ada          HR    HR      R    R
>> ADA (subset) HR    HR      HR   HR
>> C            R     -      NR    NR
>> 
>> as expected  BUT
>> 
>> C (subset, codinng standard and static analysis) 
>>              HR   HR      HR     HR
>> 
>> 
>> So whilst straight ADA *is* better than vanilla C. No one would debate
>> that!  Spark ADA is no better than C with a subset, coding standard and
>> using static analysis....  IE much the same constraints as SPARK ADA has
>> over ADA...
>
>Fundamental misconception.  SPARK is wholly unambiguous and therefore 
>analyseable in a formal and mathematical sense.  An un-annotated subset 
>of C _cannot_ have this property.  Analysis of such a language can, 
>therefore, ony result in the _detection_ of certain kinds of error, it 
>cannot _prove_ that they have been eliminated.

Good point. 

>> I know of projects using C in Railway, space, aero and medical projects.
>Use, even widespread use, does not imply suitability.

The point was that C has been used successfully in these areas. At one
time it was said no HLL could be used in these areas. 


>> PASCAL and Mod2 are mentioned but you will be hard pressed to find tool
>> for these for many targets. BTW is there ADA for the PIC, AVR and 8015?
>Agreed.  Modula-2, in particular, was a nice language from which a 
>secure, SPARK-like sublanguage could have been constructed.  Pity it, 
>unlike Ada, never achieved critical mass.

I was once asked to set up a Modula2 system... in theory the language
was good but I discovered that the compiler had been written in x86
assembler, there was a most of a user manual but when I contacted the
company that wrote the compiler the programmer had left and they had no
design documentation, notes or bug fixes. No evidence of any testing
etc. 

In theory the language was good but the tools we had were not safe.

>I have pooh-poohed this pooh-poohing enough already!

Cue the Black Adder Goes Forth* sketch in what happens when you don't
pooh-pooh the pooh-pooh... (this will require a new NG not just a new
thread)

(Forth? even he had an opinion on languages)   


>have a Happy New Year
>Peter

Happy New Year? with you waiting to analyse every line of MISRA-C2... I
shall need tranquillisers :-)

BTW Re your Correctness by Construction: Better can also be cheaper...
Interesting reading. I also use the line "better is also cheaper" when
discussing C programming 

Regards & Happy New Year

Chris


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Peter Amey wrote:
> Chris Hills wrote:
> > <snarflemike@yahoo.com> writes
> >
> >> Some more interesting reading (note that MISRA acknowledges that
> >> there are better languages than C for safety-critical work):
> >
.... snip ...
> 
> Wrong.  We did.  Unfortunately the rather stern view we took of
> what was needed to make C fully-analyseable (basically, a Pascal
> subset in C syntax) was not seen as being compatible with the
> apparent aim of the comittee: as much C as possible with the
> minimal restrictions needed to plug the biggest holes.

This may be just as well, since IMO part of the C problem is the
extreme reuse and terseness of tokens and the perverse precedence
rules.  

No language can be proof against errors, it can only supply extra
redundancy and increase the likelihood of detection at compile
time or detection at run time via appropriate checks. 
Unfortunately the latter will always require a means of
disablement, and the psychology of programmers is such that that
will be used unnecessarily.

> 
.... snip ...
> 
> We don't rubbish C.  We rubbish magic where logic is to be
> preferred. We have well-articulated reasons for saying that C is
> not well suited for constructing high-integrity systems.  The
> proponents of C for this purpose never seem to present their
> reasons.  All we ever hear are: "there are lots of C programmers
> around"; "we only ever employ the best people and they don't
> make those kinds of mistakes"; and, the falsehood, "C, with
> suitable support tools, is as good as anything else".

Again, I consider splint annotatated C to be another language,
with an even more unnatural syntax.  Also, the best people DO make
those kinds of mistakes, and I present myself as evidence. 
Unfortunately many of the best programmers are somewhat sot in
their ways, and will reach for the C system as opposed to learning
an Ada or Pascal system, just as not too long ago they reached for
the assembler rather than learn Fortran, PL/I, Pascal, or C. 
Availability also has a hand in here.

I consider the ideal mixture for embedded systems to be a
combination of assembly, C, and Pascal.  The result can be trimmed
down to the abilities of highly incapable hardware, and yet can be
made mutually compatible.  I think (and I am willing to be
corrected) that Ada cannot be trimmed substantially and still be
Ada, and even if it can the extra verbiage will deter users.  

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On Sun, 28 Dec 2003 15:51:57 GMT, CBFalconer <cbfalconer@yahoo.com> wrote:


> I consider the ideal mixture for embedded systems to be a
> combination of assembly, C, and Pascal.  The result can be trimmed
> down to the abilities of highly incapable hardware, and yet can be
> made mutually compatible.  I think (and I am willing to be
> corrected) that Ada cannot be trimmed substantially and still be
> Ada, and even if it can the extra verbiage will deter users.
>

I think the subset of Ada used by SPARK is a good counter-example.  It's 
not the only one in use, since Ada provides pragmas that restrict 
functionality to achieve a higher level of determinism, or to 
reduce/remove the need for runtime library support.

- Ed

In article <1563361.SfB03k3vvC@linux1.krischik.com>, Martin Krischik
<krischik@users.sourceforge.net> writes
>Hyman Rosen wrote:
>and how will you do it in C?
>
>Use an unsigned short int. Well an short int is usualy 16 bit not 8.
>
>Use an unsigned char? Well it is 8 bit - but is is a character not a number.

[plain] char is a character
singed and unsigned char are integer types.

>If you are lucky you have real C99 compiler with byte. 

there are no C99 compilers bar the (apparently) the Tasking Tricore
compiler.




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <chris@phaedsys.org> wrote in message
news:GawT1aBurv7$EA8G@phaedsys.demon.co.uk...
> In article <bsmagl$e5ajv$1@ID-69815.news.uni-berlin.de>, Peter Amey
> <peter.amey@praxis-cs.co.uk> writes
> >(for example,
> >why deep static analysis of _any_ general-purpose langauge is
> >impossible;
>
> Interesting.... can you explain? Perhaps as a separate thread?

Rice's theorem states this.  It is a result of the undecidablility of the
Halting problem, and it is also related to Godel's incompleteness theorem.
I would suggest taking a class on computation theory, but it might suffice
to read a book on computation theory and work through the problems.

> >or, why systems of integrities in the better-than 10e-6
> >failures per hour class _require_ deep static analysis);
>
> Is that a contradiction or do you mean that you need static analysis but
> it can never be 100%?

No it isn't a contradiction.  SPARK is not a general purpose language; it is
a special purpose language (SPARK is not Turing-Complete hence Rice's
theorem doesn't apply to it), which is designed to facilitate deep static
analysis.

Georg Bauhaus wrote:

> In comp.lang.ada Ian Bell <ian@ruffrecordsdotworldonline.co.uk> wrote:
> :> You mean as in
> :> 
> :>   type my_index is range 0 .. some_variable;
> :> 
> :> -- yes, Ada compilers will perform the check.
> :> 
> : 
> : That was not what I had in mind and seems to me to be rather dodgy code.
> :  i was thinking more of the return value of some function being used as
> : an index to the array.
> 
> That should depend on what the compiler can find out about the
> function.  For example, if there is "type Index is range 0..359;",
> then if a function is specified to return values of a constrained
> subtype of Index ranging from 0..179, and a buffer has been allocated for
> some Index subtype's values ranging from 180..359, the compiler will
> warn if you use the function's values as indices to the array,
> _although_ in C terms the array index values and the function return
> values are indistinguishable (both unsigned shorts for example).

So are you basically saying that Ada requires the function return type to be
bounded and can simply check this against the array bound?

Ian

Ed Falis wrote:

> On Sat, 27 Dec 2003 17:08:43 +0000, Ian Bell
> <ian@ruffrecordsDOTworldonline.co.uk> wrote:
> 
>> That was not what I had in mind and seems to me to be rather dodgy
>> code.  i
>> was thinking more of the return value of some function being used as an
>> index to the array.
> 
> Ian,
> 
> Depends on the relationship of the subtype of the function result to that
> of the index type of the array.
> 
> If they're of the same subtype, or of subtypes derived from the same type
> ("compatible"), and have the same range, the indexing operation will work
> because an out of range value would have raised an exception before the
> function result returned.
> 
> If the subtypes are derived from the same type, but have different ranges,
> a runtime check is performed to make sure the function result is within
> the stated index range.

Ah, so there are run time checks too.  I had not realised this.  What
happens when the check fails and what is the code overhead introduced by
the check?

Ian

CBFalconer wrote:

> James Rogers wrote:
>> 
> ... snip ...
>> 
>> When reliability engineers encounter a system relying upon human
>> actions the commonly accepted error rate, assuming properly trained
>> humans, is 1 in 1000. Such an error rate is unacceptably low for
>> most safety critical systems. An error rate of 1 in 1000 is a
>> reliability rate of 0.999. Safety critical systems commonly
>> require reliability rates on the order of 0.999999. This is
>> three orders of magnitude higher than can be achieved through
>> reliance on human correctness.
> 
> And even then, 1000 such 6 nines reliable systems together can be
> expected to have a combined reliability of 0.999.  Now consider
> the count of individual transistors in a moderately complex
> processor.
> 
> There are two basic methods of improving the end product
> reliability:  Improve the component reliability, and reduce the
> number of components.  This argues heavily against using a Pentium
> when a PIC will do.
> 

Interesting argument but a potentialy flawed example.  First one pentium and
one pic are each one component so no reduction in components. More
importantly, though a Pentium may have more transistors in it than a PIC
and hence might be seen as more complex, it is not necessarily less
reliable.  Indeed given the relatives quantities manufactured the pentium
might well be much more reliable than the PIC.

Ian

Ian Bell <ian@ruffrecordsDOTworldonline.co.uk> wrote in
news:3fef5f9b_2@mk-nntp-1.news.uk.worldonline.com: 

> 
> So are you basically saying that Ada requires the function return type
> to be bounded and can simply check this against the array bound?

Close. Ada requires the function return type to match the array index type.
Ada type matching is much more rigorous than C type matching.

Examples:

type my_index is range 1..10;
type beauty_scale is range 1..10;

type my_nums is array(my_index) of integer;

foo : my_nums;

function rand_index return my_index;
function rand_beauty return beauty_scale;


I have defined two distinct integer types above. The type my_index
is not synonymous with the type beauty_scale. Ada provides NO implicit
conversion between the two types. This is what Ada strong typing gives
us, a strong separation of data types.

It is valid to make the following call:

foo(rand_index) := 32;

This is valid because the function rand_index always returns a value
of type my_index, which is also the index type for the foo variable.

It is invalid to make the following call:

foo(rand_beauty) := 32;

This is invalid because the function beauty_index always returns
a value of beauty_scale, while the index type for the foo variable is
my_index.

This error is detected by the compiler.

I am sure you have already noticed that the range of values for both
types are identical. For Ada this structural equivalence is meaningless.
Different types are simply not implicitly converted. The Ada type model
is based upon the type name, not the type structure.

Jim Rogers

Chad R. Meiners wrote:

> Rice's theorem states this.  It is a result of the undecidablility of the
> Halting problem, and it is also related to Godel's incompleteness theorem.
> I would suggest taking a class on computation theory, but it might suffice
> to read a book on computation theory and work through the problems.
....
> No it isn't a contradiction.  SPARK is not a general purpose language; it is
> a special purpose language (SPARK is not Turing-Complete hence Rice's
> theorem doesn't apply to it), which is designed to facilitate deep static
> analysis.

True in practice, and also in theory due to limits on memory sizes.  But 
if you were to write a SPARK program that was an interpreter for a 
general purpose language, verification would only result in proving that 
the interpreter worked correct and say nothing about programs in the 
interpreted language.

Not how you would use SPARK in any case, but it is worth remembering. 
Just as I can write Ada programs that are not SPARK programs but can 
statically proven to halt, or I can write an Ada program for which no 
such proof is possible.  SPARK just provides a convenient way to write 
programs that can be proven correct, and to automate much of the proof.

In C it is much, much harder to write programs that can be proven 
correct, but it can be done.  One way is with an Ada to C translator. If 
I had to produce a large safety-critical system for a chip which did not 
have an Ada compiler, using an Ada to C translator (several exist) and 
the SPARK tools might be a decent alternative to an Ada port.

In practice for the small programs that are common on 8-bit chips, I 
find it easier to validate the generated code to the original requirements.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Ian Bell wrote:

> So are you basically saying that Ada requires the function return type to be
> bounded and can simply check this against the array bound?

No. He is saying that Ada types and subtypes typically contain 
information about expected values that will be checked at compile time 
or run time as appropriate.

If the subtypes "statically match", which does not mean that the bounds 
are static, it can be determined at compile time that no run-time check 
will be necessary.  And of course, that means you don't have to worry 
about what happens if the check fails.  In fact, years ago in Ada 83, I 
had a nice tool that detected every place that a run-time bound was 
tested by the compiler.  About one-third of the cases were cases where 
rearranging the code would allow the compiler to eliminate the check, 
one-third were really needed, and the rest were bugs.  Today I use the 
SPARK analyzer or other (ASIS) tools to do essentially the same checking.

You are not required to use subtypes which are correctly bounded in Ada. 
But it is a big help to (static) debugging and program correctness if 
you do.  And in another thread on comp.lang.ada we are discussing that 
it is a VERY useful property of Ada, not just because it makes it more 
likely that the program will correctly implement the requirements.  It 
also often results in missed requirements being detected.

I have lost track of the number of times when a "simple question" about 
the right way to declare a subtype or assign a default value in Ada, has 
gone back to the design team to write a new requirement, as soon as they 
figured out what it should be.

My favorite example of this came from a project which was doing a flight 
control system for a fighter aircraft.  They wanted to know if it was 
possible to implement the system as a round-robin scheduler in Ada.  I 
sent back a template of what the final code would look like, and a set 
of questions that needed to be answered before the code could be 
written--or the question answered.  A month or so later I called back 
and asked whether that had solved their problem.  The answer was that 
they had resolved fifteen of the seventeen questions I had asked and 
they only had two left!

Eventually, they used hard-deadline scheduling because that way they 
could resolve the remaining questions.  Notice that the questions in one 
sense had nothing to do with Ada.  Ada had made the need for answers 
obvious, but the questions could be stated in terms that were actually 
independent of programming language and hardware.

"If the tracking of incoming missles exceeds its time slot should it be 
aborted or allowed to delay the navigation function?"

"If the aircraft state update takes longer than expected--read time-outs 
on status inquiries due to damage--should it restart where it left off 
in the next time-slot, continue execution at low-priority, or reset to 
the beginning for the next time slot but skip the failed check?"

These are not easy questions, and there may be no "right" answer in the 
sense of one that will always save the aircraft.  But choosing the best 
answer may save some aircraft that would otherwise be lost.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Ian Bell wrote:
> CBFalconer wrote:
> > James Rogers wrote:
> >>
> > ... snip ...
> >>
> >> When reliability engineers encounter a system relying upon human
> >> actions the commonly accepted error rate, assuming properly trained
> >> humans, is 1 in 1000. Such an error rate is unacceptably low for
> >> most safety critical systems. An error rate of 1 in 1000 is a
> >> reliability rate of 0.999. Safety critical systems commonly
> >> require reliability rates on the order of 0.999999. This is
> >> three orders of magnitude higher than can be achieved through
> >> reliance on human correctness.
> >
> > And even then, 1000 such 6 nines reliable systems together can be
> > expected to have a combined reliability of 0.999.  Now consider
> > the count of individual transistors in a moderately complex
> > processor.
> >
> > There are two basic methods of improving the end product
> > reliability:  Improve the component reliability, and reduce the
> > number of components.  This argues heavily against using a
> > Pentium when a PIC will do.
> 
> Interesting argument but a potentialy flawed example.  First one
> pentium and one pic are each one component so no reduction in
> components. More importantly, though a Pentium may have more
> transistors in it than a PIC and hence might be seen as more
> complex, it is not necessarily less reliable.  Indeed given the
> relatives quantities manufactured the pentium might well be much
> more reliable than the PIC.

I disagree.  The basic components may have different reliability
figures, but both chips are made up of various implantations,
etchings, and aluminum layers, which create a whole aggregate of
components of varying reliability.  In both cases the user never
gets to see the fundamentally flawed components, because of
manufacturers final test.  I daresay the percentage yield for PICs
is considerably higher than that for Pentia, and this is reflected
in the price.

You also need to consider the MTBF of components.

Contrast the up times of early vacuum tube computers, later more
complex transistor/diode machines, still later SSI (7400 gates
etc) generations, and today almost everything is lumped onto one
or two chips.  The component count keeps going up, but the dodgy
interconnects and packaging goes down.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Ian Bell wrote:
> Ed Falis wrote:
> 
.... snip ...
> >
> > If the subtypes are derived from the same type, but have
> > different ranges, a runtime check is performed to make sure the
> > function result is within the stated index range.
> 
> Ah, so there are run time checks too.  I had not realised this. 
> What happens when the check fails and what is the code overhead
> introduced by the check?

You may well have control of 'what happens' via exception throwing
and trapping.  The overhead is likely to be well under 5% IIRC, as
shown by a study in Pascal 30 or more years ago.  The point is
that with close subtyping the compiler can derive those
expressions that require checks, and suppress most pointless
checks with ease.

For example, MAX(a + b) = MAX(a) + MAX(b).  If this is suitable,
it need not be checked.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:ItOdncXDf7nrHnKiRVn-gw@comcast.com...
>
> True in practice, and also in theory due to limits on memory sizes.

I believe SPARK is a finite language.  That is you can only declare finite
data structures.  In general purpose languages you can declare infinite data
structures, which are needed to be Turing-Complete.  Most compilers (and
computers) only support subsets of general purpose programming language ;-)

> But
> if you were to write a SPARK program that was an interpreter for a
> general purpose language, verification would only result in proving that
> the interpreter worked correct and say nothing about programs in the
> interpreted language.

Well if you had some nice properties about the interpreted language then the
verification of the interpreter would imply that those program apply to the
program while they are being interpreted. I know---I am nitpicking, but I
have been trained to.

> Not how you would use SPARK in any case, but it is worth remembering.

I believe the SPARK examiner is written in SPARK. ;-)

> Just as I can write Ada programs that are not SPARK programs but can
> statically proven to halt, or I can write an Ada program for which no
> such proof is possible.  SPARK just provides a convenient way to write
> programs that can be proven correct, and to automate much of the proof.

I completely agree.  I just get excited about SPARK because it is one of the
few formal tools situated toward the end of the verify/validation chain.
For instances for a formal methods class, I used Promela and LOTOS to prove
a theorem for a safety property about a set of traffic lights for a one lane
bridge.  With SPARK I was able to able to prove that the premise of that
theorem was satisfied by the traffic controller program that I wrote.

> In C it is much, much harder to write programs that can be proven
> correct, but it can be done.

I agree.  However, directly working with proofs about programs written in C
would probably not be a process that you could pick up in a week to finish a
class project ;-)

> One way is with an Ada to C translator. If
> I had to produce a large safety-critical system for a chip which did not
> have an Ada compiler, using an Ada to C translator (several exist) and
> the SPARK tools might be a decent alternative to an Ada port.

This really isn't writing C programs to be proven correct.  It is generating
them as an intermediate representation.  Once the C code is compiled, you
can still use the practice that you suggested below.

> In practice for the small programs that are common on 8-bit chips, I
> find it easier to validate the generated code to the original
requirements.

A wise practice considering that compilers have bugs.  However, the point of
verifying that SPARK code meets validated requirements is to detect errors
sooner to simplify the later stages of development.  Hopefully once you VV
the SPARK program, your task to VV the generated code is simplified.

-CRM
To reply by email, change the "hotmail" to "yahoo".

In comp.lang.ada Robert I. Eachus <rieachus@comcast.net> wrote:
: Ian Bell wrote:
: 
:> So are you basically saying that Ada requires the function return type to be
:> bounded and can simply check this against the array bound?
: 
: No. He is saying that Ada types and subtypes typically contain 
: information about expected values that will be checked at compile time 
: or run time as appropriate.

I'll try one of Robert's ideas.
Say I do not ignore the compiler's warning that the function used
for array indexing will return values out of range for the array. I
might see that the choice of two subtypes has been inappropriate
and should be replaced with two different types. They will have
overlapping ranges but will allow the same representation in
bits. However, the program cannot be compiled any longer, using
the same buffer:

procedure p is

   type Red_Index is range 90 .. 105;
   type Light_Red_Index is range 100 .. 120;

   buffer: array(Red_Index) of Boolean;

   function some_val return Light_Red_Index is separate;

begin
   if buffer(some_val) then
      null;  -- do something here, in a more real program
   end if;
end p;

    11.    if buffer(some_val) then
                     |
        >>> expected type "Red_Index" defined at line 3
        >>> found type "Light_Red_Index" defined at line 4

That is, I might presume that color Red is not too different from
Light_Red. I might know that the number of bits used for values
in the two types will be the same (char in C terms, say).  Still the
compiler will not let me use Light_Red_Index's value 101 and
Red_Index's value 101 interchangeably.

The range check goes away when both the function and the array
use the same index type (the function is implemented to return
random values from the index type's range (because the generator
has been instantiated with that type.))  The assembly listing shows
8bit register use on i686 when the index range permits, even with
numbers ranging beyond 255 (or > 65535 for that matter).

   type Light_Red_Index is range 92_000 .. 92_200;
   for Light_Red_Index'Size use 8;

In short, convenient, checked at compile time, and efficient :-)

-- Georg

In comp.lang.ada Robert A Duff <bobduff@shell01.theworld.com> wrote:
> However, 'lint' (in the case of C) doesn't have enough information

> (Boy, I guess the spelling police will really get after you for spelling
> "Ada" wrong twice in the same sentence -- "ADa" and "ADA".  Sheesh.  ;-))

He is a LINT-user    :-|

Robert I. Eachus wrote:

[snip]
> 
> Not how you would use SPARK in any case, but it is worth remembering. 
> Just as I can write Ada programs that are not SPARK programs but can 
> statically proven to halt, or I can write an Ada program for which no 
> such proof is possible.  SPARK just provides a convenient way to write 
> programs that can be proven correct, and to automate much of the proof.
> 
> In C it is much, much harder to write programs that can be proven 
> correct, but it can be done.  One way is with an Ada to C translator. If 
> I had to produce a large safety-critical system for a chip which did not 
> have an Ada compiler, using an Ada to C translator (several exist) and 
> the SPARK tools might be a decent alternative to an Ada port.
> 

Funny you should mention that.  We are currently doing exactly this for 
an aviation project.  Tool chain is UML to SPARK to C.  Most of the 
verification activity will be done on the SPARK intermediate "design 
model".  We have found that SPARK to C translation is much easier than 
Ada to C translation.  For example, verification activities at the SPARK 
level eliminate the requirement to add run-time checks to the C (which 
is therefore very easy to compare against the SPARK source); 
furthermore, the use of SPARK laregly eliminates the need for a run-time 
library so all the C is directly traceable to user-written SPARK statements.

I have submitted a paper on this to Ada Europe.  We are also in the 
process of productising the process (probably in the form of a "generate 
C" switch for the SPARK Examiner.

regards

Peter

CBFalconer wrote:

> Ian Bell wrote:
>> CBFalconer wrote:
>> > James Rogers wrote:
>> >>
>> > ... snip ...
>> >>
>> >> When reliability engineers encounter a system relying upon human
>> >> actions the commonly accepted error rate, assuming properly trained
>> >> humans, is 1 in 1000. Such an error rate is unacceptably low for
>> >> most safety critical systems. An error rate of 1 in 1000 is a
>> >> reliability rate of 0.999. Safety critical systems commonly
>> >> require reliability rates on the order of 0.999999. This is
>> >> three orders of magnitude higher than can be achieved through
>> >> reliance on human correctness.
>> >
>> > And even then, 1000 such 6 nines reliable systems together can be
>> > expected to have a combined reliability of 0.999.  Now consider
>> > the count of individual transistors in a moderately complex
>> > processor.
>> >
>> > There are two basic methods of improving the end product
>> > reliability:  Improve the component reliability, and reduce the
>> > number of components.  This argues heavily against using a
>> > Pentium when a PIC will do.
>> 
>> Interesting argument but a potentialy flawed example.  First one
>> pentium and one pic are each one component so no reduction in
>> components. More importantly, though a Pentium may have more
>> transistors in it than a PIC and hence might be seen as more
>> complex, it is not necessarily less reliable.  Indeed given the
>> relatives quantities manufactured the pentium might well be much
>> more reliable than the PIC.
> 
> I disagree.  The basic components may have different reliability
> figures, but both chips are made up of various implantations,
> etchings, and aluminum layers, which create a whole aggregate of
> components of varying reliability.  In both cases the user never
> gets to see the fundamentally flawed components, because of
> manufacturers final test.  I daresay the percentage yield for PICs
> is considerably higher than that for Pentia, and this is reflected
> in the price.

Except yield and component reliability are not (necessarily) related. 
Furthermore, the greater volumes of pentiums manufactured means that SPC
will have identified process and product weaknesses and improved both yield
and reliability.

> 
> You also need to consider the MTBF of components.
> 
> Contrast the up times of early vacuum tube computers, later more
> complex transistor/diode machines, still later SSI (7400 gates
> etc) generations, and today almost everything is lumped onto one
> or two chips.  The component count keeps going up, but the dodgy
> interconnects and packaging goes down.
> 

Don't disagree with that at all.

ian

Georg Bauhaus wrote:

> That is, I might presume that color Red is not too different from
> Light_Red. I might know that the number of bits used for values
> in the two types will be the same (char in C terms, say).  Still the
> compiler will not let me use Light_Red_Index's value 101 and
> Red_Index's value 101 interchangeably.

Well, it would be better to say that the compiler won't let you mix 
Light_Red_Index and Red_Index implicitly.  You can always say:

if buffer(Red_Index(some_val)) then...

If the two types are represented the same, then there will be no real 
run-time cost for the conversion.  (If both Red_Index and 
Light_Red_Index were SUBtypes of Integer, then you could write:

if buffer(some_val) then... and there would be a range check associated 
with the indexing operation.  With Red_Index and Light_Red_Index as 
separate types, there will be a range check now associated with the 
conversion instead of the subscripting.  But assuming that the 
representations of the types are identical, the code should be identical.

>                                        The assembly listing shows
> 8bit register use on i686 when the index range permits, even with
> numbers ranging beyond 255 (or > 65535 for that matter).
> 
>    type Light_Red_Index is range 92_000 .. 92_200;
>    for Light_Red_Index'Size use 8;
> 
> In short, convenient, checked at compile time, and efficient :-)

Yep, and if you do a type conversion as above, the compiler will add the 
bias back in (or add the net difference if there are two different 
biases).  This means you can write your code in meaningful units and 
allow the compiler to remember and generate any conversions.  This is 
real handy when you have a sensor that for example, returns a 12-bit 
encoding of an angle.  You can write the code using units of degrees (or 
radians or grads if you want) and the compiler will convert your 
constants at compile time.  Get a new sensor with a 16-bit ADC, and all 
you have to change is the type declaration (and of course, recompile and 
test).

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Chad R. Meiners wrote:

> "Robert I. Eachus" <rieachus@comcast.net> wrote in message
> news:ItOdncXDf7nrHnKiRVn-gw@comcast.com...
> 
>>True in practice, and also in theory due to limits on memory sizes.
>  
> I believe SPARK is a finite language.  That is you can only declare finite
> data structures.  In general purpose languages you can declare infinite data
> structures, which are needed to be Turing-Complete.  Most compilers (and
> computers) only support subsets of general purpose programming language ;-)

I think we are agreeing violently. ;-)  My point is that you can use 
external (from a SPARK viewpoint) storage to make SPARK Turing-Complete. 
  For an example, consider an embedded system that includes a tape drive 
for data logging. The system as a whole is Turing Complete, given an 
operator to change tapes, but it wouldn't normally be used in that way.

So you would be able to prove that a package that used the tape drive to 
implement a stack was correct, but you couldn't validate programs that 
used the tape as an unbounded store.

Once you get into this situation, which I have run into on several 
projects you have to decide where to make the cut.  I remember one 
particular (pre-SPARK) Ada project where we validated that the program 
would not fail if it ran out of logging space, and that the amount of 
logging space available met the system spec.  We just had to live with 
the fact that the logging requirement was somewhat arbitrary.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Perhaps I should read further in the thread before replying, but I
just can't help it:

On Sat, 27 Dec 2003 05:29:44 GMT, James Rogers
<jimmaureenrogers@att.net> wrote:

[...]
>The C standard explicitly permits accessing one element beyond the end
>of an array. Neither the C compiler nor lint can determine if an array
>index is outside the bounds of the array. Ada compilers detect static
>references beyond the end of an array every time.
>
>Examples:
>
>int foo[10];
>
>int i;
>
>for(i = 0; i < 100; ++i)
>{
>   foo[i] = i;
>}
>
>Although human inspection clearly identifies the for loop indices
>to be beyond the bounds of the array, neither the C compiler nor lint
>will detect the problem. Since the problem can be clearly identified

This one's pretty easy for PC-lint.  Consider:

---begin included file---
C:\Dave>type lloop.c

void f(void)
{
    int foo[10];

    int i;

    for(i = 0; i < 100; ++i)
    {
       foo[i] = i;
    }
}

C:\Dave>lint-nt -u lloop.c
PC-lint for C/C++ (NT) Ver. 8.00n, Copyright Gimpel Software 1985-2003

--- Module:   lloop.c
                 _
       foo[i] = i;
lloop.c  10  Warning 662: Possible creation of out-of-bounds pointer
(90 beyond
    end of data) by operator '[' [Reference: file lloop.c: lines 8,
10]
lloop.c  8  Info 831: Reference cited in prior message
lloop.c  10  Info 831: Reference cited in prior message
                 _
       foo[i] = i;
lloop.c  10  Warning 661: Possible access of out-of-bounds pointer (90
beyond
    end of data) by operator '[' [Reference: file lloop.c: lines 8,
10]
lloop.c  8  Info 831: Reference cited in prior message
lloop.c  10  Info 831: Reference cited in prior message
_
}
lloop.c  12  Warning 550: Symbol 'foo' (line 4) not accessed
lloop.c  4  Info 830: Location cited in prior message

C:\Dave>
---end included file---

The "-u" option tells PC-lint to do a "unit" check, i.e., that the
referenced file is not a complete program, so it should suppress
errors like "Function f defined but not called."

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On Sun, 28 Dec 2003 16:33:05 +0000, Chris Hills <chris@phaedsys.org>
wrote:

[...]
>
>[plain] char is a character
>singed and unsigned char are integer types.

Plain character is an abomination.  It is particularly unsuited for
character data.  You can get singed.  ;-)

All three are integer types.  All three are 1 byte wide ("byte" does
not mean "8 bits").

>
>>If you are lucky you have real C99 compiler with byte. 

I'm not sure what you mean.  There's no such thing as "byte."
uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
but I fear relatively few even know it exists, let alone how to use
it...

>
>there are no C99 compilers bar the (apparently) the Tasking Tricore
>compiler.

Comeau?

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Chris Hills wrote:

> In article <1563361.SfB03k3vvC@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes
>>Hyman Rosen wrote:
>>and how will you do it in C?
>>
>>Use an unsigned short int. Well an short int is usualy 16 bit not 8.
>>
>>Use an unsigned char? Well it is 8 bit - but is is a character not a
>>number.
> 
> [plain] char is a character
> singed and unsigned char are integer types.

Your are kidding. And you realy want to use a language which can not
distinquish between a number and a character for safety-critical systems?

>>If you are lucky you have real C99 compiler with byte.

> there are no C99 compilers bar the (apparently) the Tasking Tricore
> compiler.

I does not realy speak in favour of C if in 2003 there is still no major
compiler to meet the 1999 standarts.

But then amost nobody knows the standart anyway. Even if you are prepared to
pay the $18 to actulay see it, you are hard pressed to find the place where
you can actually order it. 

The Ada standart, however, is available for all:

http://adaic.org/standards/95lrm/html/RM-TTL.html

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

"Chris Hills" <chris@phaedsys.org> wrote in message
news:11LvOkBBXw7$EAJw@phaedsys.demon.co.uk...
> [plain] char is a character
> singed and unsigned char are integer types.

"singed" char? Perhaps there is a distinction between sung and unsung chars.

"Robert I. Eachus" <rieachus@comcast.net> wrote in message
news:H_mdnevqls8nwW2iRVn-iQ@comcast.com...
> I think we are agreeing violently. ;-)  My point is that you can use
> external (from a SPARK viewpoint) storage to make SPARK Turing-Complete.
>   For an example, consider an embedded system that includes a tape drive
> for data logging. The system as a whole is Turing Complete, given an
> operator to change tapes, but it wouldn't normally be used in that way.

Yep. We are agreeing.  I was going to use the tape drive example but you
beat me to it.

> So you would be able to prove that a package that used the tape drive to
> implement a stack was correct, but you couldn't validate programs that
> used the tape as an unbounded store.
>
> Once you get into this situation, which I have run into on several
> projects you have to decide where to make the cut.  I remember one
> particular (pre-SPARK) Ada project where we validated that the program
> would not fail if it ran out of logging space, and that the amount of
> logging space available met the system spec.  We just had to live with
> the fact that the logging requirement was somewhat arbitrary.

Interesting...I had always suspected that this had to happen in practice,
but I didn't actually know how professionals (at least a set of
professionals;) reacted to these sorts of impasses.  Thank you, I bet this
bit of information will turn up useful to me sometime in the future.

-CRM

>[...]
>>The C standard explicitly permits accessing one element beyond the end

not exactly. it permits addressing one beyond the end, but not accessing
so 
	int a[10], *after = &a[10];
is OK, but
	a[10]++
isn't

The rule lets you do bounds checks on pointers, even with empty ranges.


-- 
	mac the na�f

Alex Colvin wrote:
>>>The C standard explicitly permits accessing one element beyond the end
> not exactly. it permits addressing one beyond the end, but not accessing
> so 
> 	int a[10], *after = &a[10];
> is OK, but
> 	a[10]++
> isn't
> The rule lets you do bounds checks on pointers, even with empty ranges.

And in C++, you must write
     int a[10], *after = a + 10
as &a[10] is illegal. C99 gave special dispensation to remove &*
(a[10] is rewritten as *(a+10) so &a[10] is &*(a+10) becoming (a+10))
but C++ did not, even on built-in types.

Martin Krischik wrote:

> But then amost nobody knows the standart anyway. Even if you
> are prepared to pay the $18 to actulay see it, you are hard
> pressed to find the place where you can actually order it.

Martin...

The link in my sig leads to another that'll take you directly to 
the ANSI on-line store where (for US$18) you can download it in 
PDF format. I keep mine on a business card sized CD-ROM with 
copies of Acrobat Reader and xpdf.
-- 
Morris Dovey
West Des Moines, Iowa USA
C links at http://www.iedu.com/c
Read my lips: The apple doesn't fall far from the tree.

iddw@hotmail.com (Dave Hansen) wrote in 
news:3ff0686d.528369824@News.CIS.DFN.DE:

> Perhaps I should read further in the thread before replying, but I
> just can't help it:
> 
> On Sat, 27 Dec 2003 05:29:44 GMT, James Rogers
> <jimmaureenrogers@att.net> wrote:
> 
> [...]
>>The C standard explicitly permits accessing one element beyond the end
>>of an array. Neither the C compiler nor lint can determine if an array
>>index is outside the bounds of the array. Ada compilers detect static
>>references beyond the end of an array every time.
>>
>>Examples:
>>
>>int foo[10];
>>
>>int i;
>>
>>for(i = 0; i < 100; ++i)
>>{
>>   foo[i] = i;
>>}
>>
>>Although human inspection clearly identifies the for loop indices
>>to be beyond the bounds of the array, neither the C compiler nor lint
>>will detect the problem. Since the problem can be clearly identified
> 
> This one's pretty easy for PC-lint.  Consider:
> 
> ---begin included file---
> C:\Dave>type lloop.c
> 
> void f(void)
> {
>     int foo[10];
> 
>     int i;
> 
>     for(i = 0; i < 100; ++i)
>     {
>        foo[i] = i;
>     }
> }
> 

How well does PC-lint catch the following variation:

void f(int *foo)
{
   int i;
   for(i = 0; i < 100; ++i)
   {
      foo[i] = i;
   }
}

int main(int argc, char *argv[])
{
   int bar[10];
   f(bar);
}

The abstract error is the same, yet function f has no
visibility to the size of the actual array being passed
to it. In fact, function f does not have any assurance
that its actual parameter will even point to an array.
C syntax simply does not provide the information needed
within the called function.

Compare that with the Ada syntax for dealing with arrays.

procedure main is
   type small_index is range 1..10;
   type small_array is array(small_index) of integer;
   bar : small_array;
   procedure f(foo : in out small_array) is
   begin
      for i in foo'range loop
         foo(i) := i;
      end loop;
   end f;
begin
   f(bar);
end main;

Ada arrays do not loose their bounds and indexing information
when passed to functions or procedures. Furthermore, you can
define your own array types and use those types in function and
procedure parameters. 

The Ada syntax foo'range evaluates to the ordered range of index
values for array foo. The for loop simply iterates through that
ordered range of values. The range of values is taken from the
array itself. If I were to make a small change in the for loop 
as follows:

      for i in 0..foo'last loop
         foo(i) := i;
      end loop;

The compiler would identify this as an error. The type small_array
was defined with a lowest index value of 1, not 0. 0 is not even
a valid value for the small_index type. Many compilers will identify both
errors.

Jim Rogers

Ian Bell wrote:
> CBFalconer wrote:
> > Ian Bell wrote:
> >> CBFalconer wrote:
> >> >
> >> > ... snip ...
> >> >
> >> > There are two basic methods of improving the end product
> >> > reliability:  Improve the component reliability, and reduce the
> >> > number of components.  This argues heavily against using a
> >> > Pentium when a PIC will do.
> >>
> >> Interesting argument but a potentialy flawed example.  First one
> >> pentium and one pic are each one component so no reduction in
> >> components. More importantly, though a Pentium may have more
> >> transistors in it than a PIC and hence might be seen as more
> >> complex, it is not necessarily less reliable.  Indeed given the
> >> relatives quantities manufactured the pentium might well be much
> >> more reliable than the PIC.
> >
> > I disagree.  The basic components may have different reliability
> > figures, but both chips are made up of various implantations,
> > etchings, and aluminum layers, which create a whole aggregate of
> > components of varying reliability.  In both cases the user never
> > gets to see the fundamentally flawed components, because of
> > manufacturers final test.  I daresay the percentage yield for PICs
> > is considerably higher than that for Pentia, and this is reflected
> > in the price.
> 
> Except yield and component reliability are not (necessarily)
> related. Furthermore, the greater volumes of pentiums manufactured
> means that SPC will have identified process and product weaknesses
> and improved both yield and reliability.

I seriously doubt that Pentium volume exceeds PIC volume.  A lot
of this discussion depends on how you describe a component.  A car
is a component of a fleet, while a wheel is a component of a car,
etc.  You can never measure reliability, only calculate
probabilities.  In some cases you derive these from components, in
others you use experimental sampling, in still others you rely on
educated guesswork.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Morris Dovey wrote:

> Martin Krischik wrote:
> 
>> But then amost nobody knows the standart anyway. Even if you
>> are prepared to pay the $18 to actulay see it, you are hard
>> pressed to find the place where you can actually order it.
> 
> Martin...
> 
> The link in my sig leads to another that'll take you directly to
> the ANSI on-line store where (for US$18) you can download it in
> PDF format. I keep mine on a business card sized CD-ROM with
> copies of Acrobat Reader and xpdf.

Thanks.

> --
> Morris Dovey
> West Des Moines, Iowa USA
> C links at http://www.iedu.com/c
> Read my lips: The apple doesn't fall far from the tree.

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Frank J. Lhota wrote:

> "Chris Hills" <chris@phaedsys.org> wrote in message
> news:11LvOkBBXw7$EAJw@phaedsys.demon.co.uk...
>> [plain] char is a character
>> singed and unsigned char are integer types.
> 
> "singed" char? Perhaps there is a distinction between sung and unsung
> chars.

Grin.

Well in C you can have signed char where char'Pos is range -128 .. +127 and
unsigned char where char'Pos ist 0 .. 255. One of the top 10 mistakes K&R
did. It leads to a lot of misunderstandings and signed char is only used
when Short_Short_Integer is needed.

Which is yet another example where in C you have to say "A" when realy you
want "B". How a static analysis tool will deal with this I never know. 

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Dave Hansen wrote:

> On Sun, 28 Dec 2003 16:33:05 +0000, Chris Hills <chris@phaedsys.org>
> wrote:
> 
> [...]
>>
>>[plain] char is a character
>>singed and unsigned char are integer types.
> 
> Plain character is an abomination.  It is particularly unsuited for
> character data.  You can get singed.  ;-)

Grin. But most C programmers are to lazy for to type unsigned.

> All three are integer types.  All three are 1 byte wide ("byte" does
> not mean "8 bits").

That is why Ada 'Size gives you the size in bits. No misunderstanding here. 

>>>If you are lucky you have real C99 compiler with byte.
> 
> I'm not sure what you mean.  There's no such thing as "byte."
> uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
> but I fear relatively few even know it exists, let alone how to use
> it...

You allwas learn something new. But unint_least8_t is not helpfull for
safety-critical embedded systems. You might need exaclty 8 bit.

Which brings me back to the original Question. How will you do this in C:

type Month is new Integer range 1 .. 12;
for Month'Size is 8;

Or even better:

type Display_Element is Interger range 0 .. 9;
for Display_Element'Size use 4;

type Display_Array is array (Integer range 1 .. 6) of Display_Element;
pragma Pack (Display_Array);

Display : Display_Array;
for Display'Address use 16#12_3456#;

We are talking "safety-critical embedded systems". The Plane might crash if
11 is ever stored in a Display_Element.

With Regards

Martin.
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

In article <3FF05B3C.C56C5B79@yahoo.com>, CBFalconer
<cbfalconer@yahoo.com> writes
>Ian Bell wrote:
>> CBFalconer wrote:
>> > Ian Bell wrote:
>> >> CBFalconer wrote:
>> >> >
>> >> > ... snip ...
>> >> >
>> >> > There are two basic methods of improving the end product
>> >> > reliability:  Improve the component reliability, and reduce the
>> >> > number of components.  This argues heavily against using a
>> >> > Pentium when a PIC will do.
>> >>
>> >> Interesting argument but a potentialy flawed example.  First one
>> >> pentium and one pic are each one component so no reduction in
>> >> components. More importantly, though a Pentium may have more
>> >> transistors in it than a PIC and hence might be seen as more
>> >> complex, it is not necessarily less reliable.  Indeed given the
>> >> relatives quantities manufactured the pentium might well be much
>> >> more reliable than the PIC.
>> Except yield and component reliability are not (necessarily)
>> related. Furthermore, the greater volumes of pentiums manufactured
>> means that SPC will have identified process and product weaknesses
>> and improved both yield and reliability.
>
>I seriously doubt that Pentium volume exceeds PIC volume.  

It doesn't AFAIK  the last sets of figures I saw (broadly similar from
more than one silicon vendor) the x86 class only make up around 5% of
the MUC/MCP's produced. Around 25% are 8051 types. 


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:

 >> I seriously doubt that Pentium volume exceeds PIC volume.
 >
 >
 >
 > It doesn't AFAIK  the last sets of figures I saw (broadly similar from
 > more than one silicon vendor) the x86 class only make up around 5% of
 > the MUC/MCP's produced. Around 25% are 8051 types.


Do you have a reference? Many years ago I read an article about 
microcontrollers being responsible by 95% of the market despite all the 
hype created around either Intel or AMD release of a new top 
microprocessor. I think the figure was related to market share ($$$), 
not units shipped. The former makes more sense to me as nowadays there 
are microcontrollers (from 4 to 32 bitters) in nearly every electricity 
powered stuff you may think of. If I am right, then the figures for 
units shipped are even more impressive due to cost per unit.

Regards.

Elder.

On Tue, 30 Dec 2003 11:18:55 +0100, Martin Krischik
<krischik@users.sourceforge.net> wrote:

>Dave Hansen wrote:
[...re: plain, signed, and unsigned char...]
>> All three are integer types.  All three are 1 byte wide ("byte" does
>> not mean "8 bits").
>
>That is why Ada 'Size gives you the size in bits. No misunderstanding here. 

In C, CHAR_BIT gives you the number of bits in [[un]signed] char.  It
must be >= 8.

>
>>>>If you are lucky you have real C99 compiler with byte.
>> 
>> I'm not sure what you mean.  There's no such thing as "byte."
>> uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
>> but I fear relatively few even know it exists, let alone how to use
>> it...
>
>You allwas learn something new. But unint_least8_t is not helpfull for
>safety-critical embedded systems. You might need exaclty 8 bit.

If a platform supports uint8_t (unsigned integer exactly 8 bits wide)
the compiler must provide the type.  If the platform does not support
the type, you have to choose another platform.

>
>Which brings me back to the original Question. How will you do this in C:
>
>type Month is new Integer range 1 .. 12;
>for Month'Size is 8;

You could do something like

   typedef struct month{
      value:8;
   } Month;

>
>Or even better:
>
>type Display_Element is Interger range 0 .. 9;
>for Display_Element'Size use 4;

   typedef struct display_element{
      value:4;
   } Display_Element;

>
>type Display_Array is array (Integer range 1 .. 6) of Display_Element;
>pragma Pack (Display_Array);

   typedef struct display_array{
      elt0: 4;
      elt1: 4;
      elt2: 4;
      elt3: 4;
      elt4: 4;
      elt5: 4;
   } Display_Array;

>
>Display : Display_Array;
>for Display'Address use 16#12_3456#;

   Display_Array *Display = (Display_Array *) 0x123456;

Though in no case would the ranges be enforced.  Heck, enumerations
aren't enforced in any way either:

   enum { Red, Green, Blue } color;
   int number;

   color = 42;
   number = Red;

Is perfectly fine as far as the compiler is concerned.

>We are talking "safety-critical embedded systems". The Plane might crash if
>11 is ever stored in a Display_Element.

Then don't do that.  ;-)

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Alex Colvin wrote:

>>[...]
>>>The C standard explicitly permits accessing one element beyond the end
> 
> not exactly. it permits addressing one beyond the end, but not accessing
> so
> int a[10], *after = &a[10];
> is OK, but
> a[10]++
> isn't

But the compiler won't isue an exception when you actualy do. First C does
not have exception handling (Ada has) and then it just not allowed but
almost no compiler will stop you doing it Especialy when a function call is
in between declaration and use.

> 
> The rule lets you do bounds checks on pointers, even with empty ranges.


With Regards


Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Dave Hansen wrote:

> On Tue, 30 Dec 2003 11:18:55 +0100, Martin Krischik
> <krischik@users.sourceforge.net> wrote:
> 
>>Dave Hansen wrote:
> [...re: plain, signed, and unsigned char...]
>>> All three are integer types.  All three are 1 byte wide ("byte" does
>>> not mean "8 bits").
>>
>>That is why Ada 'Size gives you the size in bits. No misunderstanding
>>here.
> 
> In C, CHAR_BIT gives you the number of bits in [[un]signed] char.  It
> must be >= 8.
> 
>>
>>>>>If you are lucky you have real C99 compiler with byte.
>>> 
>>> I'm not sure what you mean.  There's no such thing as "byte."
>>> uint8_t?  Not guaranteed to exist.  unint_least8_t?  That would work,
>>> but I fear relatively few even know it exists, let alone how to use
>>> it...
>>
>>You allwas learn something new. But unint_least8_t is not helpfull for
>>safety-critical embedded systems. You might need exaclty 8 bit.
> 
> If a platform supports uint8_t (unsigned integer exactly 8 bits wide)
> the compiler must provide the type.  If the platform does not support
> the type, you have to choose another platform.
> 
>>
>>Which brings me back to the original Question. How will you do this in C:
>>
>>type Month is new Integer range 1 .. 12;
>>for Month'Size is 8;
> 
> You could do something like
> 
>    typedef struct month{
>       value:8;
>    } Month;
> 
>>
>>Or even better:
>>
>>type Display_Element is Interger range 0 .. 9;
>>for Display_Element'Size use 4;
> 
>    typedef struct display_element{
>       value:4;
>    } Display_Element;

>>type Display_Array is array (Integer range 1 .. 6) of Display_Element;
>>pragma Pack (Display_Array);
> 
>    typedef struct display_array{
>       elt0: 4;
>       elt1: 4;
>       elt2: 4;
>       elt3: 4;
>       elt4: 4;
>       elt5: 4;
>    } Display_Array;

I had my array start at 1 not 0. In C all numbers start with 0 but in the
real world they usualy start with 1.

>>Display : Display_Array;
>>for Display'Address use 16#12_3456#;
> 
>    Display_Array *Display = (Display_Array *) 0x123456;

Display_Array *const Display = (Display_Array *) 0x123456;
 
> Though in no case would the ranges be enforced.  Heck, enumerations
> aren't enforced in any way either:
> 
>    enum { Red, Green, Blue } color;
>    int number;
> 
>    color = 42;
>    number = Red;
> 
> Is perfectly fine as far as the compiler is concerned.
> 
>>We are talking "safety-critical embedded systems". The Plane might crash
>>if 11 is ever stored in a Display_Element.
> 
> Then don't do that.  ;-)

But is it not much better if the compiler stoped you from doing that
mistake?

Anyway, all above is is just plain C and it is not at all as save as the Ada
code. Nor is it as easy to read (safety-critical software in my book should
be code reviewed). And this is just 

The claim here in the group is that by use of a static analysis tool the C
code can be made as secure as the Ada code. So let me expand my question:
How with the static analysis tool find out the the follwing might lead to
the plane crashing.

Ada:

Display (1) = 11;                --  Compiler will warn you compile time
Display (2) = Value + 2;   --  exeption if Value is greater 7

C:

Display->elt0 = 11;
Display->elt1 = Value + 2;   

This example might be over primitive but humans somtimes make this little
mistakes.


With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Martin Krischik wrote:
> I had my array start at 1 not 0. In C all numbers start with 0 but in the
> real world they usualy start with 1.

The "real world" doesn't have arrays. Only computer programs do.

In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
<krischik@users.sourceforge.net> writes
>
>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>real world they usualy start with 1.

Interesting point. Apparently 0 is the first positive integer.
Everything starts at 0. Otherwise things would start with 1 or -1  there
would be nothing (not 0) between them :-)

Zero is a valid number.

runs for cover and turns off email system :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <bshl7d$1gab$1@msunews.cl.msu.edu>, Chad R. Meiners
<crmeiners@hotmail.com> writes
>
>"Chris Hills" <chris@phaedsys.org> wrote in message
>news:fUk12TA8gB7$EA$E@phaedsys.demon.co.uk...
>> I doubt it. At least not in large enough numbers to justify it
>> especially as 61508 permits C  (subset, with coding standard and static
>> checking) to SIL-4
>>
>> In effect a SPARK-C
>
>When you says static checking, do you include static checkers that can prove
>that assertions are never volilated (within a set of assumptions)?  If so
>then your C subset with static checking might be in effect a SPARK-C.  SPARK
>supports some very nice formal verification techniques which you might be
>overlooking.

No. I was thinking about Lint initially but I am sure that some of the
better (more expensive :-) tools will test to various criteria etc and
AFAIK do what you are suggesting but I am not certain on this.  any one
using QAC or LDRA's tool like to comment?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <bebbba07.0312261939.2e6469b0@posting.google.com>, Russ
<18k11tm001@sneakemail.com> writes
>Chris Hills <chris@phaedsys.org> wrote in message news:<vUh5muAofB7$EAZb@phaedsy
>s.demon.co.uk>...
>> In article <bebbba07.0312242000.7b6f33bc@posting.google.com>, Russ 
>> >But that's just my opinion. If you want the opinions of experts at
>> >DoD, MISRA,
>> 
>> that will change in 3 months time with MISRA-C2
>> 
>> > ARINC, NASA, and CENELEC,
>>  61508 has C (with subset etc) as HR the same as Ada.
>> > check out the one-page summary I
>> >put together at http://RussP.org/Ada-recommend.pdf . Check out the
>> 
>> You will need to modify it.
>> 
>> Whilst looking though some notes I found a table  in the IEE Computing &
>> Control Engineering Journal Vol 11.1 The edition was loking at 61508 the
>> paper by R. Bell and PA Bennett.
>> 
>> The table shows failures in safety related systems  
>> 
>> 44.1%  were due to specification faults
>
>That's interesting, and I should probably look up this paper (is it
>online?). 

Yes if you are an IEE member with access to the library

>What I am getting at, in a roundabout way, is that, as you probably
>realize, "specification faults" have nothing to do with the choice of
>programming language. That's an engineering problem. 

Yes. 

>So it is as
>irrelevant to the choice of language as, say, drug abuse in the
>workplace, just to give an off-the wall example.

Judging by some of the code I have seen the two may not be unrelated :-)

> Would you argue that
>the choice of programming language is of minimal importance if half of
>the critical errors were due to drugged programmers? Of course not. So
>why are you implying that language choice is unimportant because
>engineering is important?

I was arguing that the larger problem is the engineering process rather
than which language. However (catch 22 time again) if you have a good
engineering process you are less likely to make errors and be more
meticulous because the sort of people that would set up and ruin a good
engineering process will by definition try and "do things right" 

So a good team with a good system will do a good program irrespective of
if it is C or Ada... Ie if C they would use a C subset, static analysis
coding standards, code reviews, full test plans etc...

If Ada they would use SPARK   

However a bad team using a poor engineering system is likely not to
worry too much about the rest of it. SO in that case the enforced parts
of Spark Ada probabluy would be an advantage over C

That was a generalisation!!!! I know everyone can pull up their own
exception!

The Arriane 5 rocket show the problem. Ada but from what I understand
the corners were cut on the testing due to management pressure to do
with launch windows.... Good language. "adjustments" to the system the
rocket failed.


>> 20.6 due to changes after commissioning
>Is that what we sometimes call "maintenance"? My impression is that
>Ada excels in this stage.

Maintenance is that which is done by other people after we have all
finished the design and implementation and moved on to the next
excepting project.

Ditto testing :-)

Ditto documentation :-)

>> So it's not down to the language as much as specification and
>> process.....  
>Of course it isn't. If the engineering isn't done right, the best
>programmers and software engineers in the world are unlikely to
>salvage the project.

But will get blamed for it :-(


>Are you claiming that the Arianne 5 wouldn't have failed
>catastrophically if the same bug had occurred in C code? If so, that's
>definitely interesting. I'm certainly not knowledgable enough here to
>comment, but I'm sure others on this forum are.

Definitely. C is not strongly typed. You can chuck a long into a char
and nothing will complain. So IN THIS PARTICULAR CASE an error would not
have been raised and the rocket continued..... However in the 99 similar
cases you would have wanted it to flag an error and it would not have
done so :-) 

There are many who point out that had it been written in C it would not
have lifted off anyway due to other errors that would inevtiabley been
in the system.(and the crash would not have occurred ergo C is safe :-)


>> With a good process in place and proper engineering removing the vast
>> majority of errors we start to discover the differences in languages is
>> less important. More important is how good the tools and support tools
>> for a language are. 
>
>You lost me there. As I explained above, I agree that the choice of
>language has little effect on the engineering. But the point is that
>the choice of language has a strong effect on the software design and
>development process. Isn't that what we're talking about here? If not,
>sorry, wrong number.

I was making  the point that a language, no matter how theoretically
good is only as good as the implementation of the tools to support it.
Ada has less of a problem as compilers can be validated and certified.
Not something that happens with C.

I would agree that the choice of language does have an effect on the sw
and development process. Ada AFAIk is usually taught and used in a
strong safety critical and  Enginering way.  C is often badly taught and
certainly not (usually) with any sort of Engineering or safety critical
ethos. In fact often due to it's history  quick and dirty and hacking
seem more related :-(




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <bsrn83$nk96$1@ID-217921.news.uni-berlin.de>, Elder Costa
<elder.costa@terra.com.br> writes
>
>Chris Hills wrote:
>
>>> I seriously doubt that Pentium volume exceeds PIC volume.
>>
>>
>>
>> It doesn't AFAIK  the last sets of figures I saw (broadly similar from
>> more than one silicon vendor) the x86 class only make up around 5% of
>> the MUC/MCP's produced. Around 25% are 8051 types.
>
>
>Do you have a reference? 


>Many years ago I read an article about 
>microcontrollers being responsible by 95% of the market despite all the 
>hype created around either Intel or AMD release of a new top 
>microprocessor. I think the figure was related to market share ($$$), 
>not units shipped. The former makes more sense to me as nowadays there 
>are microcontrollers (from 4 to 32 bitters) in nearly every electricity 
>powered stuff you may think of. If I am right, then the figures for 
>units shipped are even more impressive due to cost per unit.
>
>Regards.
>
>Elder.
>

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:

> In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes
>>
>>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>>real world they usualy start with 1.
> 
> Interesting point. Apparently 0 is the first positive integer.

Zero is the first natural number, positive numbers do not include zero.

> Everything starts at 0. Otherwise things would start with 1 or -1  there
> would be nothing (not 0) between them :-)

> Zero is a valid number.

All numbers are valid. What could be an "invalid" number?

> runs for cover and turns off email system :-)

Just start receiving the answer number zero! (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Hyman Rosen wrote:

> Martin Krischik wrote:
>> I had my array start at 1 not 0. In C all numbers start with 0 but in the
>> real world they usualy start with 1.
> 
> The "real world" doesn't have arrays. Only computer programs do.

The "real world" does not have numbers as well.

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

Martin Krischik wrote:
> 
.... snip ...
> 
> The claim here in the group is that by use of a static analysis
> tool the C code can be made as secure as the Ada code.

I don't think anyone knowledgeable is seriously making such a
claim.  However, nobody knowledgeable would make the claim that
assembly language is unnecessary either, and similarly C is
extremely useful as a lingua franca extending over many systems.

As has been pointed out elsethread, it is possible to translate
Ada to C, which immediately takes advantage of the de facto
portability, but gives up some compile time efficiency and
convenience.  After all, the usual function of a C compiler is to
translate a C program to assembly language, except that that
destination is not standardized.

Implementation of run-time checks may require that the C code make
extensive use of system subroutines.  It may not be possible to
use "a = b + c;" statements.  At the same time the full C library
is probably not needed, and can be heavily pruned for Ada use.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

In article <bssflk$10el5$1@ID-77047.news.uni-berlin.de>, Dmitry A.
Kazakov <mailbox@dmitry-kazakov.de> writes
>Chris Hills wrote:
>
>> In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
>> <krischik@users.sourceforge.net> writes
>>>
>>>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>>>real world they usualy start with 1.
>> 
>> Interesting point. Apparently 0 is the first positive integer.
>
>Zero is the first natural number, positive numbers do not include zero.
Is that in maths, computing or philosophy?

>> Everything starts at 0. Otherwise things would start with 1 or -1  there
>> would be nothing (not 0) between them :-)
>> Zero is a valid number.
>All numbers are valid. What could be an "invalid" number?

My phone bill :-)


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Tue, 30 Dec 2003 18:36:13 +0000, Chris Hills wrote:

> In article <bssflk$10el5$1@ID-77047.news.uni-berlin.de>, Dmitry A.
> Kazakov <mailbox@dmitry-kazakov.de> writes
>>Chris Hills wrote:
>>
>>> In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
>>> <krischik@users.sourceforge.net> writes
>>>>
>>>>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>>>>real world they usualy start with 1.
>>> 
>>> Interesting point. Apparently 0 is the first positive integer.
>>
>>Zero is the first natural number, positive numbers do not include zero.
> Is that in maths, computing or philosophy?
> 
>>> Everything starts at 0. Otherwise things would start with 1 or -1  there
>>> would be nothing (not 0) between them :-)
>>> Zero is a valid number.
>>All numbers are valid. What could be an "invalid" number?
> 
> My phone bill :-)
> 
>
GNP
Consumer Satisfaction Index
any election year stat
women's ages
etc etc ...

On Tue, 30 Dec 2003 18:08:23 +0100, Martin Krischik
<krischik@users.sourceforge.net> wrote:

>Dave Hansen wrote:
[...]
>> Then don't do that.  ;-)
>
>But is it not much better if the compiler stoped you from doing that
>mistake?

Of course.  Thus the smiley.  I freely admit that Ada does checking
that no C compiler does.  I even admit it may (may!) be a better
langauge than C (for appropriate values of "better").

But with the possible exception of the Atmel AVR (GNAT?), there is
_no_ Ada compiler for _any_ of the microprocessors I'm using today.
For me, that makes C a better language.

>
>Anyway, all above is is just plain C and it is not at all as save as the Ada
>code. Nor is it as easy to read (safety-critical software in my book should
>be code reviewed). And this is just 

No, it's not the same, it's just as close as I could get.  But
"easy-to-read" is in the eye of the reader.  I learned Pascal and
Modula-2 years ago, so Ada doesn't look too bad.  But other than the
variable declaration syntax and some of the strange precedence rules,
I find C very easy to read.

Many consider the terseness of C to be a problem or even a
disadvantage.  But sometimes it helps in comprehension.  Consider:

   int key;
   extern int get_key(void);
   extern void process(int);
   #define EXIT_KEY  'X'

   while ( (key = get_key()) != EXIT_KEY )
      process(key);

How do you do that in Ada?  

Even the canonical strcpy function is obvious and has a certain
beauty.  Perhaps you think it looks more like line noise:

   char *strcpy(char *dest, char *src)
   {
      char *retval = dest;

      while (*dest++ = *src++)
         continue;

      return retval;
   }

But it's "safe" only when used properly.

>
>The claim here in the group is that by use of a static analysis tool the C
>code can be made as secure as the Ada code. So let me expand my question:

I wouldn't make that claim.  Mine would be that the proper use of a
static analysis tool will make C code much better than if you didn't
use a static analysis tool at all.  Substituting "Ada" for "C" in the
previous statement would probably leave it true.

>How with the static analysis tool find out the the follwing might lead to
>the plane crashing.
>
>Ada:
>
>Display (1) = 11;                --  Compiler will warn you compile time
>Display (2) = Value + 2;   --  exeption if Value is greater 7

Exceptions are valuable only if handled (think Ariane 5).  How would
you handle this one?

>
>C:
>
>Display->elt0 = 11;
>Display->elt1 = Value + 2;   
>
>This example might be over primitive but humans somtimes make this little
>mistakes.

True.  But I don't think even Ada will catch them all.  And it
certainly does no better than C for e.g. sensor failures.  

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Chris Hills wrote:

> In article <1731094.1f7Irsyk1h@linux1.krischik.com>, Martin Krischik
> <krischik@users.sourceforge.net> writes

>>I had my array start at 1 not 0. In C all numbers start with 0 but in the
>>real world they usualy start with 1.
 
> Interesting point. Apparently 0 is the first positive integer.

In my Math lessons there had been the Natural Numbers "N" and the Natural
Number with 0 "N0" (0 should be subsripted). 

> Everything starts at 0.

No. Look at the next calender for examples: The day of month start with 1.
The month of year as well. Some might debate Day of Week but at least in
the bible they have been counted from 1 to 7.

Three expamples of integer ranges which do not start with 0.

> Otherwise things would start with 1 or -1  there
> would be nothing (not 0) between them :-)

Just to tease you:

type Some_Array is new array (Integer range -1 .. 1) of Some_Element;

is valid Ada code.

> Zero is a valid number.

Shure it is. But not in all cases.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Hyman Rosen wrote:
> Martin Krischik wrote:
> 
> > I had my array start at 1 not 0. In C all numbers start with 0
> > but in the real world they usualy start with 1.
> 
> The "real world" doesn't have arrays. Only computer programs do.

You live in a highly peculiar world. :-)

Martin means array indices, not numbers, IMO.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Dave Hansen wrote:
> 
.... snip ...
> 
> Many consider the terseness of C to be a problem or even a
> disadvantage.  But sometimes it helps in comprehension.  Consider:
> 
>    int key;
>    extern int get_key(void);
>    extern void process(int);
>    #define EXIT_KEY  'X'
> 
>    while ( (key = get_key()) != EXIT_KEY )
>       process(key);
> 
> How do you do that in Ada?

I won't answer that, but here is how I would do it in Pascal:

   FUNCTION nextkey(VAR keyval : char) : boolean;

      BEGIN
      keyval = get_key;
      nextkey = keyval <> EXIT_KEY;
      END;

   BEGIN
   ....
   WHILE nextkey(key) DO process(key);
   ....

I have no qualms about factoring out baby subroutines.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

CBFalconer wrote:
> You live in a highly peculiar world. :-)
> Martin means array indices, not numbers, IMO.

Counting in the real world is done in many peculiar ways.
For example, at least in the US, house numbers tend to be
even on one side of the street and odd on the other.

Counting in computer programs should be done in a way most
convenient for the programs to do their work.

On Tue, 30 Dec 2003 19:20:50 GMT, Dave Hansen <iddw@hotmail.com> wrote:

>    int key;
>    extern int get_key(void);
>    extern void process(int);
>    #define EXIT_KEY  'X'
>
>    while ( (key = get_key()) != EXIT_KEY )
>       process(key);
>
> How do you do that in Ada?
>


with Get_Key, Process;
--  Assuming appropriate declarations elsewhere

procedure Do_it is
     Key: Character;
     Exit_Key : constant Character := 'X';
begin
    loop
        Key := Get_Key;
    exit when Key = Exit_Key;
       Process (Key);
    end loop;
end Do_It;

An extra few lines.

- Ed

In article <1072806253.772580@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> Martin Krischik wrote:
>> I had my array start at 1 not 0. In C all numbers start with 0 but in the
>> real world they usualy start with 1.
> 
> The "real world" doesn't have arrays. Only computer programs do.

Cleanup in Aisle 7.

In article <1072819860.150168@master.nyc.kbcfp.com>, Hyman Rosen <hyrosen@mail.com> writes:
> CBFalconer wrote:
>> You live in a highly peculiar world. :-)
>> Martin means array indices, not numbers, IMO.
> 
> Counting in the real world is done in many peculiar ways.
> For example, at least in the US, house numbers tend to be
> even on one side of the street and odd on the other.
> 
> Counting in computer programs should be done in a way most
> convenient for the programs to do their work.

And it is, generally using binary...

Counting in the _source_ of computer programs should be done in the
way to maximize correctness of the computer-human interface.  For
the number of people who attended a Modern Western Square Dance,
that means starting at 8 (any fewer and there was no dance).

Larry Kilgallen wrote:
> Cleanup in Aisle 7.

And in many buildings, the next higher floor after 12 is 14.
In my building, the next higher floor after 14 is PH.

If anything, counting in the real world is a lot like Ada
enumeration types.

On Tue, 30 Dec 2003 21:15:46 GMT, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Dave Hansen wrote:
>> 
[...]
>>    while ( (key = get_key()) != EXIT_KEY )
>>       process(key);
>> 
>> How do you do that in Ada?
>
>I won't answer that, but here is how I would do it in Pascal:
>
>   FUNCTION nextkey(VAR keyval : char) : boolean;
>
>      BEGIN
>      keyval = get_key;
>      nextkey = keyval <> EXIT_KEY;
>      END;
>
>   BEGIN
>   ....
>   WHILE nextkey(key) DO process(key);
>   ....

I'd thought about that, but I remembered my instructors discouraging
functions with side effects.  I'm not sure why now, other than they'd
been teaching us FORTRAN the previous quarter.  Certainly after 20
years of programming in C, it seems almost second nature today.

Though one thing bugs me.  In C, nextkey would be written something
like

   int nextkey(int *key_ptr)
   {
      *key_ptr = get_key();
      return *key_ptr != EXIT_KEY;
   }

and would be called like

   while ( nextkey(&key) ) process(key);

Note the address operator at the call.  It makes it obvious (at the
point the function is used) that nextkey modifies its parameter (or at
least it _could_).  In Pascal, the only way to know that is to look at
the function definition.  In C++, the parameter is likely to be a
reference, and have the same problem (IMHO) as Pascal.

Oh, and I never did like Pascal's cutesy way of returning a value from
a function...  But that's just syntax.  Until you try to use the
function name as a temporary -- then all recursive heck breaks out.

>
>I have no qualms about factoring out baby subroutines.

Nor I.  One recent small (PIC) project has 26 function definitions
(including main).  Since most of these are called from one place
(each), the compiler is smart enough to "inline" them so that worst
case return stack usage (including interrupt) is 3.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On Tue, 30 Dec 2003 21:35:10 GMT, Ed Falis <falis@verizon.net> wrote:

>On Tue, 30 Dec 2003 19:20:50 GMT, Dave Hansen <iddw@hotmail.com> wrote:
[...]
>>    while ( (key = get_key()) != EXIT_KEY )
>>       process(key);
>>
>> How do you do that in Ada?
>>
>
>
>with Get_Key, Process;
>--  Assuming appropriate declarations elsewhere
>
>procedure Do_it is
>     Key: Character;
>     Exit_Key : constant Character := 'X';
>begin
>    loop
>        Key := Get_Key;
>    exit when Key = Exit_Key;
>       Process (Key);
>    end loop;
>end Do_It;

Thanks.  It was a serious question.  I did want to know.

Though structurally, this reminds me of

   while (1)  /* or for (;;) if you like obscure syntax */
   {
      key = get_key();
      if (key == EXIT_KEY) break;
      process(key);
   }

which tends to be discouraged.

Another question:  Note that in C, even though get_key takes no
parameters, it is called with empty parentheses, while Get_Key in Ada
looks (syntactically) like any other variable.  ISTR that in Modula-2,
a function that takes no paramters could be called either way (with or
without empty parentheses).  Is this true in Ada?  FWIW, I like the
empty parens because they signal to the reader that something special
is going on.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Hyman Rosen wrote:

> CBFalconer wrote:
>> You live in a highly peculiar world. :-)
>> Martin means array indices, not numbers, IMO.
> 
> Counting in the real world is done in many peculiar ways.
> For example, at least in the US, house numbers tend to be
> even on one side of the street and odd on the other.
> 
> Counting in computer programs should be done in a way most
> convenient for the programs to do their work.

Here you hit the main difference between the Pascal/Modula-2/Ada fraction
and the C/C++ fraction.

Those Pascal/Modula-2/Ada fraction belive that computer programs should
reseble the real word as much as possible and translating beween real world
and computer world should be done by the compiler and the optimizer.

Because once the compiler and optimizer have learned to do that will do it 
right every time. Unlike humans.

I have a lot more experience in C++ then in Ada jet I make a lot more little
mistakes in C++ then in Ada. Most of which are type convertions where there
is no type is to be converted.

And of course I use warning level 4 to tell me about unsuitable type
convertions but it does not help. Mostly because the 3rd party libraries
(incl. the STL) are not compatible with warning level 4.

From my experience 10 to 1 (10 times as many silly little mistakes in C++)
is realistic.

And, unlike the normal C/C++ developer, who take these bugs K&R given, I
know that an Ada compiler would have told me that I am doing something
silly.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Dave Hansen wrote:

> On Tue, 30 Dec 2003 21:35:10 GMT, Ed Falis <falis@verizon.net> wrote:
> 
>>On Tue, 30 Dec 2003 19:20:50 GMT, Dave Hansen <iddw@hotmail.com> wrote:
> [...]
>>>    while ( (key = get_key()) != EXIT_KEY )
>>>       process(key);
>>>
>>> How do you do that in Ada?
>>>
>>
>>
>>with Get_Key, Process;
>>--  Assuming appropriate declarations elsewhere
>>
>>procedure Do_it is
>>     Key: Character;
>>     Exit_Key : constant Character := 'X';
>>begin
>>    loop
>>        Key := Get_Key;
>>    exit when Key = Exit_Key;
>>       Process (Key);
>>    end loop;
>>end Do_It;
> 
> Thanks.  It was a serious question.  I did want to know.
> 
> Though structurally, this reminds me of
> 
>    while (1)  /* or for (;;) if you like obscure syntax */
>    {
>       key = get_key();
>       if (key == EXIT_KEY) break;
>       process(key);
>    }
> 
> which tends to be discouraged.

In Ada the exit is at the front of the statement and therefore easier to
spot.

> Another question:  Note that in C, even though get_key takes no
> parameters, it is called with empty parentheses, while Get_Key in Ada
> looks (syntactically) like any other variable.  ISTR that in Modula-2,
> a function that takes no paramters could be called either way (with or
> without empty parentheses).  Is this true in Ada?  FWIW, I like the
> empty parens because they signal to the reader that something special
> is going on.

Well, no. This is partly because of the way rename works:

http://www.adaic.org/standards/95lrm/html/RM-8-5-4.html
http://www.adaic.org/standards/95lrm/html/RM-3-5-1.html

(you don't need to pay $18 to read it ;-))

Look aut for the renamings of "red" ;-). Not every function is actualy a
function.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Chris Hills wrote:
>>Do you have a reference? 
> 
???????????????????????????????????

On Wed, 31 Dec 2003 00:11:37 GMT, Dave Hansen <iddw@hotmail.com> wrote:

> Though structurally, this reminds me of
>
>    while (1)  /* or for (;;) if you like obscure syntax */
>    {
>       key = get_key();
>       if (key == EXIT_KEY) break;
>       process(key);
>    }
>
> which tends to be discouraged.

This is a matter of language-specific idioms, I'd say.   The exit from the 
statement list of a loop is the most flexible Ada iteration form, but it 
isn't used all that often - the other forms are more common since they 
cover most cases.

>
> Another question:  Note that in C, even though get_key takes no
> parameters, it is called with empty parentheses, while Get_Key in Ada
> looks (syntactically) like any other variable.  ISTR that in Modula-2,
> a function that takes no paramters could be called either way (with or
> without empty parentheses).  Is this true in Ada?  FWIW, I like the
> empty parens because they signal to the reader that something special
> is going on.

The empty parens are not allowed in Ada.  Bob Eachus or someone else might 
be able to give some of the rationale.  It's a case similar to the choice 
of () for array indexing rather than [].  In Ada, a function result is 
considered conceptually similar to a constant, as are enumeration 
literals, and many of the same rules apply to them and their use.  I 
suspect the syntax is intended to reinforce this.

- Ed

In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:
:   while ( nextkey(&key) ) process(key);
: 
: Note the address operator at the call.  It makes it obvious (at the
: point the function is used) that nextkey modifies its parameter (or at
: least it _could_).  In Pascal, the only way to know that is to look at
: the function definition.  In C++, the parameter is likely to be a
: reference, and have the same problem (IMHO) as Pascal.

Ada solution that addresses both & and the while(1) issue:

procedure p is

   function next_key (key_filled: access Character) return Boolean is separate;

   procedure process (the_key: in out Character) is separate;


   key: aliased Character;

begin

   while next_key (key'access) loop
      process(key);

   end loop;

end p;


-- Georg

Ed Falis wrote:

> This is a matter of language-specific idioms, I'd say.   The exit from 
> the statement list of a loop is the most flexible Ada iteration form, 
> but it isn't used all that often - the other forms are more common since 
> they cover most cases.

Depends on your programming style (and the type of programs you write) 
how often it occurs.  I always use it for "n and a half" type loops, and 
for tasks where the main body is a loop that is only exited in special 
circumstances.  Certainly in Ada, such loop are not discouraged, 
although some people get bent out of shape if you have two exits in a 
loop.  I certainly am not going to get upset, or even be mildly 
concerned about:

loop
   Input := Next_Char;
   exit when Input = 'X';
   exit when Input = 'x';
   Process_Input;
end loop;

vs.

loop
   Input := Next_Char;
   exit when Input = 'X' or else Input = 'x';
   Process_Input;
end loop;

In fact I slightly prefer the first form.

> The empty parens are not allowed in Ada.  Bob Eachus or someone else 
> might be able to give some of the rationale.  It's a case similar to the 
> choice of () for array indexing rather than [].  In Ada, a function 
> result is considered conceptually similar to a constant, as are 
> enumeration literals, and many of the same rules apply to them and their 
> use.  I suspect the syntax is intended to reinforce this.

There was a time when the parenthesis were required.  I think it made it 
from Preliminary Ada into Ada 80, but definitely was gone before Ada 82. 
  The argument against the empty parentheses was mostly stylistic, but 
the equivalence of enumeration and other literals to function calls was 
the real killer.  A rule that determine when the empty parentheses were 
required was considered to be a burden on users, but it also would have 
been a burden on implementors and the ARG. ;-)

Incidently there are a few cases in Ada where a function result is 
equivalent to a variable not a constant.  Read about return by reference 
for more details.  And of course you can have cases where a function 
returns an access value, and can appear in a name on the left hand side 
of an assignment statement:

function Predecessor(Node: Item_Access) return Item_Access;
....
Temp, New_Node: Item_Access;
....
New_Node.Next := Temp;
Predecessor(Temp).Next := New_Node;

Of course, this is a much more common use of functions in variable names 
  than return by reference functions.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

>The empty parens are not allowed in Ada.  Bob Eachus or someone else might 
>be able to give some of the rationale.  It's a case similar to the choice 
>of () for array indexing rather than [].  In Ada, a function result is 
>considered conceptually similar to a constant, as are enumeration 
>literals, and many of the same rules apply to them and their use.  I 
>suspect the syntax is intended to reinforce this.


I suspect that the use of () instead of [] has more to do with 7-bit
character sets for European languages. See
	http://archive.adaic.com/standards/83rat/html/ratl-02-01.html
and ISO 646. Same problem that gave us C trigraphs


-- 
	mac the na�f

Chris Hills <chris@phaedsys.org> wrote in message news:<8Ib9B0EcKc8$EAT6@phaedsys.demon.co.uk>...
> 
> >Are you claiming that the Arianne 5 wouldn't have failed
> >catastrophically if the same bug had occurred in C code? If so, that's
> >definitely interesting. I'm certainly not knowledgable enough here to
> >comment, but I'm sure others on this forum are.
> 
> Definitely. C is not strongly typed. You can chuck a long into a char
> and nothing will complain. So IN THIS PARTICULAR CASE an error would not
> have been raised and the rocket continued..... However in the 99 similar
> cases you would have wanted it to flag an error and it would not have
> done so :-) 

As an aside, I disagree with this for two reasons.  First, I expect
that sensor failure, as indicated by "impossible values," would have
been checked for in C code as well as in Ada code.  _Something_ had to
be done if the Horizontal Bias value went berzerk during a launch. 
Given the stated bias of the project (untrapped errors were assumed to
indicate hardware failure), the code would have been designed to do
exactly what the Ada code did, through an explicit range check and
switch-to-backup-unit action.

Second, it appears that the "Operand Error" that started the ball
rolling (or the rocket dropping) was actually a hardware FPU
exception.  The Ariane hardware has been reported as Motorola
68020/68881, and Operand Error is the name of the FPU exception that
would result from an out-of-range FP to INT conversion.  Even if the
code were written in C, the exception would have been generated, and
presumably the exception handler would have performed the same
deliberate and intended actions of shutting down the device so the
backup device could take over.

Mike

In article <20619edc.0312310940.4e577ab5@posting.google.com>, Mike Silva
<snarflemike@yahoo.com> writes
>Chris Hills <chris@phaedsys.org> wrote in message news:<8Ib9B0EcKc8$EAT6@phaedsy
>s.demon.co.uk>...
>> 
>> >Are you claiming that the Arianne 5 wouldn't have failed
>> >catastrophically if the same bug had occurred in C code? If so, that's
>> >definitely interesting. I'm certainly not knowledgable enough here to
>> >comment, but I'm sure others on this forum are.
>> 
>> Definitely. C is not strongly typed. You can chuck a long into a char
>> and nothing will complain. So IN THIS PARTICULAR CASE an error would not
>> have been raised and the rocket continued..... However in the 99 similar
>> cases you would have wanted it to flag an error and it would not have
>> done so :-) 
>
>As an aside, I disagree with this for two reasons.  First, I expect
>that sensor failure, as indicated by "impossible values," would have
>been checked for in C code as well as in Ada code.

Maybe.  Well you would like to thing so. 

But I did say in this specific case of putting a large number into a
smaller sized int.

>  _Something_ had to
>be done if the Horizontal Bias value went berzerk during a launch. 
>Given the stated bias of the project (untrapped errors were assumed to
>indicate hardware failure), the code would have been designed to do
>exactly what the Ada code did, through an explicit range check and
>switch-to-backup-unit action.

No complaint about that. My understanding was that the "error" occurred
after the figures from the SW unit were being used as it was past the
point in the flight where they were needed.


>Second, it appears that the "Operand Error" that started the ball
>rolling (or the rocket dropping) was actually a hardware FPU
>exception. 

Ok... thats HW so it makes no difference on the language used.

> The Ariane hardware has been reported as Motorola
>68020/68881, and Operand Error is the name of the FPU exception that
>would result from an out-of-range FP to INT conversion.  Even if the
>code were written in C, the exception would have been generated, and
>presumably

presumably... It's like the "should" word that keeps cropping up just
before things go wrong :-)

> the exception handler would have performed the same
>deliberate and intended actions of shutting down the device so the
>backup device could take over.

But as the back up had the same problem.... the rest is history.


Interesting analysis. 


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England    /\/\/\/\/\
/\/\/ chris@phaedsys.org       www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills <chris@phaedsys.org> wrote in message news:<dUH1GvFv9w8$EA2P@phaedsys.demon.co.uk>...

>...the rest is history.

Or, as it's know in comp.lang.ada, "not that damned rocket _again_!" :)

(I've deleted comp.arch.embedded, since this is about some weird Ada
obscurity.)

"Robert I. Eachus" <rieachus@comcast.net> writes:

> There was a time when the parenthesis were required.  I think it made it
> from Preliminary Ada into Ada 80, but definitely was gone before Ada
> 82.

I believe that's correct.

>... The argument against the empty parentheses was mostly stylistic, but
> the equivalence of enumeration and other literals to function calls was
> the real killer.

Agreed.

>...A rule that determine when the empty parentheses were
> required was considered to be a burden on users, but it also would have
> been a burden on implementors and the ARG. ;-)

But I think requiring empty parens on parameterless calls would actually
*simplify* the compiler.  I can think of two cases:

    function F(X: Integer := 1) return String;

Only context can tell whether F(37) means "call F with actual parameter
37" versus "call F with actual parameter defaulted to 1, and then select
component number 37 of the resulting String."  That is, it requires
overload resolution to figure out the syntax of "F(37)" -- is it a
function call or is it an indexed component?

The other example is entry families.  Task_Name.Entry_Name(X)
could mean to call a parameterless entry whose index in the family
is X, or it could mean to call a single entry passing actual parameter
X.  The compiler can't tell which it is based purely on (context free)
syntax.

- Bob

Robert A Duff wrote:
> But I think requiring empty parens on parameterless calls would actually
> *simplify* the compiler.

Don't forget the useful fiction that enumeration literals
are parameterless functions. That would be impacted by
requiring empty parentheses. Now, if it hadn't been decided
that array access and function calls should both use ()...

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > But I think requiring empty parens on parameterless calls would actually
> > *simplify* the compiler.
> 
> Don't forget the useful fiction that enumeration literals
> are parameterless functions.

I don't much like that "useful fiction".  Seems more like a "strange
confusion", to me.

We don't pretend that "1" is the name of a function, after all.

>... That would be impacted by
> requiring empty parentheses.

Indeed.

>... Now, if it hadn't been decided
> that array access and function calls should both use ()...

Yeah, ... ;-)

- Bob

Robert A Duff wrote:
> I don't much like that "useful fiction".  Seems more like a "strange
> confusion", to me.

That fiction combines with the ability to overload on return type such
that you can have the same name (or literal) used as an enumerator for
multiple types, and the compiler figures out which one is meant from
context in most cases. It means that the ARM doesn't have to create a
separate rule allowing and explaining this.

But you already know that, right?

Robert A Duff wrote:

> Hyman Rosen <hyrosen@mail.com> writes:
> 
>> Robert A Duff wrote:
>> > But I think requiring empty parens on parameterless calls would
>> > actually *simplify* the compiler.
>> 
>> Don't forget the useful fiction that enumeration literals
>> are parameterless functions.
> 
> I don't much like that "useful fiction".  Seems more like a "strange
> confusion", to me.
> 
> We don't pretend that "1" is the name of a function, after all.

Why not to?

There is a famous way to build positive numbers from sets. Let null be an
empty set, then {null} is 1, {{null}} is 2 etc. Putting this in Ada
notation, could be:

1 renames (others=>null);
2 renames (others=>(others=>null));
.... -- (:-))

-- 
Regards,
Dmitry A. Kazakov
www.dmitry-kazakov.de

In article <vUh5muAofB7$EAZb@phaedsys.demon.co.uk>
           chris@phaedsys.org "Chris Hills" writes:

> The table shows failures in safety related systems  
> 
> 44.1%  were due to specification faults
> 20.6 due to changes after commissioning
> 
> joint 3rd with 14.7% were:
> design and implementation
> operation and maintenance
> 
> there was also
> 5.9% on installation and commissioning.
> 
> So it's not down to the language as much as specification and
> process.....  
> 
> See the Arianne 5 rocket project. The system failed 29 seconds in due to
> Sw errors. the problem was not so much Ada but the way it was used and
> the project managed. 
> 
> NB the project would have flown if C had been used because C is not
> strongly typed and the same error would not have been generated.... OK..
> I know, if they used C it would never have lifted off in the first
> place.... :-)
> 
> With a good process in place and proper engineering removing the vast
> majority of errors we start to discover the differences in languages is
> less important. More important is how good the tools and support tools
> for a language are. 
> 
> I know of one very high integrity system that is using C because the
> quality of the compiler is very high and the support tools are
> available. They are not available for Ada for the same target. they
> could not have done the same level of testing and validation.

I think that makes the points I have been promulgating so often, on this
and other groups, very nicely Chris. Thanks.

The only other point is that whatever your process, it should generate 
the necessary evidence for your audit trail to be able to back-track to
where problems were introduced. I know that Def-Std 00-56 was recently
being reviewed to see if the evidential position could be improved.

-- 
********************************************************************
Paul E. Bennett ....................<email://peb@amleth.demon.co.uk>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

"Hyman Rosen" <hyrosen@mail.com> wrote:
> Robert A Duff wrote:
> > I don't much like that "useful fiction".  Seems more like a "strange
> > confusion", to me.
>
> That fiction combines with the ability to overload on return type such
> that you can have the same name (or literal) used as an enumerator for
> multiple types, and the compiler figures out which one is meant from
> context in most cases. It means that the ARM doesn't have to create a
> separate rule allowing and explaining this.
>
> But you already know that, right?

Bob better know that, or we'll have to revoke his language-lawyer license!
:-)

                   Randy.

Hyman Rosen <hyrosen@mail.com> writes:

> Robert A Duff wrote:
> > I don't much like that "useful fiction".  Seems more like a "strange
> > confusion", to me.
> 
> That fiction combines with the ability to overload on return type such
> that you can have the same name (or literal) used as an enumerator for
> multiple types, and the compiler figures out which one is meant from
> context in most cases. It means that the ARM doesn't have to create a
> separate rule allowing and explaining this.

I very much like the ability to overload on return type (as in the enum
lits we're talking about).  This is superior to the overloading in C++,
and many other languages, IMHO, which is always bottom up.

But the reasoning seems to be:
1. Overloading is for subprogram names.
2. But we want to overload enum lits, too.
3. So we better pretend that enum lits are functions.

A better line of thinking is:
1. Overloading is for subprogram names.
2. But we want to overload enum lits, too.
3. OOPS.  Number 1 is wrong.  We can let enum lits be overloaded,
but there's no reason to pretend they're functions.  They're just plain
old literals.
4. Might as well let constants be overloaded, too, with rules similar
to enum lits.

By the way, there's no need for a "separate rule" to allow overloading.
If the concept exists in the language, and you don't want to allow
overloading of everything, then you need rules in the other direction --
for example, the rules in Ada about no two homographs in the same
declarative region.

I would prefer to allow *everything* to be overloaded, but put the
restrictions in the resolution rules.

> But you already know that, right?

I know it only too well.  ;-)

- Bob

On 26 Dec 2003 19:39:18 -0800, 18k11tm001@sneakemail.com (Russ) wrote:

>Chris Hills <chris@phaedsys.org> wrote in message news:<vUh5muAofB7$EAZb@phaedsys.demon.co.uk>...
<snip>

>> With a good process in place and proper engineering removing the vast
>> majority of errors we start to discover the differences in languages is
>> less important. More important is how good the tools and support tools
>> for a language are. 
>
>You lost me there. As I explained above, I agree that the choice of
>language has little effect on the engineering. But the point is that
>the choice of language has a strong effect on the software design and
>development process. Isn't that what we're talking about here? If not,
>sorry, wrong number.

The choice of the implementation language should have no bearing on
the software design, unless one is using a language specific feature
as a design feature. 

The choice of language may affect the software development process in
so much as coding guidelines and associated work instructions. For
instance, the choice of C over Ada may mean that a more rigorous code
syntax checking be performed and/or more comprehensive structural unit
testing be carried out. The integration and system testing of a system
built with either language should pretty much be the same.

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

On Thu, 18 Dec 2003 20:37:52 +0000 (UTC), peb@amleth.demon.co.uk
("Paul E. Bennett") wrote:

>In article <3fe155df.209316468@News.CIS.DFN.DE>
>           postmaster@noname.com "Ken Lee" writes:
>
>> In response to the previous poster, "professionalism and experience"
>> of the developer is a very inconsistent attribute. 
>
>Professionalism, surely, demands that the engineers employ a development
>process that stands the test by producing dependable systems. Whether it
>is an individual engineer, or many teams, there should be a decent 
>development process in place to manage any project from initial quotation
>to de-commissioning at end of system life. For the lone engineer it means 
>that his process should be acceptable to his clients.

Don't get me wrong -- you'd think what you stated would be true, but
there is no "standard" for professionalism. The fact that one has a
piece of paper stating that they are a bona fide engineer doesn't mean
that they're any good. However by "natural selection", those engineers
that are gainfully still employed and are regarded by their peers as
professional, do use acceptable processes (personal or otherwise).

<snip>

>
>When I have seen that some companies QA manual runs to eight or more
>volumes I know they are not following any of it. Such is an example
>of the wrong process because it is not memorable enough. My own 
>document is a mere 35 pages but has always stood me in good stead.
>The whole process is simply represented on a single page in a 
>flowchart which is also on my web-site.

Although I'm not an advocate of quality manuals of biblical
proportions, I do believe that the QM is dependant on the type of
product one is developing. If one's company is subjected to external
regulatory audits, then the scope of the QM should be so appropriate
(as a minimum) to the auditor's expectations. Theoretically the QM
should be scoped to be appropriate to the level of criticality of the
system.

Ken.

+====================================+
I hate junk email. Please direct any 
genuine email to: kenlee at hotpop.com

On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
<sb463ba@l1-hrz.uni-duisburg.de> wrote:

>In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:

Note: I'm reading from comp.arch.embedded.  Just so you know where I'm
coming from...

>:   while ( nextkey(&key) ) process(key);
>: 
[... "&" operator signals "nextkey" might modify the value of the
parameter ...]
>
>Ada solution that addresses both & and the while(1) issue:
>
>procedure p is
>
>   function next_key (key_filled: access Character) return Boolean is separate;
>
>   procedure process (the_key: in out Character) is separate;
>
>
>   key: aliased Character;
>
>begin
>
>   while next_key (key'access) loop
>      process(key);
>
>   end loop;
>
>end p;

Thanks.  I like it, if I understand it.  ;-)

Is the "'access" tag (or whatever you call it) _required_ on the call
if a function is going to modify the parameter?  I like it even better
if that's true.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

On Wed, 31 Dec 2003 12:02:48 +0100, Martin Krischik
<krischik@users.sourceforge.net> wrote:

>Dave Hansen wrote:
>
>> On Tue, 30 Dec 2003 21:35:10 GMT, Ed Falis <falis@verizon.net> wrote:
>> 
[...]
>>>    loop
>>>        Key := Get_Key;
>>>    exit when Key = Exit_Key;
>>>       Process (Key);
>>>    end loop;
[...]
>> Thanks.  It was a serious question.  I did want to know.
>> 
>> Though structurally, this reminds me of
>> 
>>    while (1)  /* or for (;;) if you like obscure syntax */
>>    {
>>       key = get_key();
>>       if (key == EXIT_KEY) break;
>>       process(key);
>>    }
>> 
>> which tends to be discouraged.
>
>In Ada the exit is at the front of the statement and therefore easier to
>spot.

I'm not sure what you mean.   If you're talking about indentation, C
gives you the freedom to do that:

    while (1)
    {
       key = get_key();
    if (key == EXIT_KEY) break;
       process(key);
    }

The problem in C is the "break," which is (wrongfully, in my view)
thought to be too similar to "goto" ("continue" has a similar
reputation).  The other problem is that "break" is overloaded (WRT
switch/case statements) and might be confusing.  Some people propose
"named breaks" in the (misguided, IMHO) theory that something like

    while process_input: (1)
    {
       key = get_key();
       if (key == EXIT_KEY) break process_input;
       process(key);
    }

is somehow clearer. (Actually, "named breaks" would also allow you to
"break" out of nested loops without a goto, but I'm not looking to get
into that particular argument, just trying to clarify my "discouraged"
comment above.)

[... calling functions with empty parentheses ...]
>
>Well, no. This is partly because of the way rename works:
>
>http://www.adaic.org/standards/95lrm/html/RM-8-5-4.html
>http://www.adaic.org/standards/95lrm/html/RM-3-5-1.html
>
>(you don't need to pay $18 to read it ;-))
>
>Look aut for the renamings of "red" ;-). Not every function is actualy a
>function.

Interesting.  Since I have no real Ada experience, can you tell me
what the differences between something like

   function Rouge return Color renames Red;

and declaring a constant (please forgive the clumsy guess at the
proper syntax) something like

   const Rouge: Color = Red;

are?  The only one I can come up with at first blush is that you can
take the address of a function (I assume...)

Thanks,

                               -=Dave
-- 
Change is inevitable, progress is not.

iddw@hotmail.com (Dave Hansen) writes:

> On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
> <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> 
> Is the "'access" tag (or whatever you call it) _required_ on the call
> if a function is going to modify the parameter?  

Yes. Ada allows "in out" for procedure parameters, but not for
function parameters.

> I like it even better if that's true.

I don't. Why introduce pointers when "in out" would do the job!

Apparently there were some people on the design team for Ada 83 who
thought "function" meant "no side effects", and want to "enforce"
that. Of course, functions can have side effects; now they just have
to lie about it!

But it's not going to change :).

-- 
-- Stephe

Dave Hansen wrote:
> <krischik@users.sourceforge.net> wrote:
> >Dave Hansen wrote:
> >
> [...]
> >>
> >> Though structurally, this reminds me of
> >>
> >>    while (1)  /* or for (;;) if you like obscure syntax */
> >>    {
> >>       key = get_key();
> >>       if (key == EXIT_KEY) break;
> >>       process(key);
> >>    }
> >>
> >> which tends to be discouraged.
> >
> > In Ada the exit is at the front of the statement and therefore
> > easier to spot.
> 
> I'm not sure what you mean.   If you're talking about indentation,
> C gives you the freedom to do that:
> 
>     while (1)
>     {
>        key = get_key();
>     if (key == EXIT_KEY) break;
>        process(key);
>     }
> 
> The problem in C is the "break," which is (wrongfully, in my view)
> thought to be too similar to "goto" ("continue" has a similar
> reputation).  The other problem is that "break" is overloaded (WRT
> switch/case statements) and might be confusing.  Some people propose
> "named breaks" in the (misguided, IMHO) theory that something like
> 
>     while process_input: (1)
>     {
>        key = get_key();
>        if (key == EXIT_KEY) break process_input;
>        process(key);
>     }
> 
> is somehow clearer. (Actually, "named breaks" would also allow
> you to "break" out of nested loops without a goto, but I'm not
> looking to get into that particular argument, just trying to
> clarify my "discouraged" comment above.)

IMO the appropriate C phrasing is:

   while ( (EXIT_KEY != (key = get_key())) ) {
      process(key);
   }

and we should assume that get_key returns EXIT_KEY for EOF.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

Dave Hansen wrote:

> On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
> <sb463ba@l1-hrz.uni-duisburg.de> wrote:
> 
>>In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:
> 
> Note: I'm reading from comp.arch.embedded.  Just so you know where I'm
> coming from...
> 
>>:   while ( nextkey(&key) ) process(key);
>>: 
> [... "&" operator signals "nextkey" might modify the value of the
> parameter ...]
>>
>>Ada solution that addresses both & and the while(1) issue:
>>
>>procedure p is
>>
>>   function next_key (key_filled: access Character) return Boolean is
>>   separate;
>>
>>   procedure process (the_key: in out Character) is separate;
>>
>>
>>   key: aliased Character;
>>
>>begin
>>
>>   while next_key (key'access) loop
>>      process(key);
>>
>>   end loop;
>>
>>end p;
> 
> Thanks.  I like it, if I understand it.  ;-)
> 
> Is the "'access" tag (or whatever you call it) _required_ on the call

Its called an attribute. All sort of things can have attributes. i.E. the
Integer'Image () (function) attribute creates a String repesenting and
Integer.

> if a function is going to modify the parameter?  I like it even better
> if that's true.

For functions yes, procedures however have in, out, in out and access. The
difference between out and in out is interesting one. out means that the
data comes back but no data is passed in.

BZW: in, out and in out may or may not be implemented by the use of pointer.
The compiler will do what is best. i.E. for a char it might be better to
copy the char in and out instead passing a pointer. Especialy when a
register is available for parameter passing.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

In comp.arch.embedded Dave Hansen <iddw@hotmail.com> wrote:
: On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus
: <sb463ba@l1-hrz.uni-duisburg.de> wrote:
: 
:>In comp.lang.ada Dave Hansen <iddw@hotmail.com> wrote:
: 
: Note: I'm reading from comp.arch.embedded.  Just so you know where I'm
: coming from...

Sorry. I need to adjust my reader software.

: Is the "'access" tag (or whatever you call it)

It's an attribute, like 'address, 'size, 'range, etc.

: Is the "'access" tag (or whatever you call it) _required_ on the call
: if a function is going to modify the parameter?  I like it even better
: if that's true.

Yes, as Stephen has explained. Let me add that if you want a variable
to be modifiably through some pointer you will have to say so.
You declare the variable aliased (using the "aliased" keyword
in the declaration), and point to it using 'access values.

There is also an 'unchecked_access attribute which allows pointers to
aliased local objects to be passed around. The intention is to remind
the programmer/maintainer of the pointer validity check that cannot
in general be done by the compiler as in the following example:

   type Reg16_Ptr is access all Interfaces.Unsigned_16;
   --  pointer to a 16 bit register


   function trig_reg return Reg16_Ptr is
      
      v: aliased Interfaces.Unsigned_16;
      --  16 bits from the toaster's eject trigger, v is local to function
      
      pragma Import(Ada, v);
      --  do not initialise v
      
      for v'address use System.Storage_Elements.To_Address(16#A022#);
      --  hardware address
   begin
      return v'unchecked_access;
      --  points to local v which is really a register, not a value on the
      -- stack
   end trig_reg;


-- Georg

"Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> Apparently there were some people on the design team for Ada 83 who
> thought "function" meant "no side effects", and want to "enforce"
> that. Of course, functions can have side effects; now they just have
> to lie about it!

AFAIK the following is completely valid Ada 83. Note how similar this is to
the examples presented to show why allowing "in out" parameters in functions
is a bad idea.

    type Integer_Acc is access Integer;

    X_Acc : Integer_Acc := new Integer'( 2 );
    Y : Integer;

    function Incr( Acc : in Integer_Acc ) return Integer is
    begin
       Acc.all := Acc.all + 1;
       return Acc.all;
    end Incr;

    ...

    Y := Incr( X_Acc ) - X_Acc.all;     -- Y is ???

> "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> Apparently there were some people on the design team for Ada 83 who
> thought "function" meant "no side effects", and want to "enforce"
> that. Of course, functions can have side effects; now they just have
> to lie about it!
I've seen this argument quite often (especially by RBKD), but it is totally bogus.
Nobody claimed that functions should not have side effects, but only that functions compute a result given some parameters and the
global state of the program. It was felt that it was OK for a function to modify the global state, but modifying the parameters
would be surprising and error-prone.

BTW, Ada79 had functions that were required to not have side effects, and value returning procedures that did not have this
constraint. This was felt to be too extreme (or maybe difficult to enforce) and the current solution to be an acceptable trade-off.

-- 
---------------------------------------------------------
           J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Martin Krischik wrote:
> Its called an attribute. All sort of things can have attributes. i.E. the
> Integer'Image () (function) attribute creates a String repesenting and
> Integer.

This is the main feature which confounds attempts to use the C
preprocessor on Ada programs. It also confounds "ordinary" program
editors that believe single quotes should come in matched pairs.

Yet another obstacle for potential new users of Ada, who might want
to load up some Ada code in a non-Ada IDE to have a look at it.

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1073409810.463948@master.nyc.kbcfp.com...
> This is the main feature which confounds attempts to use the C
> preprocessor on Ada programs. It also confounds "ordinary" program
> editors that believe single quotes should come in matched pairs.

As for the C preprocessor, why not use m4 instead?  Why would anyone want to
use the C preprocessor on Ada programs when there are other, better,
just-as-free, macro processors available?

As for smart editors that aren't smart enough, I'd suggest upgrading to
something smarter or downgrading to something dumber.  Emacs and vi should
both work fine.

> Yet another obstacle for potential new users of Ada, who might want
> to load up some Ada code in a non-Ada IDE to have a look at it.

Is it common for developers to have their programming language selection
determined by the limitations of their text editor?

If you want to argue against Ada, you should find a better argument than "my
editor is broken".

Kelly

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1072806253.772580@master.nyc.kbcfp.com...
> Martin Krischik wrote:
> > I had my array start at 1 not 0. In C all numbers start with 0 but in
the
> > real world they usualy start with 1.
>
> The "real world" doesn't have arrays. Only computer programs do.

I must remember to tell my radar building biddies, who have (various types
of) antenna arrays... ;-)

In comp.lang.ada, ... Hyman Rosen <hyrosen@mail.com> wrote:

: It also confounds "ordinary" program
: editors that believe single quotes should come in matched pairs.

Like a VB editor?
How do "ordinary" program editors handle std::string s = "'"; ?
Or any string literal that has a single quote in it?
How about a < b?
Is it difficult to write Algol 60 programs in "ordinary" program
editors, then?

I think programming languages should not be designed solely
around the "beliefs" of "ordinary" program editors?


-- Georg

Kelly Hall wrote:
> As for the C preprocessor, why not use m4 instead?  Why would anyone want to
> use the C preprocessor on Ada programs when there are other, better,
> just-as-free, macro processors available?

Because they already use the C preprocessor for C, and for IDL, and for
X Window resource files, and perhaps for other things, while they have
never even heard of m4. Because the configuration information with which
they hope to filter their Ada source code already exists in the form of
system header files in C preprocessor format.

> As for smart editors that aren't smart enough, I'd suggest upgrading to
> something smarter or downgrading to something dumber.  Emacs and vi should
> both work fine.

As I said, it's an obstacle. Obstacles aren't insurmountable, just annoying.

> Is it common for developers to have their programming language selection
> determined by the limitations of their text editor?

It's common for people to load up files in whatever editor they happen to
be using at the moment. The scattered single quotes are going to look funny,
and people are going to think it's an odd choice, once they realize that
quoted strings aren't being delimited.

> If you want to argue against Ada, you should find a better argument than "my
> editor is broken".

Why would I want to argue against Ada?

"Jean-Pierre Rosen" <rosen@adalog.fr> writes:

> > "Stephen Leake" <Stephe.Leake@nasa.gov> wrote in message
> > news:mailman.212.1073342204.31149.comp.lang.ada@ada-france.org...
> > Apparently there were some people on the design team for Ada 83 who
> > thought "function" meant "no side effects", and want to "enforce"
> > that. Of course, functions can have side effects; now they just have
> > to lie about it!

> I've seen this argument quite often (especially by RBKD), but it is
> totally bogus. 

Hmm. You must be using some different meanings for the words "totally
bogus" than I do.

> Nobody claimed that functions should not have side effects, but only
> that functions compute a result given some parameters and the global
> state of the program. 

That's what procedures do as well; what's the difference? Oh, one of
the "out" parameters to a function is called the "result". Why should
that matter?

> It was felt that it was OK for a function to modify the global
> state, but modifying the parameters would be surprising and
> error-prone.

Surprising to you, perhaps. Not to me! It is surprising to me that I
_can't_ have "in out" in functions.

So the argument is _not_ _totally_ bogus. A little bogus, perhaps? I'd
prefer to say the argument is not universally accepted, or more
accuratly, not accepted by a majority of the Ada 83 and 95 teams.

> BTW, Ada79 had functions that were required to not have side
> effects, and value returning procedures that did not have this
> constraint. This was felt to be too extreme (or maybe difficult to
> enforce) and the current solution to be an acceptable trade-off.

I understand that was the decision reached. Obviously, I'd prefer the
Ada79 approach. Or provide a pragma (like Pure) that says "this
function has no side effects". I'm having a hard time understanding
what the downside of permitting me to use "in out" in functions is,
for those who don't want them. It doesn't cost them anything! We could
give them a compiler switch that forbids them if they want it.

-- 
-- Stephe

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1073421950.964139@master.nyc.kbcfp.com...
> Kelly Hall wrote:
> > As for the C preprocessor, why not use m4 instead?  Why would anyone
want to
> > use the C preprocessor on Ada programs when there are other, better,
> > just-as-free, macro processors available?
>
> Because they already use the C preprocessor for C, and for IDL, and for
> X Window resource files, and perhaps for other things, while they have
> never even heard of m4.

But learning about m4 is a valuable exercise! It is a flexible and powerful
preprocessor with far more capabilities that the C preprocessor.

Stephen Leake wrote:

> I understand that was the decision reached. Obviously, I'd prefer the
> Ada79 approach. Or provide a pragma (like Pure) that says "this

Funny, but just today I read that GNAT does indeed have pragma
Pure_Function.

With Regards

Martin
-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

What exactly would be the meaning of:

A := Func_X (A) + Func_Y (A) ;

if functions had in-out parameters and A could be modified while 
evaluating the RHS? I suppose one might be able to come up with some 
evaluation rules that at least meant determinism for the end result, but 
staring at it would not make it intuitively obvious to even the most 
casual observer. Sure, the functions *could* modify A if they had 
visibility to the right scope, but how often does someone do that in 
real-world use? The current style - while not guaranteeing a lack of 
side effects - tends to discourage it and leads to more easily 
comprehended code.

I don't understand what the headache is here anyway. If one wants to 
modify parameters, use a procedure. If one wants some kind of 
math-oriented thingie to return a result, use a function. Only 
interfacing to squirly languages like C seems to be an issue - and I 
think that ought to be a difficult and painful thing to discourage it 
from happening. :-)

MDC

Jean-Pierre Rosen wrote:
> 
> I've seen this argument quite often (especially by RBKD), but it is totally bogus.
> Nobody claimed that functions should not have side effects, but only that functions compute a result given some parameters and the
> global state of the program. It was felt that it was OK for a function to modify the global state, but modifying the parameters
> would be surprising and error-prone.
> 
> BTW, Ada79 had functions that were required to not have side effects, and value returning procedures that did not have this
> constraint. This was felt to be too extreme (or maybe difficult to enforce) and the current solution to be an acceptable trade-off.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Marin David Condic <nobody@noplace.com> writes:

> What exactly would be the meaning of:
> 
> A := Func_X (A) + Func_Y (A) ;

> if functions had in-out parameters and A could be modified while
> evaluating the RHS? 

Obviously, this is erroneous code, since the result depends on the
order of evaluation. Note that it is legal Ada now, if A is an
access parameter. It is similarly erroneous if either Func_X or Func_Y
have other mutually-dependent side effects.

Ada usually tries to eliminate the possibility of such erroneous code.
But given all the ways this statement can be erroneous, I see very
little gain from forbidding "in out".

I guess that's the point of disagreement; how much gain or cost there
is in forbidding "in out".

> Sure, the functions *could* modify A if they
> had visibility to the right scope, but how often does someone do
> that in real-world use? 

All the time in my code, because I need to write reentrant code that
has state.

The canonical example is a random number generator:

function Random (Gen : in out Generator) return Float;

"Obviously", this should be a function (the C and Ada standards say so
:). Also "obviously", it needs to modify the state of the generator.
Not so obviously, that state needs to be stored in the parameter, so I
can call Random from several different threads.

Currently, in non-tricky, legal Ada 95, we cannot simultaneously
satisfy all of the above statements. The only one I'm free to change
is the first one; subprograms that modify state and are reentrant must
be procedures, not functions. (I include using "access" instead of "in
out" as "tricky" code).

All of the Ada 95 implementations must resort to "tricks" to implement
the standard Random. That seems "totally bogus" to me :).

> The current style - while not guaranteeing a lack of side effects -
> tends to discourage it and leads to more easily comprehended code.

Marginally more comprehendable, in some cases. Marginally less
comprehendable, in other cases. This is really a moot point, since we
have access parameters.

Why is making A "access" better than making A "in out"? The parameter
mode is supposed to indicate whether the parameter is modified or not.
It is _not_ supposed to indicate the parameter passing mechanism!

Using "access" instead of "in out" is a form of lying to the user; it
reduces comprehension.

> I don't understand what the headache is here anyway. If one wants to
> modify parameters, use a procedure. 

That is always possible. But why should I not have the choice of using
a function, if it fits the application better?

Why is Random a function?

> If one wants some kind of
> math-oriented thingie to return a result, use a function. 

But I want a function that modifies state in a reentrant way, like
Random does.

> Only interfacing to squirly languages like C seems to be an issue -
> and I think that ought to be a difficult and painful thing to
> discourage it from happening. :-)

Interfacing with C always requires a pragma, so 'pragma
Valued_Procedure' is perfectly reasonable here. I agree that is _not_
an argument for "in out" in functions.

-- 
-- Stephe

Frank J. Lhota wrote:
> But learning about m4 is a valuable exercise! It is a flexible and powerful
> preprocessor with far more capabilities that the C preprocessor.

One of the things you can learn about m4 is that it has no way of
dealing specially with character strings, so if you're using it on
Ada programs and innocently want to do
     Text_IO.Put_Line("This is a UNIX system!");
you could very easily wind up with
     Text_IO.Put_Line("This is a 1 system!");

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1073409810.463948@master.nyc.kbcfp.com...
> Martin Krischik wrote:
> > Its called an attribute. All sort of things can have attributes. i.E.
the
> > Integer'Image () (function) attribute creates a String repesenting and
> > Integer.
>
> This is the main feature which confounds attempts to use the C
> preprocessor on Ada programs. It also confounds "ordinary" program
> editors that believe single quotes should come in matched pairs.
>
> Yet another obstacle for potential new users of Ada, who might want
> to load up some Ada code in a non-Ada IDE to have a look at it.

I've never used it but what about the GNAT pre-processor (gnatprep?). Given
that it is a pre-processor for Ada (well GNAT Ada :-) it should be able to
handle everything.

Otherwise, you are surely using a knife when you need a spoon...

Stephen Leake <stephen_leake@acm.org> writes:

> The canonical example is a random number generator:
> 
> function Random (Gen : in out Generator) return Float;
> 
> "Obviously", this should be a function (the C and Ada standards say so
> :).

During the Ada 9X project, some folks suggested making it a procedure.
This was considered a non-starter, primarily because Fortran uses a
function, and that's what people expect.  It is rather strange that
(some of) the same language designers who choked at the idea of making
Random a procedure were adamant about forbidding 'in out' params.

There are all kinds of advantages to using functions over procedures.
One is that you can use a function to initialize an object, right at
the point of declaration.  Using a procedure is error prone, because
the initialization is far-separated from the declaration, and because
it requires making constants into variables.  Furthermore, some
kinds of subtypes *cannot* be initialized by procedures -- String,
for example.

Limiting the applicability of functions by forbidding 'in out'
is poor language design.  The programmer should be the one
to decide when side effects are appropriate.

The mistake is in thinking that Ada "functions" are the same thing as
maths "functions" -- they are not.  Ada functions are simply a procedure
with a different calling syntax.  IMHO, both kinds of subprograms should
have been called "procedures".

>... Also "obviously", it needs to modify the state of the generator.
> Not so obviously, that state needs to be stored in the parameter, so I
> can call Random from several different threads.

It is also possible to implement the generator as a private type that
has a pointer into the heap.  But then you need to horse around with
finalization in order to manage the memory.  And note that the generator
type cannot simply *be* a limited controlled type, because of the
accessibility rules -- more horsing around.

- Bob

"safety critical C" is an oxymoron if I ever heard one.

"> > As for smart editors that aren't smart enough, I'd suggest upgrading to
> > something smarter or downgrading to something dumber.  Emacs and vi should
> > both work fine.
>
> As I said, it's an obstacle. Obstacles aren't insurmountable, just annoying.
>
> > Is it common for developers to have their programming language selection
> > determined by the limitations of their text editor?
>
> It's common for people to load up files in whatever editor they happen to
> be using at the moment. The scattered single quotes are going to look funny,
> and people are going to think it's an odd choice, once they realize that
> quoted strings aren't being delimited.
>

I  put a single quote line into codewright just now. It turns the rest of the line red.
Big deal. Get a new editor.

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc65fn9vtb.fsf@shell01.TheWorld.com...
> During the Ada 9X project, some folks suggested making it a procedure.
> This was considered a non-starter, primarily because Fortran uses a
> function, and that's what people expect.  It is rather strange that
> (some of) the same language designers who choked at the idea of making
> Random a procedure were adamant about forbidding 'in out' params.

Was there any discussion of using access types, i.e.

    function Random (Gen : access Generator) return Result_Subtype;

This would require that each generator is aliased, and that 'Access
attributes be used, but at least this would give some recognition to the
fact that the generator is changed by the call.

> There are all kinds of advantages to using functions over procedures.
> One is that you can use a function to initialize an object, right at
> the point of declaration.  Using a procedure is error prone, because
> the initialization is far-separated from the declaration, and because
> it requires making constants into variables.  Furthermore, some
> kinds of subtypes *cannot* be initialized by procedures -- String,
> for example.
>
> Limiting the applicability of functions by forbidding 'in out'
> is poor language design.  The programmer should be the one
> to decide when side effects are appropriate.
>
> The mistake is in thinking that Ada "functions" are the same thing as
> maths "functions" -- they are not.  Ada functions are simply a procedure
> with a different calling syntax.  IMHO, both kinds of subprograms should
> have been called "procedures".
>
> >... Also "obviously", it needs to modify the state of the generator.
> > Not so obviously, that state needs to be stored in the parameter, so I
> > can call Random from several different threads.
>
> It is also possible to implement the generator as a private type that
> has a pointer into the heap.  But then you need to horse around with
> finalization in order to manage the memory.  And note that the generator
> type cannot simply *be* a limited controlled type, because of the
> accessibility rules -- more horsing around.
>
> - Bob

Scott Moore wrote:
> Big deal. Get a new editor.

And that's certainly something they would do if they decided
to use Ada.  But I was talking about casual first impressions.
There was a thread here a while ago claiming that Ada was easy
to read and that no odd surprises lurk in the syntax, unlike C
and its ilk. This is a counterexample.

Scott Moore wrote:
> "safety critical C" is an oxymoron if I ever heard one.

Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!

Hyman Rosen wrote:

> Scott Moore wrote:
>> "safety critical C" is an oxymoron if I ever heard one.
> 
> Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!

That wasn't a programing bug - that was a management bug!

The managent decided to use the Ariane 4 software on the Ariane 5. They
wanted to save the money on developing *and* testing a new software
release.

No programer had been asked if the Ariane 4 software was suitable for the
Ariane 5. The software was not run thrue a test suit - not even once.

Fatal since it was no sporatic problem. It was a 100% allways problem:
Ariane 4 is a vertical lift off, the software was designed for vertical
lift off. Ariane 5 is a tilted lift off.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

"Frank J. Lhota" <NOSPAM.lhota.adarose@verizon.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wcc65fn9vtb.fsf@shell01.TheWorld.com...
> > During the Ada 9X project, some folks suggested making it a procedure.
> > This was considered a non-starter, primarily because Fortran uses a
> > function, and that's what people expect.  It is rather strange that
> > (some of) the same language designers who choked at the idea of making
> > Random a procedure were adamant about forbidding 'in out' params.
> 
> Was there any discussion of using access types, i.e.
> 
>     function Random (Gen : access Generator) return Result_Subtype;
> 
> This would require that each generator is aliased, and that 'Access
> attributes be used, but at least this would give some recognition to the
> fact that the generator is changed by the call.

As far as I can remember, this idea was considered, and was generally
thought to be ugly.  I mean, suppose you're trying to convince a Fortran
programmer to use Ada for numerics stuff.  If you start babbling about
aliased and 'Access when there is no inherent need for pointers,
they're going to laugh, and rightly so.

It would boil down to this rule: "All variables of type Generator must
be declared aliased, for reasons only some crazy language lawyer types
can explain."

The random number package was designed to be easy to use.  Introducing
pointers, or making Random a procedure, were thought to be annoyances.

- Bob

On Thu, 08 Jan 2004 10:18:12 GMT, "Scott Moore" <samiam@moorecad.com>
wrote:

[...]
>I  put a single quote line into codewright just now. It turns the rest of the line red.
>Big deal. Get a new editor.

Umm, CodeWright has an Ada lexer.  Not very sophisticated, but it
solves this problem.  When I put the function using "key'access" in a
junk.ada buffer, the "access" is highlighted as a keyword, and the
apostrophe (single-quote) is black.  

The biggest problem is that it doesn't differentiate well between
functions, simple variables, and arrays: An identifier followed by a
paren is highlighted as a function, otherwise it's black (default).
More sophisticated behavior would require a symbol table -- I think
CodeWright's language lexers are not much (if any) more sophisticated
than regular expressions.

If that's all too confusing, you can turn coloring off if you so
desire.  In any case, I don't think you need a whole new editor -- At
least, not if you start with the right one.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Robert A Duff <bobduff@shell01.TheWorld.com> wrote:
> During the Ada 9X project, some folks suggested making [the random
> number generator subprogram be] a procedure.
> This was considered a non-starter, primarily because Fortran uses a
> function, and that's what people expect.  It is rather strange that
> (some of) the same language designers who choked at the idea of making
> Random a procedure were adamant about forbidding 'in out' params.

A quote about eating your own dog food comes to mind here...

It's not just expectations created by other languages which are a
problem here.  A few years ago I wrote a package which looked in
part like:

    package Buffered_IO is

       type Buffered_Input is tagged abstract limited private;

       -- A buffered input object reads data in large blocks for
       -- efficiency, similar to the C standard I/O library or the
       -- C++ "istream" type.  To read an input source, you first
       -- declare and initialize a type derived from Buffered_Input;
       -- The details of how you do this depend on where the data
       -- is coming from; see the child packages of Buffered_IO for
       -- details.  However, once an input source is opened, you can
       -- read it like you would expect:

       procedure Get(File : in out Buffered_Input'class;
                     Item : out Character);
       pragma inline(Get);
       procedure Get(File : in out Buffered_Input'class;
                     Item : out String);
       function End_Of_File(File : in out Buffered_Input'class)
                           return Boolean;

Oops, that last declaration is illegal.  But am I seriously going to
ask Ada programmers to write code like:

       loop
          End_Of_File(Input, EOF);
       exit when EOF;
          ...
       end loop;

I don't think so.  So I changed the paramter mode of End_Of_File to "in",
and used by GNAT to implement Ada.Numerics.Discrete_Random to allow the
parameter to be used like an "in out" parameter.
				Kenneth Almquist

Marin David Condic <nobody@noplace.com> writes:

> It would seem intuitively obvious to even the most casual observer
> that if you're not sure what a thing is *supposed* to do, you can't
> possibly be sure that it does it.  Unfortunately, this lesson is often
> learned at great financial (and sometimes human) expense.
>
> MDC

Indeed. I am a big proponent of formal methods and mathematical
proofs. But using these tools makes it even more important to get the
requirements correct, sound and complete.

- Mark Lorenzen

>
> Robert I. Eachus wrote:
>> The Airbus 320 should bury the idea that theorem provers can result
>> in safe software.  In the case of the Airbus 320 what happened was
>> that the formal logic used for stating the requirements/theorems was
>> relatively opaque to experts in the field (read pilots).  So the
>> flaws in the requirements, and later about 500 people, were buried
>> by that opacity.
>>
>
>
> -- 
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/
> My project is: http://www.jsf.mil/NSFrames.htm
>
> Send Replies To: m   o   d   c @ a   m   o   g
>                     c   n   i       c   .   r
>
>      "Face it ladies, its not the dress that makes you look fat.
>      Its the FAT that makes you look fat."
>
>          --  Al Bundy
>
> ======================================================================

Yeah, but as far as I can tell C always had "in only" parameters and 
everything was a function returning a result. The only way you could get 
"in out" mode was passing addresses (indistinguishable to the garden 
variety programmer from a 'Access) and of course dealing with all the 
errors that resulted from no checking that a parameter actually was an 
address. Such a setup didn't seem to hurt C with respect to popularity 
or getting Fortran programmers to understand it.

I'm ambivalent about "in out" for functions. I've never found it 
difficult to use functions just the way they are and can't think of a 
case where in-out would have helped me with a real world problem. The 
only example anyone ever seems to cite is the Random Number Generator 
leading me to think that maybe this *is* the only instance in which it 
is genuinely useful. OTOH, I could see how they might be included and 
not impact my life one iota. If you don't need it, you don't use it. 
Except that possibly it casts into doubt what happens in an expression 
loaded with function calls where one used to be able to assume that the 
parameters were not being modified. With in-out you'd have to know the 
parameter modes before you could interpret what the expression was doing.

MDC



Robert A Duff wrote:
> 
> As far as I can remember, this idea was considered, and was generally
> thought to be ugly.  I mean, suppose you're trying to convince a Fortran
> programmer to use Ada for numerics stuff.  If you start babbling about
> aliased and 'Access when there is no inherent need for pointers,
> they're going to laugh, and rightly so.
> 



-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Frank J. Lhota wrote:

> Was there any discussion of using access types, i.e.
> 
>     function Random (Gen : access Generator) return Result_Subtype;
> 
> This would require that each generator is aliased, and that 'Access
> attributes be used, but at least this would give some recognition to the
> fact that the generator is changed by the call.

Actually, and I think more interesting, was that we discussed making the 
generator parameter implicit, and having a per task generator value.

That idea was dropped because some people thought it would make calls to 
Random slower, and others were worried that it would force all compilers 
to support per task variables.  Per task variables did make it into Ada 
9X, but there is no standard way to use them with random number 
generators. I keep promising myself that someday I will have to write a
generic that does that, but it seems like using a sledgehammer to swat a 
fly.  Every time the issue comes up, it is easier to create a new 
generator object inside each task.

But notice that having a "default" generator would be either error prone 
in the presense of tasking, or slow because references would have to be 
via a protected object whether or not a program used random numbers in 
more than one task.  We avoided that mistake, and not by accident.  But 
it does create this anomaly that the "normal" random number generator 
interface does have this weird side effect on its parameter.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Hyman Rosen wrote:

> Scott Moore wrote:
> 
>> "safety critical C" is an oxymoron if I ever heard one.
> 
> 
> Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!

In every group that I participated in that ever discussed issues of code 
reuse from a systems perspective, the fact that an M1A1 tank was not an 
M1 tank was discussed.  (Substitute F-15 and F-15E for Air Force 
sponsored groups and so on.) The result, of course is that you may be 
able to reuse much of the code, but you CANNOT reuse the requirements 
analysis.  And if the requirements change, then the testing has to 
change. So even if you can reuse 100% of the code, that only saves 15% 
of the overall software costs.  Library reuse works on the other hand, 
but you have to invest in building the library independent of an 
particular development project.  If a reuse library contains software 
that matches your requirements, then you have a component that solves 
part of your problem and does not require a new test plan, test suite, 
and testing.  (You still need to perform system test however.)

Arianne 501 crashed because the bean counters tried to do software reuse 
without repeating the requirements analysis, and later cut out all 
system testing.  Oops!  Incidently the subsequent Arianne 5 failures 
followed almost identical fault trees, but they did not involve Ada code.


-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Robert I. Eachus wrote:
> Arianne 501 crashed because...

Yes, I know. But I'm also pretty sure that there's lots of
safety-critical code that's written in C. If someone is
going to mouth off with ignorant comments about C, I want
to make sure that I mouth off with ignorant comments about
Ada.

Hyman Rosen wrote:
> Robert I. Eachus wrote:
> 
> > Arianne 501 crashed because...
> 
> Yes, I know. But I'm also pretty sure that there's lots of
> safety-critical code that's written in C. If someone is going to
> mouth off with ignorant comments about C, I want to make sure
> that I mouth off with ignorant comments about Ada.

Neither of which is very helpful.  You might do well to recognize
that Ada has been designed to detect Stupid Human Tricks as far as
practicable, while C is designed to allow SHTs anywhere that they
are not demonstrably and immediately fatal.  At the same time I
expect Scott Moore has more experience with strongly typed and
relatively safe languages than you do.  I may be wrong.

Given a choice of two airline pilots, would you choose the one
whose sole experience has been stunt-flying and racing, or the one
who has been captaining an airliner without incident for a similar
length of time?  Would you alter your choice if 

 a) You want to get there in one piece or 
 b) You have to get there yesterday to prevent disaster or 
 c) Only one is available.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

CBFalconer wrote:
 > Ada has been designed...

That does not make safety-critical C an "oxymoron".

Marin David Condic <nobody@noplace.com> writes:

> Yeah, but as far as I can tell C always had "in only" parameters and
> everything was a function returning a result. The only way you could get
> "in out" mode was passing addresses (indistinguishable to the garden
> variety programmer from a 'Access) and of course dealing with all the
> errors that resulted from no checking that a parameter actually was an
> address. Such a setup didn't seem to hurt C with respect to popularity
> or getting Fortran programmers to understand it.

I've heard a lot of Fortran programmers complaining about C!

> I'm ambivalent about "in out" for functions. I've never found it
> difficult to use functions just the way they are and can't think of a
> case where in-out would have helped me with a real world problem. The
> only example anyone ever seems to cite is the Random Number Generator
> leading me to think that maybe this *is* the only instance in which it
> is genuinely useful.

It's a good example because it's familiar -- it's in the RM.

I can think of several other examples.  How about this one:

    function Get_Line(F: in out File) return String;

You can't make that a procedure, because Get_Line itself needs to
determine the length of the result, and 'out' parameters don't work that
way.  And even if they did, it's kind of nice to be able to say:

    X: constant String := Get_Line(F);

>... OTOH, I could see how they might be included and
> not impact my life one iota. If you don't need it, you don't use
> it.

I agree with that philosophy.  It is not the job of the language
designer to prevent people from doing evil things.  It is the job of the
language designer to prevent people from doing evil things *by
accident*.  You're not likely to declare 'in out' parameters by
accident, so it's fine to let the programmer decide when to use it.
(Probably not very often -- *most* functions should be free of side
effects.)

Except, as you say:

>... Except that possibly it casts into doubt what happens in an
> expression loaded with function calls where one used to be able to
> assume that the parameters were not being modified. With in-out you'd
> have to know the parameter modes before you could interpret what the
> expression was doing.

That's a good point, too.  You can't get any advantage out of having
side-effect-free functions unless you (the reader of the program) can
somehow *know* that they are side-effect-free.

I would be in favor of marking 'in out' and 'out' with some syntax at
the call site.  I would also be in favor of marking calls syntactically
if they have side effects on global variables.  But none of that has
anything to do with Ada (although there was an *optional* way to mark
'[in] out' in Green).

> MDC
> 
> Robert A Duff wrote:
> > As far as I can remember, this idea was considered, and was generally
> > thought to be ugly.  I mean, suppose you're trying to convince a Fortran
> > programmer to use Ada for numerics stuff.  If you start babbling about
> > aliased and 'Access when there is no inherent need for pointers,
> > they're going to laugh, and rightly so.

A: So I know what you're talking about without looking ahead.
Q: Why is top-posting a bad idea?
;-)

- Bob

Hyman Rosen <hyrosen@mail.com> writes:

> Robert I. Eachus wrote:
> > Arianne 501 crashed because...
> 
> Yes, I know. But I'm also pretty sure that there's lots of
> safety-critical code that's written in C.

Yes, of course.  There's plenty of hyperbole on usenet -- folks say
"X is impossible and Y is perfect" when the truth is,
"Y is better than X for certain purposes".

It's interesting that there are actually *very* few disasters caused by
the malfunction of safety-critical software (in *any* language).  At
least, compared to the number of malfunctions in software I use every
day on my desk.  Language is important, but it is far from the *only*
issue in ensuring safety.  And airplanes are not dropping out of the
sky all the time.

>... If someone is
> going to mouth off with ignorant comments about C, I want
> to make sure that I mouth off with ignorant comments about
> Ada.

;-)

This vaguely reminds me of the usenet game of "trolling", where one
tries to trick one's opponents into thinking oneself is a blithering
idiot.  I don't get it -- how can anybody get satisfaction out of that?

At least you said "nyah nyah" to let us know you were being sarcastic.

Sorry, this is getting off topic.  I'll shut up now.

- Bob

"Robert I. Eachus" <rieachus@comcast.net> writes:

[stuff about random number generator]

Note that Robert Eachus is truly an expert on random number issues.
I wouldn't know a good random-number generation algorithm if it bit
me on the behind.  ;-)  And I don't use them in my work.  I (and others)
were just using the "random" function as an example of a function that
returns a sequence, one at a time, where we believe it's OK to have
side effects (i.e. it's OK that the function returns a different value
each time it's called).

- Bob

In article <hYudnRZ2b6gYQGOi4p2dnA@comcast.com>, "Robert I. Eachus" <rieachus@comcast.net> writes:

> Arianne 501 crashed because the bean counters tried to do software reuse 
> without repeating the requirements analysis, and later cut out all 
> system testing.

From another point of view, they just opened the system testing process
up to the public view :-)

Larry Kilgallen wrote:

> From another point of view, they just opened the system testing process
> up to the public view :-)

Sorry, no.  If the course of Ariane 501 would have been slightly 
different, the launch would have succeeded.  But it would have said 
nothing about the likelihood that then next Airiane 5 launch would have 
succeeded.  In fact there have been three major failures in less than a 
dozen launches, with lots of originally needed testing done after each 
failure, and they still don't have a working system.  In the meantime, 
Ariane 4 (Remember, the one the software requirements were originally 
for?) has had about 100 launches with a very good record.

So the Ariane 5 is almost the poster child for doing reuse without 
redoing the systems requirements analysis from the top.   I would hope 
that no one would ever make that mistake again.  But the lesson that 
keeps being taught about the first Ariane 5 launch is about software 
validation.

Similarly the lessons learned in five Airbus 320 crashes are getting 
papered over.  It is by now clear to those who study such accidents, 
that all five accidents were probably caused by invalid requirements. 
For years Airbus has claimed that the software had been proven correct 
and couldn't have caused the crashes.  But finally enough has come out 
that the accident investigators are pretty sure they know exactly which 
requirements error caused which crash.

The Airbus 320 should bury the idea that theorem provers can result in 
safe software.  In the case of the Airbus 320 what happened was that the 
formal logic used for stating the requirements/theorems was relatively 
opaque to experts in the field (read pilots).  So the flaws in the 
requirements, and later about 500 people, were buried by that opacity.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Please, let us not start this Ariane 5 discussion again. There have been at
least 3 threads on this topic, and the later threads have done nothing other
than rehash the arguments from the first thread. There are enough reruns on
television, we don't need them in newsgroups. Unless one of us comes up with
something about Ariane 5 that has not been said here before, can't we just
move on?

It would seem intuitively obvious to even the most casual observer that 
if you're not sure what a thing is *supposed* to do, you can't possibly 
be sure that it does it.  Unfortunately, this lesson is often learned at 
great financial (and sometimes human) expense.

MDC

Robert I. Eachus wrote:
> 
> The Airbus 320 should bury the idea that theorem provers can result in 
> safe software.  In the case of the Airbus 320 what happened was that the 
> formal logic used for stating the requirements/theorems was relatively 
> opaque to experts in the field (read pilots).  So the flaws in the 
> requirements, and later about 500 people, were buried by that opacity.
> 


-- 
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/NSFrames.htm

Send Replies To: m   o   d   c @ a   m   o   g
                    c   n   i       c   .   r

     "Face it ladies, its not the dress that makes you look fat.
     Its the FAT that makes you look fat."

         --  Al Bundy

======================================================================

Mark Lorenzen wrote:

> Indeed. I am a big proponent of formal methods and mathematical
> proofs. But using these tools makes it even more important to get the
> requirements correct, sound and complete.

And that was exactly the problem in the Airbus 320 case.  The grumblings 
of the software designers about the opacity of the formal language used 
were ignored as "the difficulty of learning a new methodology."  The 
real problem was the lack of a formal method for converting the formal 
version of the requirements back into something that could be understood 
by the domain experts.

In government contracting we run into this problem all the time.  The 
contractor wants the "B"-specs, the mapping of the original 
specifications to the intended implementation, to be considered to 
replace the "A"-spec once the B-specs are accepted by the government. 
The government wants the testing done to the A-spec, not the B-spec.

The usual resolution is to delay government acceptance of the B-spec 
until the test plan is available to bounce off the original A-spec. 
Once that requirements tracability is complete, then the government 
allows the B-spec to be signed off as the specification to be 
implemented by the contractor.  But the government does not accept the 
B-spec requirements until they are sure that the test plan will result 
in coverage of the A-spec requirements.  I can't count the number of 
times that the MITRE project team I was on was tasked by the government 
to check that changes to the test plan still covered all the original 
(A-spec) requirements.  Often this was less than a day's work since the 
requirements mapping was still valid.  In other cases, approval dragged 
on for months since requirements changes had to be mapped back to the 
A-spec level.

What happened in the Ariane 501 case can be easily explained by 
referring to this model.  The original test plan covered the "real" 
A-spec.  But the full-up navigation system test called for in the test 
plan was later eliminated due to cost and schedule problems involving 
the test rig.  But no one "looked back" to see which A-spec requirements 
were to be tested by the eliminated test.  Of course, doing such an 
evaluation of the test plan change should have discovered the mismatch 
between the Ariane 4 derived requirements and the Ariane 5 system 
requirements.  (The change to the test plan substituted system testing 
for the upgraded INS for the Ariane 4 for the planned Ariane 5 guidance 
system test.)

This is what I like about the FFRDC (federally funded research and 
development corporation) model the US government uses.  Technically, the 
FFRDC does not work for the particular government agency that contracts 
for the development of whatever new system.  (Often the DoD, but also 
NASA, intelligence organizations, the DOE, and the FAA among others.) 
The FFRDC is charged by Congress with oversight of the project for 
technical and financial feasibility.  But in real day-to-day operations, 
this usually means keeping their eyes focused on the original goal.
If a project like the SSC (super-conducting supercollider) or the A-12 
(Navy stealth attack aircraft) goes out of control and is canceled by 
Congress there is egg on the face of the FFRDC involved.  (Fortunately 
not MITRE in those two cases.)

On the other hand, the FFRDC can go "around" the contracting agency 
directly to Congress when it first becomes clear that the risk 
associated with a project is too great. I've been involved in several of 
those calls.  Or the FFRDC can recommend spending and "extra" hundred 
million dollars or three now to ensure that the project doesn't flop 
later.  Again I have been involved in a few of those calls.  And once I 
even told the government (in this case the Air Force) that the risk was 
not that the contractor couldn't meet the current requirements, but that 
they would, and the government would be left buying an unusable system 
because the governments actual requirements had changed.

That is the other side of the "cost overrun" story.  Had the governments 
real requirements changed?  Yes.  Could the government have held the 
contractors feet to the fire and force them to meet the original 
requirements for the original price?  Yes.  But the government was 
better off negotiating a change order, knowing that the contractor would 
"recover" their previous cost overruns when pricing the change, than 
spending hundreds of millions for a now-useless system, and then putting 
the changes needed to fix it out for bid.

In case you are wondering what changes caused the problem, it was 
Goldwater-Nichols.  This bill changed the way the military responded to 
crises by decentralizing the responsibility to several commands. 
Currently the most well known is the Central Command, which was 
responsible for running the Gulf War, and invasions of Afghanistan and 
Iraq.  What was the problem?  The data presented to various commands and 
to the Pentagon in the original system could be different, since data 
would arrive at different locations via different routes.  But you 
didn't want say Central Command seeing a major threat, and the Pentagon 
(and the President) seeing different data.  We also didn't want to force 
all data to go through the national command authority so it was consistent.

The changes meant that the individual commands needed to know whether 
they were seeing the "full" picture, or damage to the network resulted 
in different commands having access to different data (or the same data 
at significantly different times).  In other words all the theater 
commands needed to see the network status, not just the one location 
responsible for maintaining the network.  It sounds like a minor change, 
but it wasn't.  The network of course was fault-tolerant, and 
maintenance, of course, needed to know which if any links had failed. 
The problem had two parts.  First the commands needed to be able to 
compute the network connectivity, including for links which did not 
directly affect them. This affected network topology and message routing 
for status messages.  Second, the commands needed to be able to do data 
fusion, and get the SAME results as everyone else, independent of 
network timing delays.  This required new data fusion algorithms, where 
the results were independent of the order the data was received.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush

Robert I. Eachus wrote:
> The Airbus 320 should bury the idea that theorem provers can result in 
> safe software.

It's always been my contention that writing the specifications which you
will then prove that a program obeys is exactly as hard as writing the
program itself.

In comp.arch.embedded Hyman Rosen <hyrosen@mail.com> wrote:
> Robert I. Eachus wrote:
> > The Airbus 320 should bury the idea that theorem provers can result in 
> > safe software.

Well, saying they can't result in safe software would be even wronger,
of course.  So I guess the real idea that has to be buried is that
they _will_ do so, just like that.

Or, in other words: no matter how good your tools, the GIGO principle
(garbage in, garbage out) still holds.

> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Which would appear to be one of many special cases of what we used to
call the "lemma on conservation of difficulty" among students here.
In the essence it says: "No truly difficult problems ever go away just
by waving some magical tool at them."

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:VK2Mb.2414$Qq.1124@nwrdny01.gnilink.net...
> Robert I. Eachus wrote:
> > The Airbus 320 should bury the idea that theorem provers can result in
> > safe software.
>
> It's always been my contention that writing the specifications which you
> will then prove that a program obeys is exactly as hard as writing the
> program itself.

Yes and no.

Yes, in that writing rigorous formal specifications is HARD WORK.

No, in that the effort you put into writing those rigorous formal specifications
almost always translates into significantly-reduced effort when writing the code
that implements those specifications, because now you have a SOLID
understanding, where you used to have only a sketchy understanding.