Re: [pypy-dev] [pypy-svn] r45269 - in pypy/dist/pypy/rpython/module: . tes
Hello again,
Author: fijal Date: Mon Jul 23 13:52:26 2007 New Revision: 45269
Modified: pypy/dist/pypy/rpython/module/ll_os.py pypy/dist/pypy/rpython/module/test/test_posix.py Log: Add os.uname. RPython level. segfaults ll2ctypes in some strange way, I'm not sure I want to know
Modified: pypy/dist/pypy/rpython/module/ll_os.py ============================================================================== --- pypy/dist/pypy/rpython/module/ll_os.py (original) +++ pypy/dist/pypy/rpython/module/ll_os.py Mon Jul 23 13:52:26 2007 @@ -110,6 +110,34 @@ register_external(os.setsid, [], int, export_name="ll_os.ll_os_setsid", llimpl=setsid_lltypeimpl)
+# ------------------------------- os.uname ------------------------------ + +if hasattr(os, 'uname'): + UTSNAMEP = rffi.CStruct('utsname', ('sysname', rffi.CCHARP), + ('nodename', rffi.CCHARP), + ('release', rffi.CCHARP), + ('version', rffi.CCHARP), + ('machine', rffi.CCHARP), + ('stuff', rffi.CCHARP))
I think the error comes from the ctypes interpretation of the structure. utsname is not made of char* pointers, but (at least on the debian machine I have access to) the members are actually fixed arrays of chars, the lengths of which are not public, but well specified in sys/utsname.h. It should make no difference when translated, because the code looks like v->sysname etc. ctypes on the other hand needs to know the precise sizeof and offsets of each member. I tried to modify the _socket module to also use rffi, and had the same problem. I think that we will need a tool similar to pypy.rpython.rctypes.tool.ctypes_platform, which generates and compiles C code to get the different sizes and offsets. (We will need support for C defines as well) Hope this helps, -- Amaury Forgeot d'Arc
Amaury Forgeot d'Arc wrote:
Hello again,
Author: fijal Date: Mon Jul 23 13:52:26 2007 New Revision: 45269
Modified: pypy/dist/pypy/rpython/module/ll_os.py pypy/dist/pypy/rpython/module/test/test_posix.py Log: Add os.uname. RPython level. segfaults ll2ctypes in some strange way, I'm not sure I want to know
Modified: pypy/dist/pypy/rpython/module/ll_os.py ==============================================================================
--- pypy/dist/pypy/rpython/module/ll_os.py (original) +++ pypy/dist/pypy/rpython/module/ll_os.py Mon Jul 23 13:52:26 2007 @@ -110,6 +110,34 @@ register_external(os.setsid, [], int, export_name="ll_os.ll_os_setsid", llimpl=setsid_lltypeimpl)
+# ------------------------------- os.uname ------------------------------ + +if hasattr(os, 'uname'): + UTSNAMEP = rffi.CStruct('utsname', ('sysname', rffi.CCHARP), + ('nodename', rffi.CCHARP), + ('release', rffi.CCHARP), + ('version', rffi.CCHARP), + ('machine', rffi.CCHARP), + ('stuff', rffi.CCHARP))
I think the error comes from the ctypes interpretation of the structure. utsname is not made of char* pointers, but (at least on the debian machine I have access to) the members are actually fixed arrays of chars, the lengths of which are not public, but well specified in sys/utsname.h.
It should make no difference when translated, because the code looks like v->sysname etc. ctypes on the other hand needs to know the precise sizeof and offsets of each member.
I tried to modify the _socket module to also use rffi, and had the same problem.
I think that we will need a tool similar to pypy.rpython.rctypes.tool.ctypes_platform, which generates and compiles C code to get the different sizes and offsets. (We will need support for C defines as well)
Hope this helps,
I think armin worked a bit on it. We need some more support for that I'm afraid. Let's dig... :.
From the manpage: The length of the arrays in a struct utsname is unspecified; the fields are terminated by a null byte (’’ ’). ??? I'm completely confused. :.
Hi Fijal, On Mon, Jul 23, 2007 at 02:38:32PM +0200, Maciek Fijalkowski wrote:
The length of the arrays in a struct utsname is unspecified; the fields are terminated by a null byte (?????? ???).
I'm completely confused.
It means that the structure looks like this in lltype notation: Struct('utsname', ('text1', FixedSizeArray(Char, 10)), ('text2', FixedSizeArray(Char, 20)), ...) where, annoyingly, the numbers '10' and '20' are platform-dependent and must be obtained by trying to compile snippets of C code using sizeof() and offsetof(). Or are you confused about the bit saying that the fields are zero-terminated? It just means that in the array, characters 0 to N-1 are non-null, charater N is null, and the rest of the characters are undefined. A bientot, Armin.
On 24.07.2007, at 18:08, Armin Rigo wrote:
Hi Fijal,
On Mon, Jul 23, 2007 at 02:38:32PM +0200, Maciek Fijalkowski wrote:
The length of the arrays in a struct utsname is unspecified; the fields are terminated by a null byte (?????? ???).
I'm completely confused.
It means that the structure looks like this in lltype notation:
Struct('utsname', ('text1', FixedSizeArray(Char, 10)), ('text2', FixedSizeArray(Char, 20)), ...)
where, annoyingly, the numbers '10' and '20' are platform-dependent and must be obtained by trying to compile snippets of C code using sizeof() and offsetof().
Or are you confused about the bit saying that the fields are zero-terminated? It just means that in the array, characters 0 to N-1 are non-null, charater N is null, and the rest of the characters are undefined.
Which reminds us to implement this carefully and not to rely on the terminating byte, or we will open the door to buffer overflow exploits :-) ciao - chris -- Christian Tismer :^) <mailto:tismer@stackless.com> tismerysoft GmbH : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9A : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 802 86 56 mobile +49 173 24 18 776 fax +49 30 80 90 57 05 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/
Christian Tismer wrote:
On 24.07.2007, at 18:08, Armin Rigo wrote:
Hi Fijal,
On Mon, Jul 23, 2007 at 02:38:32PM +0200, Maciek Fijalkowski wrote:
The length of the arrays in a struct utsname is unspecified; the fields are terminated by a null byte (?????? ???).
I'm completely confused.
It means that the structure looks like this in lltype notation:
Struct('utsname', ('text1', FixedSizeArray(Char, 10)), ('text2', FixedSizeArray(Char, 20)), ...)
where, annoyingly, the numbers '10' and '20' are platform-dependent and must be obtained by trying to compile snippets of C code using sizeof() and offsetof().
Or are you confused about the bit saying that the fields are zero-terminated? It just means that in the array, characters 0 to N-1 are non-null, charater N is null, and the rest of the characters are undefined.
Which reminds us to implement this carefully and not to rely on the terminating byte, or we will open the door to buffer overflow exploits :-)
ciao - chris
I personally don't think that implementation of uname() might be a security hazard - if kernel really wants to hack us it can for sure :] Cheers, fijal :.
participants (4)
-
Amaury Forgeot d'Arc -
Armin Rigo -
Christian Tismer -
Maciek Fijalkowski