From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,
	PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,ad06d2d7cb045687
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Received: by 10.68.135.231 with SMTP id pv7mr12586796pbb.8.1328578567987;
        Mon, 06 Feb 2012 17:36:07 -0800 (PST)
MIME-Version: 1.0
Path: 
 lh20ni268763pbb.0!nntp.google.com!news1.google.com!goblin3!goblin1!goblin.stu.neva.ru!news.tornevall.net!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Silly and stupid post-condition or not ?
Date: Mon, 6 Feb 2012 19:36:02 -0600
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <jgpv66$6ha$1@munin.nbi.dk>
References: <op.v8w6ptk5ule2fv@douda-yannick>
 <82wr86fzos.fsf@stephe-leake.org>
 <5af407fc-2868-44ca-84d2-c51a2a64104d@o4g2000pbc.googlegroups.com>
 <82k445fu9n.fsf@stephe-leake.org> <jgfjc4$u4b$1@munin.nbi.dk>
 <82ty36urik.fsf@stephe-leake.org> <jgl7k6$lp1$1@munin.nbi.dk>
 <op.v87eozlaule2fv@douda-yannick>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1328578566 6698 69.95.181.76 (7 Feb 2012 01:36:06 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Tue, 7 Feb 2012 01:36:06 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Date: 2012-02-06T19:36:02-06:00
List-Id: <comp.lang.ada>

"Yannick Duch�ne (Hibou57)" <yannick_duchene@yahoo.fr> wrote in message 
news:op.v87eozlaule2fv@douda-yannick...
Le Sun, 05 Feb 2012 07:29:21 +0100, Randy Brukardt <randy@rrsoftware.com>  a 
�crit:
>> A large part of the problem that I see with proof tools is that they 
>> often
>> require peeking into the body to verify calls. This is just plain wrong,
>> because it means that the proof has to be redone if the body changes. And 
>> it
>> also means that the body has to exist (and in a near-final form) before 
>> the proof can be valuable.
>
>Seems strange assertion.
>
>With SPARK, you prove the implementation is conforming to its

Sorry, I was talking about "some" proof tools, not any specific one. And 
recall that I was specifically answering a query about why seeing the body 
was not good enough. SPARK is *not* seeing the body, so none of what I said 
applies to it. But there are a lot of "correctness" tools out there that 
only work with complete source code.

                                 Randy.