Re: where to handle python version mismatches?

"M. Levinson" <[email protected]> writes:

> But as I recall, I was still left wondering if there's a
> sufficiently portable way to determine whether a Py_ssize_t
> value could overflow an off_t when the len from
> PyString_AsStringAndSize() is passed to
> normalize_cache_entry(), which takes an off_t parameter.

Well, Py_ssize_t is supposed to be the same size as size_t, and
I think it's unlikely that anyone would define off_t as smaller
than size_t.

parse_bencoding_integer() does arithmetic with off_t and needs to
detect overflows.  It currently assumes that the numbers will
wrap around.  On recent versions of GCC, this requires
-fno-strict-overflow, which precludes some optimizations.  Other
compilers may require other options that I don't know about.  So
parse_bencoding_integer() should instead be changed to detect the
overflows before they happen (bug 1012).  For this, we'll need
OFF_MAX, which unfortunately does not seems to be in C99 or
POSIX.  So, I think ELinks should define OFF_MIN and OFF_MAX
(or similar ELinks-specific macros) in a header file, based on
sizeof(off_t); if that is not right for some machine, #ifdefs can
be added.  src/scripting/python/ could then use these as well.

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFILqQxHm9IGt60eMgRAsCnAJ9GTMN+f5H5Xzeu/aCWiTQiq6DRVgCbBfBl
9i7D02yd3Ws930510rmtwd0=
=QCAs
-----END PGP SIGNATURE-----