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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 108717,a7c8692cac750b5e X-Google-Thread: 103376,703c4f68db81387d X-Google-Attributes: gid108717,gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newshub.sdsu.edu!logbridge.uoregon.edu!usenet01.sei.cmu.edu!nntp.ece.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail From: "Arthur J. O'Dwyer" Newsgroups: comp.programming,comp.lang.ada Subject: Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)) Date: Sun, 13 Mar 2005 19:48:52 -0500 (EST) Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: References: <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> <1110396477.596174.285520@o13g2000cwo.googlegroups.com> <112vb2t8eonuhed@corp.supernews.com> <1110422108.925127.54110@o13g2000cwo.googlegroups.com> <11329cb96h2p19f@corp.supernews.com> <113394jjvppao64@corp.supernews.com> <1133s3qnmqmbjfb@corp.supernews.com> <4232a9f7$0$26552$9b4e6d93@newsread4.arcor-online.net> <11369p5jrcc6835@corp.supernews.com> <1110697151.726709.276550@l41g2000cwc.googlegroups.com> NNTP-Posting-Host: smtp.andrew.cmu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: bb3.andrew.cmu.edu 1110761333 26563 128.2.10.82 (14 Mar 2005 00:48:53 GMT) X-Complaints-To: advisor@andrew.cmu.edu NNTP-Posting-Date: 14 Mar 2005 00:48:53 GMT In-Reply-To: <1110697151.726709.276550@l41g2000cwc.googlegroups.com> Xref: g2news1.google.com comp.programming:17923 comp.lang.ada:9344 Date: 2005-03-14T00:48:53+00:00 List-Id: On Sun, 12 Mar 2005, jimmaureenrogers@worldnet.att.net wrote: > Arthur J. O'Dwyer wrote: >> This example does not appear to contain any buffer oveflow. >> If you think it does, please point it out to me. I may have >> missed something. >> > > Ok, I understand why he made p and q with N+1 elements. > This allows him to point past the Nth element without > leaving either p or q's allocated space. Right. (That's still a weird way of putting it... /obviously/ you need more than N elements in an array if you're going to be accessing the N+1th element! :) > Nonetheless, > the data element in the highest position of those arrays > has not been initialized. This is not the best practice. /None/ of the data elements of 'p' or 'q' has been initialized. The array elements all have indeterminate (undefined) value until they have been assigned-to in the 'do_array' routine. (And then, IIRC, it's the /first/ elements of 'p' and 'q' that still don't receive values. But I'm not looking at the code right now.) >> On Sun, 13 Mar 2005, Jim Rogers wrote: >>> >>> procedure Do_Array(X : Combiner) is >>> PA : Element_Ptr; >>> begin >>> Pa := X.P; -- assign all elements of X.P to Pa >> >> Um... surely there's a better way to do this! Are you really >> copying N references here, or is something going on more subtle >> than the comment indicates? > > That is exactly what I am doing, which matches nicely with the > actions taken in the C code for the function setup_array: > > void > setup_array( > int * x[N2], > int p[N+1], > int q[N+1] > ) > { > int i; > for(i=0; i< N;i++){ > x[i]-&p[i]; > x[i_N]=&q[i]; > } > } > > This appears to also be copying two sets of N pointers. Yes, but only once. You put the same code inside 'Do_Array', which IIRC gets called 10_000 times inside the main loop. As I read the C code, the point of 'setup_array' (assuming the whole program made sense, which it doesn't) is to avoid having to do tedious calculations inside 'do_array'. But your code is doing an O(N) copy operation inside 'do_array'! >>> Pa(2).all := 1; -- Assign 1 to the second value in the array >> >> For my own edification: Am I correct in thinking that the ".all" >> is superfluous in this expression? > > Not at all. This is equivalent to the C syntax > *(p[1]) = 1; Where '.all' corresponds to C's '*' operator, right. I thought I recalled reading that Ada would infer the '.all' to make the types work out in some cases (similarly to Algol?); either I read wrong, or this just isn't one of those cases. -Arthur