In article <4656F2E4.68CDB793@yahoo.com>, CBFalconer says...
> Colin Paul Gloster wrote:
> > Robert Adsett <sub2@aeolusdevelopment.com> posted:
> >
> > "[..]
> > 
> > Also fairly trivially reported with PC-Lint
> > [..]
> > e:\cygwin\home\radsett\newlib-lpc\test2.c  46  Warning 632: Assignment
> > 
> > to
> >     strong type 'quantity_of_oranges_type' in context: assignment
> > 
> >                                                         |
> >                             oranges_in_handbag /*Oops.*/;
> > e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 639: Strong
> 
> Not readable, due to lack of proper quoting, excessive line
> lengths, etc.  Please fix your newsreader.

I won't argue on the quoting, but any line length issues originated with 
me.  Cut and paste from PC-Lint's error output and wrapped during post 
by the newsreader.

> Please do not top-post.  Your answer belongs after (or intermixed

He also didn't top-post.  It just looked thay way.

Robert

-- 
Posted via a free Usenet account from http://www.teranews.com

Colin Paul Gloster wrote:
> Robert Adsett <sub2@aeolusdevelopment.com> posted:
>
> "[..]
> 
> Also fairly trivially reported with PC-Lint
> [..]
> e:\cygwin\home\radsett\newlib-lpc\test2.c  46  Warning 632: Assignment
> 
> to
>     strong type 'quantity_of_oranges_type' in context: assignment
> 
>                                                         |
>                             oranges_in_handbag /*Oops.*/;
> e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 639: Strong
>                             type
>     mismatch for type 'quantity_of_apples_type' in binary operation
> 
> e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 639: Strong
> type
>     mismatch for type 'quantity_of_oranges_type' in binary operation
> 
> e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 632: Assignment
> 
> to
>     strong type 'quantity_of_apples_type' in context: assignment
> [..]"

Not readable, due to lack of proper quoting, excessive line
lengths, etc.  Please fix your newsreader.

Please do not top-post.  Your answer belongs after (or intermixed
with) the quoted material to which you reply, after snipping all
irrelevant material.  See the following links:

-- 
  <http://www.catb.org/~esr/faqs/smart-questions.html>
  <http://www.caliburn.nl/topposting.html>
  <http://www.netmeister.org/news/learn2quote.html>
  <http://cfaj.freeshell.org/google/>  (taming google)
  <http://members.fortunecity.com/nnqweb/>  (newusers)



-- 
Posted via a free Usenet account from http://www.teranews.com

In article <MPG.20beb62fda5adbc7989744@free.teranews.com>, Robert Adsett 
<sub2@aeolusdevelopment.com> writes
>In article <f31fo4$slp$1@newsserver.cilea.it>, Colin Paul Gloster
>says...
>
>This is as far as I got with your post, I'm afraid your quoting style
>makes the rest incomprehensible.
>
>Robert

I keep telling him this but in a discussion on the use of compiler 
languages in safely critical work he keeps using an unreadable (ie 
dangerous) style of quoting that is indecipherable to most others.

Chris

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

In news:MPG.20beb62fda5adbc7989744@free.teranews.com ,
Robert Adsett <sub2@aeolusdevelopment.com> posted:
"[..]

Also fairly trivially reported with PC-Lint
[..]
e:\cygwin\home\radsett\newlib-lpc\test2.c  46  Warning 632: Assignment

to
    strong type 'quantity_of_oranges_type' in context: assignment

                                                        |
                            oranges_in_handbag /*Oops.*/;
e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 639: Strong
                            type
    mismatch for type 'quantity_of_apples_type' in binary operation

e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 639: Strong
type
    mismatch for type 'quantity_of_oranges_type' in binary operation

e:\cygwin\home\radsett\newlib-lpc\test2.c  48  Warning 632: Assignment

to
    strong type 'quantity_of_apples_type' in context: assignment
[..]"

Thanks.

CBFalconer wrote:
> Chris Hills wrote:
> ... snip ...
>> With good processes and project management C is as effective as Ada.
>> This is because people use the correct tools with a C compiler and
>> use the language responsibly.
>>
>> If you really want to you can make a pigs ear of it with Ada too.
> 
> Snippet:
> 
>    char array[MAXi];
>    int  i;
>    ...
>    for (i = 0; array[i]; i++) continue;
> 
> Please show me the C system that detects the possible overrun at
> compile time, or at any time before execution, when it either
> aborts or needs added code.
> 

gcc 4.3 has this feature:

http://gcc.gnu.org/gcc-4.3/changes.html (look under "C Family")

Of course, gcc 4.3 is not yet released.

> However, when i is properly declared as 0..MAXi, the detection is
> immediate.  C lacks this facility.
> 

I definitely agree that this sort of thing is something that C is 
missing.  If you want to get the best out of lint, you have to add extra 
lint-specific comments with this sort of range information - it would be 
far better if it were included in the C language itself.  This would 
give three things (in order of importance) - it would let the programmer 
be clearer about his/her intentions in the code, it would let the 
compiler do better checking, and it would let the compiler generate 
better code in some cases.

Another thing I'd like is an Ada-like ability to get information about a 
type (either from the type name, or from a variable), such as the 
highest value of a enumerated type.  In Pascal, and Ada, you can write 
the equivalent of:

typedef enum { white, black, orange, blue } colours;
typedef struct { uint_8 red, blue, green; } rgbStruct;
static rgbStruct rgbs[colours];

Thus you have an array sized and indexed by the enumerated type.

You can get some way towards this using C++, but it's not easy to do so 
without run-time costs.

Al Balmer wrote:
> CBFalconer <cbfalconer@yahoo.com> wrote:
> 
>> Snippet:
>>
>>   char array[MAXi];
>>   int  i;
>>   ...
>>   for (i = 0; array[i]; i++) continue;
>>
>> Please show me the C system that detects the possible overrun at
>> compile time, or at any time before execution, when it either
>> aborts or needs added code.
> 
... snip ...
> 
> You don't want a computer to do stupid things, don't write stupid
> code.

What's stupid about that code?  It is effectively strlen.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

On Tue, 22 May 2007 17:11:26 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Chris Hills wrote:
>> 
>... snip ...
>> 
>> Do you have any evidence to counter the claim that C can be as
>> safe as Ada?
>
>C doesn't range check.  That should suffice.

So what ?

If a language detects an out of range condition, what does it do ? 

If it generates an exception, is there any guarantee that this
exception is handled in any sensible way ? Look for instance at the
first "spectacular" Ariane 5 launch :-).

In systems, in which you just can not give up and display a blue
screen etc., you really have to design the software in such a way that
it survives unexpected events. 

In practice, it is much easier to code the error cases in the main
program flow than using a huge exception handler, which first tries to
figure out what happened and then tries to figure out, how to get out
of this, without crashing the system.

Paul

Chris Hills wrote:

> In article <20070523.7998760.BF4D@mojaveg.lsan.mdsg-pacwest.com>,
> Everett M. Greene <mojaveg@mojaveg.lsan.mdsg-pacwest.com> writes
>>Paul Keinanen <keinanen@sci.fi> writes:
>>> Chris Hills <chris@phaedsys.org> wrote:
>>>
>>> >I still can't find an IEE magazine with an item on 61508 which showed
>>> >that coding errors are a very small part of the over all list of errors
>>> >and that given a good process the errors in different languages fall
>>> >into insignificance.
>>>
>>> Isn't this obvious ?
>>
>>And what about the management failures?  Most programming projects
>>fail due to errors such as trying to solve the wrong problem, too
>>few resources for the amount of effort required, etc.  The choice
>>of programming language has no impact on this either.
> 
> 
> This is correct.  These affect all projects no matter the language used.
> 
> With good processes and project management C is as effective as Ada.
> This is because people use the correct tools with a C compiler and use
> the language responsibly.
> 
> If you really want to you can make a pigs ear of it with Ada too.

With a lack of Chris finding the magazine article he was seeking I thought I
would see what I could turn up with a bit of Googling. The links below lead
to some interesting material (one saying that it doesn't matter about
language and one arguing that it does - but the latter sells Spark-Ada).

        <http://www.sesltd.com/expertise_safety.aspx>
        <http://crpit.com/confpapers/CRPITV47Thomas.pdf>

Also another paper has an interesting view on languages for Safety Critical
Systems.

        <http://www.nlr.nl/id~4463/lang~en.pdf>

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

On Thu, 24 May 2007 09:22:42 -0400, CBFalconer <cbfalconer@yahoo.com>
wrote:

>Snippet:
>
>   char array[MAXi];
>   int  i;
>   ...
>   for (i = 0; array[i]; i++) continue;
>
>Please show me the C system that detects the possible overrun at
>compile time, or at any time before execution, when it either
>aborts or needs added code.

If you want to see me, you do the travel. However, I suspect that you
can easily find another C programmer in your vicinity who would detect
this error at compile time, or even before.

You don't want a computer to do stupid things, don't write stupid
code.

-- 
Al Balmer
Sun City, AZ