Delphi Puzzles

In Windows, resource names have to be in all caps. 'Bitmap1' is not a legal resource name, but 'BITMAP1' is.

However, that's not the complete answer, because this code will work - the API for dealing with resource will take the uncapitalized names and work with them as if they were capitalized. But if the name of the resource as saved in the executable (or in the .res file that gets compiled into the executable) is not in all caps, the resource will never be found, and an exception will be raised.

Further considerations:

Older versions of Delphi came with the Image Editor that would edit the image data in .res files. Whenever you would rename a resource, it would save the resource name in all caps, no matter what you typed. BUT, when you clicked "New Bitmap" to create a new bitmap resource, it would create the bitmap with the resource name 'Bitmap1' (or whatever number was next), and would NOT translate that into uppercase letters. Oops!

Review:

1. Resources must be stored with all-uppercase names.

2. Make sure you rename resources in the image editor, because the default names are broken.

This one was actually based on code I wrote, and a bug I created. It wasn't in Delphi though, but the logic error I created was interesting enough to make a note and turn it into a puzzle. When I translated the buggy code into Delphi, it behaved exactly the way I expected. Then I translated the fix, and it did NOT behave the way I expected. That is, there was another bug.

...and that's what you got for this puzzle.

The problem here is one of assumption. That assumption is that if you don't assign any value to ShowRec.Length, then it will be zero. Our programmer may have assumed this because he thought the compiler would produce a zeroed-out array, or perhaps he assumed that the caller would zero out the array. In any case, that's not what happened, and his array was full of random numbers - leftover memory from another lifetime.

As we look at the code, the problem arises on line 28, when Times[I].Length is accessed. At first this seems ok, because we set Length back on line 18. But then if conditions allow us to get to line 31, we set ShowName, but not length. Length will be garbage. When we loop back and get to line 26, ShowName is set, so we pass the condition, and then get to line 28 where we access Length which is (!) garbage. It could be 0, it could be 1, it could be 4097234, it could even be $CAFEBABE. Whatever it is, if it's greater than 30, it's going result in a value for Blocks that will cause the J loop to execute many more times than we want it to.

When that happens, we'll see the array fill up with references to a single show. Instead of watching House for one hour, we'll be seeing it 17 hours a day. Come to think of it, that might not be such a bad thing....

The solution?

Our first instinct might be to add after line 31:

But that actually results in the same problem, just with more predictable but equally useless values for Length. In a nutshell, Length can ONLY be set for the first member of the array representing a show. It has to be zero for the subsequent members.

So, there's our answer:

If you think about it, this makes sense. Our assumption was that the array would have zeros anywhere that we didn't assign a value. We know that's not true, so we need to put the zeros there ourselves.

BONUS QUESTION FOR THE WEEKEND:

If the compiler isn't putting zeros in the length field, it stands to reason that it's also not putting empty strings in the ShowName field where we don't assign it. Why didn't that cause an access violation or some other nasty?

Peter has missed the double meaning of the NOT operator. He wants to see all of the students that do not have a grade over 60, so he uses this line to see if the grade is where he wants it:

What Peter doesn't realize is that in this case, the NOT operator isn't going to tell him if his expression is not true, but rather is going to return the bitwise NOT of CalculateGrade. If the grade is 40, the bitwise NOT will be -41, (assuming that the grade is expressed as an integer). A student with a grade of 40 will still be included in the list.

BUT, the bitwise NOT of 70 is -71, so a student with a passing grade of 70 will also be included in the list of failing students, and Peter's program receives a failing grade.

Once Peter realized this, he changed his code:

A few weeks later, Peter was looking at the same code again, and realized he could make it even more precise:

If only he'd done that in the first place, he never would have gotten confused.

Sarah's mistake was in the way she moved through the records in her table. She started with the basic pattern of iteration through a table:

Table1.First;


while not Table1.EOF do


begin


  {process record here}


  Table1.Next;


end; 

Then she added code to check the record and delete it if its CreationDate was before January 1, 1998. The problem is that calling Table1.Delete deletes the current record AND moves ahead to the next record.

By calling Table1.Next right after calling Delete, Sarah created code that would skip over every record immediately after a record that needed to be deleted. If there are two records in a row that are older than 10 years , only the first would be deleted; the second would remain.

Sarah fixed the code by making her statement into an if..else:

if Table1.FieldByName('CreationDate').AsDateTime <


    EncodeDate(1998, 1, 1) then


  Table1.Delete


else


  Table1.Next; 

When you try to compile this code, you get an error message that isn't much help. The compiler stops on the message handler declaration with the error "Invalid message parameter list."

What the compiler wants to see is the message parameter modified as a var parameter: