Re: [RFC] Crash sourcing Python script on Windows

[John Spencer <maillist-gdbpatches@barfooze.de>]

On 09/29/2011 03:01 AM, Paul_Koning@Dell.com wrote:
>> At long last, I forced myself to look into this. I had noticed that "source script.py" did not work on Windows, and resulted in the debugger crashing.  It turns out that the problem came from the fact that I was using a binaries from python.org where the definition of type FILE difers from the definition our compiler uses.  The crash occurs when trying to call PyRun_SimpleFile with a FILE created by GDB.
>>
>> The approach we took is to create a new FILE descriptor using Python routines, thus making sure that the FILE is compatible with PyRun_SimpleFile.  There were two such calls, so we wrote a wrapper to that function that only takes a filename, and creates the FILE on the fly.  This avoids code duplication.
> That sounds like a good solution.  I'm puzzled though -- how did FILE end up being different?  One would expect the right header files to be used, producing correct/consistent results.  If that didn't happen in this case, could it happen for other aspects of the GDB to Python API?
>
> 	paul
>
FILE is supposed to be an opaque type and as such noone except of the 
libc which defines it is supposed to "poke" at its internals.
however it is common practice in GNU software to assume everybody uses 
GLIBC and poke around in internal stuff thats not supposed to be 
accessibly at all in userland. another example of such illegal behaviour 
is libevent, which does illegal things with fd_set internals to allow 
more than FD_SETSIZE file descriptors to be used with select().