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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f849b,b8d52151b7b306d2
X-Google-Attributes: gidf849b,public
X-Google-Thread: 103376,a00006d3c4735d70
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2003-12-30 15:59:36 PST
Path: 
 archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!mail.nartron.COM!not-for-mail
From: iddw@hotmail.com (Dave Hansen)
Newsgroups: comp.arch.embedded,comp.lang.ada
Subject: Re: Certified C compilers for safety-critical embedded systems
Date: Wed, 31 Dec 2003 00:03:28 GMT
Message-ID: <3ff20cc8.635997032@News.CIS.DFN.DE>
References: <3fe00b82.90228601@News.CIS.DFN.DE> <3FE026A8.3CD6A3A@yahoo.com>
 <x0%Db.16$_l6.25998@news.uswest.net>
 <3bf1uvg2ntadvahfud2rg6ujk24sora6gr@4ax.com>
 <2u3auvogde8ktotlaq0ldiaska3g416gus@4ax.com> <bs62ph$giu$1@newshost.mot.com>
 <20619edc.0312221020.3fd1b4ee@posting.google.com>
 <b5feuv06s2nmpakq0o1b7v0kpd450v3eli@4ax.com>
 <20619edc.0312222106.3b369547@posting.google.com>
 <45cs9hAbLc6$EAAx@phaedsys.demon.co.uk> <3fe9f0d7.104475725@News.CIS.DFN.DE>
 <FaLTFYBFof6$EAVI@phaedsys.demon.co.uk>
 <5802069.JsgInS3tXa@linux1.krischik.com>
 <1072464162.325936@master.nyc.kbcfp.com>
 <1563361.SfB03k3vvC@linux1.krischik.com>
 <11LvOkBBXw7$EAJw@phaedsys.demon.co.uk> <3ff0687f.528387944@News.CIS.DFN.DE>
 <1086072.fFeiH4ICbz@linux1.krischik.com> <3ff18d4d.603356952@News.CIS.DFN.DE>
 <1731094.1f7Irsyk1h@linux1.krischik.com> <3ff1b8ef.614528516@News.CIS.DFN.DE>
 <3FF1E06D.A351CCB4@yahoo.com>
NNTP-Posting-Host: mail.nartron.com (216.65.187.224)
X-Trace: news.uni-berlin.de 1072828775 1266548 216.65.187.224 ([97677])
X-Newsreader: Forte Free Agent 1.21/32.243
Xref: archiver1.google.com comp.arch.embedded:6409 comp.lang.ada:3973
Date: 2003-12-31T00:03:28+00:00
List-Id: <comp.lang.ada>

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.