Commit Graph

17 Commits

Author SHA1 Message Date
Alexander
ab92adf7c9 move ImagingNewEpilogue functionality to ImagingNewPrologueSubtype
doublechecked: no im->image or im->image8 or im->image32 access
between ImagingNewPrologue and ImagingNewEpilogue anywhere
2017-08-06 14:12:55 +03:00
Alexander
fd9cf03d01 FIX memory leak
ImagingNewEpilogue now is always success
The Imaging object itself is freed through ImagingDelete in case
when memory is not allocated in ImagingNewBlock or ImagingNewArray
2017-08-06 14:12:55 +03:00
hugovk
a662443b7f Avoid division by zero 2017-02-22 08:28:20 +02:00
wiredfool
7d6f4104a1 Map.c check should be against PY_SSIZE_T_MAX (#2151) 2016-10-04 07:16:17 -07:00
wiredfool
c50ebe6459 Map.c overflow fixes 2016-10-03 07:27:02 -07:00
wiredfool
72c45e6f5d Fix Fatal Python error: UNREF invalid object in debug builds
PyObject_Del() should only be called on the self object in
a dealloc call, not after failing to make a new object.
Replace with Py_DECREF, which eventually calls PyObject_Del()

http://bugs.python.org/issue3299#msg78740
https://mail.python.org/pipermail/python-dev/2003-February/033258.html
2016-05-30 03:16:16 -07:00
Nicolas F
052ea606bf Clean up defines and includes for Windows
1)  Renamed USE_INLINE to PIL_USE_INLINE to avoid conflicts with
    other headers/libraries.

2)  Replace __WIN32__ and WIN32 with _WIN32

3)  Don't define WIN32 when the compiler is MSVC but not on Windows
    Why would you even...

4)  Don't define strcasecmp if you're not even going to use it.

5)  Don't include Windows.h with undefs for compilers newer than
    1998 everywhere.

6)  Don't surpress warnings for MSVC++ 4.0. People still using
    MSVC++ 4.0 deserve it.

7)  Don't include things that are already included in Windows.h
2014-05-09 21:05:30 +02:00
Eric Soroos
631612edc6 mixed 8ch tabs + spaces -> 4 space indent 2013-12-13 15:13:43 -08:00
Eric Soroos
954d1ae435 int->Py_ssize_t, fixes #436 2013-12-13 15:13:19 -08:00
Alex Clark
bb1b3a532c Cleanup WS, courtesy of @Arfrever
find * -type f "-(" -name "*.bdf" -o -name "*.c" -o -name "*.h" -o -name "*.py" -o -name "*.rst" -o -name "*.txt" "-)" -exec sed -e "s/[[:space:]]*$//" -i {} \;
2013-06-30 18:42:19 -04:00
Bryant Mairs
9f82f025dc Modified map.c to fix some MSVC10 compilation errors. 2013-01-10 08:52:47 -06:00
Brian Crowell
a8599e8bb2 py3k: Remove ancient Python hacks 2013-01-10 08:46:57 -06:00
Brian Crowell
af5228896a py3k: Add module initialization and unicode/bytes int/long thunks
This commit:

* Adds Python 3 module initialization functions. I split out the main init
  of each module into a static setup_module function.
* Adds a py3.h which unifies int/long in Python 3 and unicode/bytes in
  Python 2. _imagingft.c unfortunately looks a little kludgy after this
  because it was already using PyUnicode functions, and I had to mix and
  match there manually.

With this commit, the modules all build successfully under Python 3.

What this commit does NOT do is patch all of the uses of PyArg_ParseTuple
and Py_BuildValue, which all need to be checked for proper use of bytes
and unicode codes. It also does not let selftest.py run yet, because there
are probably hundreds of issues to fix in the Python code itself.
2013-01-10 08:46:37 -06:00
Brian Crowell
804095ecb3 py3k: Use new buffer protocol
Other ports have taken advantage of the fact that Python 3 has wrappers for
the old buffer protocol, but there's a significant disadvantage: you can't
let the buffered object know when you're done with it.

Since Python 2.6 supports the new protocol, we just go ahead and move to
it.
2013-01-10 08:46:35 -06:00
Brian Crowell
9519013466 py3k: Modernize type declarations
This updates several Python type definitions and uses to bring us closer
to Python 3 compatibility. This includes:

* Replacing staticforward and statichere with static. These were a hack for
  old compilers and are not supported/needed anymore.
* Using Py_TYPE() instead of ob_type; ob_type is hidden in Py3.
* Replacing getattr with getters/setters. getattr is sort-of supported in
  Py3, but Py_FindMethod is not. So we just use the newer
  methods/getsetters mechanisms and start using PyType_Ready everywhere.
* Use PyVarObject_HEAD_INIT for types, since types are PyVarObject.
* Use PyMODINIT_FUNC for module initialization functions.

There are some tab/space issues in this commit. I'm set for spaces; the
source is a little schizo.
2013-01-10 08:46:34 -06:00
Matti Picus
2ba3bf681d UNDEF more types before including windows headers 2012-03-09 00:00:04 +02:00
Alex Clark
9a640e3157 Forking PIL 2010-07-30 22:52:47 -04:00