const correctness patch

[GoogleCodeExporter]

Here's a new patch to make the API const correct - but this time I
identified the one position where it's appropriate to cast away the
constness. I still made tp_string_.val const as it seemed the right thing
to do.

Original issue reported on code.google.com by allef...@gmail.com on 10 May 2008 at 4:24

Attachments:

• const_correctness_patch2.diff

[GoogleCodeExporter]

Should o.string.info.s also be const?  Also, what compilation flag does this 
appease?
 Maybe add it into setup.py so we know what we're fixing.

Also, if I'm understanding correctly, this patch is good because if you are 
coding
something with #include "tinypy.c" and using some strict const flag, it will 
work,
right?  Does it offer other benefits as well?  I'd like to understand it as 
well as
possible.

Original comment by philhas...@gmail.com on 19 May 2008 at 2:57

[GoogleCodeExporter]

It's just so I can use the -Wwrite-strings option with gcc when including 
tinypy.h in
my own code. I'm compiling tinypy.c into a library, so I don't care about its 
const
correctness too much as I can leave out the option there - just my own code has 
to
include tinypy.h so it should have the "const"s :)

And no, there's no other benefit as far as I know. A C compiler can do different
optimizations sometimes when it knows a pointer cannot be used to modify the 
data it
points to, but I guess those cases are very rare.

Still, seems most projects try to keep things const correct. E.g. the Python C 
API
also defines functions like this, with the const to indicate that the string 
you pass
to the function will not be written to:

PyObject* Py_BuildValue(const char *format, ...)

Original comment by allef...@gmail.com on 19 May 2008 at 8:38

[GoogleCodeExporter]

I've applied this patch.  I also made the few changes need in tinypy to make the
whole thing compile with -Wwrite-strings, which I guess is good.

Original comment by philhas...@gmail.com on 20 May 2008 at 4:22

• Changed state: Verified