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-Thread: 103376,5b3cb1d740c0b77f
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!zeus.visi.com!news-out.visi.com!petbe.visi.com!news.octanews.net!ash.uu.net!spool.news.uu.net!not-for-mail
Date: Wed, 30 Jun 2004 12:16:28 -0400
From: Hyman Rosen <hyrosen@mail.com>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: ANN: New technical paper from Ada Europe 2004 now available
References: <cf2c6063.0406300646.49f0848c@posting.google.com>
In-Reply-To: <cf2c6063.0406300646.49f0848c@posting.google.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Organization: KBC Financial Products
Message-ID: <1088612188.693737@master.nyc.kbcfp.com>
Cache-Post-Path: master.nyc.kbcfp.com!unknown@nightcrawler.nyc.kbcfp.com
X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/)
NNTP-Posting-Host: 204.253.250.10
X-Trace: 1088612188  14361 204.253.250.10
Xref: g2news1.google.com comp.lang.ada:2008
Date: 2004-06-30T12:16:28-04:00
List-Id: <comp.lang.ada>

Rod Chapman wrote:
> "High-Integrity Ada in a UML and C World", Peter Amey and Neil White

The automatically generated C in this paper contains

     typedef Colour_ADT_RGB_Value Colour_ADT_Colour[3];
     void Colour_ADT_SWAP(Colour_ADT_Colour *A, Colour_ADT_Colour *B)
     {
         Colour_ADT_Colour Temp;
         memmove((void*)Temp,(void*)A,6);
         memmove((void*)A,(void*)B,6);
         memmove((void*)B,(void*)Temp,6);
     }

Those memmoves exhibit bad C style.

First of all, the casts to void * are unnecessary; in C any pointer
converts automatically to void * and no cast is needed.

Second, coding an explicit 6 for the memmove size is bad practice.
It would make the code unportable to funny architectures such as
some DSPs where the compiler has sizeof(int) = 1.

Third, memmove guarantees that copies of overlapping objects work;
for this case, the more efficient memcpy is better, because there is
no possibility of overlap.

Fourth, the parameters are pointers to arrays, so it's more coherent
stylistically to pass &Temp to the copy function rather than plain
Temp, even though the effect is the same.

It would be much nicer for the code to read

     memcpy(&Temp, A, sizeof(Colour_ADT_Colour));
     memcpy(A, B, sizeof(Colour_ADT_Colour));
     memcpy(B, &Temp, sizeof(Colour_ADT_Colour));