This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.smith
Recipients benjamin.peterson, christian.heimes, dmalcolm, eric.smith, georg.brandl, gvanrossum, mark.dickinson, skip.montanaro
Date 2009-11-23.12:24:12
SpamBayes Score 2.5651135e-09
Marked as misclassified No
Message-id <1258979055.2.0.890470059833.issue7353@psf.upfronthosting.co.za>
In-reply-to
Content
MvL made this comment in
http://www.mail-archive.com/python-dev@python.org/msg43844.html

I'm copying it here so it doesn't get lost and because I think he makes
a good point that many people would miss (at least I didn't think of it).
-----------------------------------------------

The macros (unfortunately) allowed
to make non-obvious mistakes. Now that they are gone, people need to
really think of what precisely they want to do.

For example, consider

if (PyInt_Check(o)){
  long val = PyInt_AsLong(o);
  // process
} else if (PyLong_Check(o)) {
  long long val = PyLong_AsLongLong(o);
  // check for overflow
  // process
}

With intobject.h, this code would continue to compile, but work
incorrectly, as the second case will never be executed. It would
be better to port this as

#if Py2.x
if (PyInt_Check(o)){
  long val = PyInt_AsLong(o);
  // process
} else
#endif
if (PyLong_Check(o)) {

i.e. eliminating the int case altogether. For another example,

long foo = PyInt_AsLong(Foo);

has a hidden error in 3.x, with intobject: PyLong_AsLong might
overflow, which the 2.x case doesn't.

So eliminating intobject.h likely helps avoiding subtle errors.

Regards,
Martin
History
Date User Action Args
2009-11-23 12:24:15eric.smithsetrecipients: + eric.smith, gvanrossum, skip.montanaro, georg.brandl, mark.dickinson, christian.heimes, benjamin.peterson, dmalcolm
2009-11-23 12:24:15eric.smithsetmessageid: <1258979055.2.0.890470059833.issue7353@psf.upfronthosting.co.za>
2009-11-23 12:24:13eric.smithlinkissue7353 messages
2009-11-23 12:24:12eric.smithcreate