Re: Breaking the 10-limit : Problems/Questions for Windows build

Hi Jean-Philippe (and others),

Op Saturday 19 April 2008 17:16:43 schreef Annick et Jean-Philippe:
> Hi, all, again.
>
> As promised, this is the second half of the "no maximum number of
> interfaces for Torcs modules" patch (too big for Torcs-devel list).
> You can apply it after or before the first half, as you want ... the result
> will be the same.
>
> As an illustration, and also an example of how to use the new feature
> in a robot code, you will also find a patch that adds an 11'th car
> to the "bt" robot (I could not keep myself from choosing the Ford GT 40
> Concept, with its so gorgeous sound !).
>
> Please, test it and tell me what you think !
> Feel free to comment, propose more, ...
>
> Cheers,
>
> Jean-Philippe.
>
> PS: Tested on Linux Mandriva 2008.0 GCC 4.2.2 rc x86_64
>            and Windows XP SP2 VC6 SP6

I only read your patch, I didn't actually test it (will do later), but I think 
there is at least one problem with it.

It is about the function linuxModLoad. What should it do? It should load the 
module and return if it was succesfull. So, at some point this function is 
called. Then the caller only knows if loading the module was succesfull or 
not. So it must obtain the data of the loaded module on another way. This is 
done by an assumption: modules are always placed in front of the list. So, by 
dereferencing the module list, it gets the module which has just been loaded.

But as far as I can see, you break that assumption. If a module is already 
loaded, nothing happends. Because raceinit.cpp in raceengineclient use that 
assumption, it will assign the wrong robot to a car, and proberbly causes 
crashes in some cases.

Of course, there also is an (easy) solution: if a module is already loaded, 
move it to the front.

It is possible that one library can be loaded by several sopath's. Think about 
a relative path and a absolute path. I don't see any circumstanses where this 
could happen in Torcs. And even if it happends, it will work the same way as 
it works now. I think documenting this assumption is a good idea.

I see that you check if calloc was succesfull. It means that Torcs doesn't 
directly crash if the computer is out of memory. Is this a good thing?

Regards,

Mart

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone