Hi Tim,
On Tue, Jul 1, 2008 at 2:37 PM, Tim Maxwell <timmaxw_at_gmail.com> wrote:
> Hi David and Arfrever,
>
> I'm sorry about letting that bug through. I hadn't tested the new
> libraryloader.py on Linux before committing it. I was going to ask David to
> do it, but I forgot. Arfrever's patch looks perfect to me.
No problem. You have made lots of great improvements to ctypesgen and
we really appreciate your work.
> On the same subject, do either of you know anybody with a Windows
> installation of ctypes? I still haven't tested the win32 branch of the
> library loader.
To test ctypesgen on Windows, I build the csvn Python bindings on
Linux and then copy the generated Python file to Windows. I just
tested the latest version of csvn on Windows (with your patches to
ctypesgen) and I was able to run the csvn test suite successfully.
> I think I fixed the NULL problem. I special-cased TypeCastExpressionNode to
> return None when 0 is cast to a pointer type.
Great! I tried re-running ctypesgen with your patch and it seems to
work. It converts NULL to None now. Note that NULL is defined twice in
functions.py:
NULL = None # <built-in>
# ... and later ...
# /usr/lib/gcc/x86_64-redhat-linux/4.1.2/include/stddef.h: 403
try:
NULL = None
except:
pass
Your patch converts ((void *) 0) to None. This works on my machine.
Note that your patch would not work if I had __cplusplus defined --
here is the code from stddef.h:
#undef NULL
#if defined(__cplusplus)
#define NULL 0
#else
#define NULL ((void *)0)
#endif
I don't know if worrying about the above case is important -- just
wanted to bring it to your attention. In general ctypesgen doesn't
work with C++ but maybe there is some situation where the above is
important.
> Can either of you think of a good way to handle typecasts in general?
I don't know how to handle typecasts in general, but I think that NULL
should be set to None regardless of what is present in their header
files. We might want to just hard code it and make sure it doesn't get
overridden.
> David, is autogen.py running ctypesgen with the --all-headers flag set? It
> seems to me that ctypesgen should not have used the declaration from the
> system header files because there was already a built-in definition. Not
> that it's a problem - I'm just wondering why it happened.
The all-headers flag is not set by autogen.py. I believe that the
definition for NULL was generated because there are macros in our
header files which reference NULL.
For example:
# /home/david/dj/svn/svn-apr13/include/apr-1/apr_pools.h: 273
def apr_pool_create(newpool, parent):
return (apr_pool_create_ex (newpool, parent, NULL, NULL))
> Attached are diffs for both of the fixes, along with another problem I
> noticed. I'm going to see about fixing the DeprecationWarnings in the
> tracebacks Arfrever sent and then commit a new revision.
Sounds good. I see that the DeprecationWarning mentions the subprocess
module, which is new in Python 2.4. Right now, I use Python 2.3 for
testing on Windows. Just wanted to mention that, just in case.
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-02 22:13:48 CEST