[Baypiggies] ctypes presentation material online
spmcinerney at hotmail.com
Fri May 12 23:47:50 CEST 2006
(Sure, most people have fond experiences of debugging in C/C++, a language
where weakly typed pointer arithmetic plus implicit type conversions gives
you enough rope to hang yourself a thousand times over.
Before I settled on Python in the year 2000, one of my motivations was
avoiding C pointer debugging andn memory management. In fact my formative
evangelizing experience in finally deciding to go to Python was a
frustrating 2 months attempting to use CompuWare Boundschecker (overpriced
at $499, underfeatured and brain-dead) on some memory leaks in some of my
MSEE project code under a tight deadline and getting nowhere fast. Never
My point in this case is that although 'len (str + 1)' is syntactically
legal, if you had any sort of heuristic in a type checker, it would flag
'str + 1' as being semantically dubious (it might be legal, but then it
might not be, so it merits closer scrutiny).
I know exactly what the C effect of len(str + 1) will be: you'll undercount
the length of the string by 1, which is a creeping bug, (unless *str ==
'\0', in which case you get a stray pointer and a nonsense length, then you
get a blatant bug).
The problem here is that the language types and the compiler do not
discriminate between length, length + 1 being integers, whereas str, str +
1 are addresses - it's all represented by 32bits. It would be interesting to
see a heuristic chart of the probability that each of different types of
pointer arithmetic are semantically correct.
I've used and scripted linters in several languages (C, Verilog) in
production flows and a key lesson I learned is to search for and flag not
just the outright illegal stuff, but the dubious stuff. Intermediate
variables, explicit casts and/or linter pragmas are a good practice (in
Static type checking is neat, and if done across language wrapper boundaries
could be even neater. I think this is a topic of potential interest to a
lot of people? (GUI folks too, for sure)
Wrapping Fortran libraries seems to be pretty similarly painful (e.g.
Jeffrey Whitaker's NAGpy
More information about the Baypiggies