[rfk-dev] compiling rfk for 32-bit x86

[David Griffith]

On Mon, 19 Nov 2012, Eric S. Raymond wrote:

> David Wolever <david at wolever.net>:
>> Alright, found the bug. Here's a reasonable patch to fix it (although I can't say with certainty that it's definitely the most reasonable):
>>
>> diff --git a/src/robotfindskitten.c b/src/robotfindskitten.c
>> index 7074273..4afd34e 100644
>> --- a/src/robotfindskitten.c
>> +++ b/src/robotfindskitten.c
>> @@ -354,7 +354,7 @@ void init ( unsigned int num ) {
>>         unsigned int i, j, temp;
>>
>>         /* allocate memory */
>> -       if ( ! ( state.items = calloc ( num, sizeof ( screen_object ) ) ) ) {
>> +       if ( ! ( state.items = calloc ( num + 2, sizeof ( screen_object ) ) ) ) {
>>                 fprintf ( stderr, "Cannot malloc.\n" );
>>                 exit ( EXIT_FAILURE );
>>         }
>
> Ah, the glory and wonder that is memory management in C.  Sorry about that.
> I was trying to simplify the code by removing several special cases in
> screen-object handling.  I never saw this blow up on my 64-bit machine.
>
> One amendment: the constant 2 should be SPECIALS, which is a macro for the
> number of {robot, kitten} objects in case that ever changes.

While the change probably is a good idea, it doesn't seem to fix or even 
address the crashes I've been getting.  Those appear to be coming from 
ncurses.  I've tried this on a Thinkpad T42, a desktop using an Athlon XP, 
and a Raspberry Pi.

-- 
David Griffith
dgriffi at cs.csubak.edu

A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?