Message 101

Re: Sort Merge

Message-ID: <3BD4ABC3.6070603@cs.cmu.edu>
Date: Mon, 22 Oct 2001 19:29:07 -0400
From: Spiros Papadimitriou <spapadim+@cs.cmu.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011012
MIME-Version: 1.0
To: Neal Burns <nburns@andrew.cmu.edu>
Cc: bb+academic.cs.15-721@andrew.cmu.edu
Subject: Re: Sort Merge
References: <Pine.LNX.3.96L.1011022183022.2045A-100000@surreal>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Maybe you are being overly pedantic, but that's immaterial! :-)

As I said, as long as your code produces the same muti-set,
then your *algorithms* are fine.  So, whether you do the (admittedly
weird) strcat() that the Minibase reference implementation does
or properly concatenate the record byte strings...

BTW, since you are suggesting a "solution"...  I did not try
your code, but I believe it
1. Could be shorter (man snprintf).
2. Completely forgets the end-of-string (and *might* result in a crash,
    incl. the "reference solution" which does the strcat()).

Spiros

Neal Burns wrote:

>Again not to be overly pedantic, but something is broken here. SMJTester.C
>defines a record as
>
>struct _rec {
>       char    key [4];
>       char    filler[4];
>};
>
>and the sizes of the fields as
>
>static short   attrSize[] = { 4, 4 };
>
>which makes sense. Then it writes 4 spaces to the filler field of each
>record, and writes a four byte ASCII number to the key field with sprintf:
>
>sprintf(rec.key, "%4d", data[i][j]);
>
>which actually writes 5 bytes, 4 bytes of padded number + a '\0'
>character, which overflows into the first byte of filler. So if you
>concatenate the records with memcpy(3), the test code will only print one
>key from each record because it runs into a NUL character in the fifth
>byte.
>
>If you use strcat(3), the test code will print the keys from both tuples
>in the composite record, but it will lop off the filler because it's
>hidden behind NUL zeroes.
>
>None of this is terribly important, but if it confuses you like it did me,
>this may save you time and pain in figuring out what's going on.
>
>If the TA's want to fix the test code to make it work the way it was
>apparently supposed to, they might want to consider something like this in
>createFiles():
>
>memset(rec.filler, ' ', 4); // pack filler with spaces
>
>char prebuf[5]; // enough to hold the number and the trailing NUL
>sprintf(prebuf, "%4d", data[i][j]);
>memcpy(rec.key, prebuf, 4); // copy exactly 4 bytes
>
>Hope this helps, have a nice day:).
>
>Neal
>
>On Mon, 22 Oct 2001, Spiros Papadimitriou wrote:
>
>>Well, I guess this is a trivial point, but since it makes more sense
>>to change 2 lines in the Perl script that will run the tests than
>>ask (possibly) each and every one of you to change 2 lines in
>>your code... :-)  So, yes, leave your code as it is.  Or to put it
>>differently, if your code outputs the same multi-set of numbers...
>>
>>Incidentally, to solve the "mystery", this is what the solution
>>code does (I guess the vars need no explanation):
>>        strcpy(RecordO, RecordR);
>>        strcat(RecordO, RecordS);
>>Go figure... ;-)
>>
>>Spiros
>>
>>
>>
>
>