Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #18800 > unrolled thread

Ctypes compatibility

Started byEvan Driscoll <edriscoll@wisc.edu>
First post2012-01-10 21:20 -0600
Last post2012-01-10 21:20 -0600
Articles 1 — 1 participant

Back to article view | Back to comp.lang.python


Contents

  Ctypes compatibility Evan Driscoll <edriscoll@wisc.edu> - 2012-01-10 21:20 -0600

#18800 — Ctypes compatibility

FromEvan Driscoll <edriscoll@wisc.edu>
Date2012-01-10 21:20 -0600
SubjectCtypes compatibility
Message-ID<mailman.4624.1326252057.27778.python-list@python.org>

[Multipart message — attachments visible in raw view] — view raw

Might as well ask another question of the list.

I've written a ctypes-based Python wrapper around the 'readdir'
function. (I want access to the dt_type field of the result, without
calling stat().)

However, it feels very... fragile. What happens on a different *nix
which uses a different size of integers? Is Linux even consistent
between 32 and 64 bits? (That's a rhetorical question.) What happens on
a different *nix with the fields in a different order, or without a
dt_type field?

It somehow feels wrong that you get way less help with this than you
would get even from C. Is that just how it is with ctypes? Or is there
some way around it? I'm sort of tempted to write a C module whose sole
purpose is to wrap readdir...

Evan


[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web