_elementtree.c warnings under 64-bit Windows #53992

Activity

1. pitrou commented on Sep 6, 2010

   

   pitrou

   on Sep 6, 2010

   MemberAuthor

   More actions

   Some of these warnings could be serious (e.g. the one where the 64-bit "self" is converted to a 32-bit "long"):

   13>..\Modules\_elementtree.c(696) : warning C4244: 'function' : conversion from 'Py_uintptr_t' to 'long', possible loss of data
   13>..\Modules\_elementtree.c(1239) : warning C4244: '=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
   13>..\Modules\_elementtree.c(1372) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
   13>..\Modules\_elementtree.c(1414) : warning C4244: '+=' : conversion from 'Py_ssize_t' to 'int', possible loss of data
   13>..\Modules\_elementtree.c(2076) : warning C4267: 'initializing' : conversion from 'size_t' to 'int', possible loss of data
   13>..\Modules\_elementtree.c(2663) : warning C4244: 'function' : conversion from 'Py_ssize_t' to 'int', possible loss of data
2. pitrou

   added

   extension-modulesC modules in the Modules dirC modules in the Modules dir

   OS-windows

   buildThe build process and cross-buildThe build process and cross-build

   on Sep 6, 2010
3. loewis commented on Sep 12, 2010

   

   loewismannequin

   on Sep 12, 2010

   Mannequin

   More actions

   Instead of

     PyLong_FromLong((Py_uintptr_t) self);

   use

      PyLong_FromVoidPtr(self);

   For the others, I suggest making length and allocated Py_ssize_t; this is likely a pervasive change. Of course, very few people will currently run into XML documents where some element has more than 2**31 children... You would need several TiB of main memory to represent it using ElementTree.

   Fredrik, please indicate whether it is ok to make this kind of change, or whether it would need your explicit approval.
4. janglin commented on Sep 24, 2010

   

   janglinmannequin

   on Sep 24, 2010

   Mannequin

   More actions

   bpo-9783.diff provides a patch that will compile clean on 32 and 64 bit Windows systems. I tried to avoid explicit casts where I could, but it was not always possible. I have ported a lot of my company's code to 64 bit (all Windows based). In my experience many warnings are because of programmers using the int type in places where a size_t may be more appropriate. Most of the warnings here are due to mixing int and Py_ssize_t types.
5. loewis commented on Sep 24, 2010

   

   loewismannequin

   on Sep 24, 2010

   Mannequin

   More actions

   bpo-9783.diff provides a patch that will compile clean on 32 and 64
   bit Windows systems. I tried to avoid explicit casts where I could,
   but it was not always possible. I have ported a lot of my company's
   code to 64 bit (all Windows based). In my experience many warnings
   are because of programmers using the int type in places where a
   size_t may be more appropriate. Most of the warnings here are due to
   mixing int and Py_ssize_t types.

   I think the patch is incorrect as it stands: the casts may cause
   truncation. As you say, int is still being used where size_t was
   more appropriate, so I think we should change it in that manner
   (e.g. make element_resize accept Py_ssize_t).

   In cases where we really can't propagate Py_ssize_t to (e.g.
   XML_Parse), we need to check for an int overflow, and raise
   an exception if it does overflow.
6. janglin commented on Sep 25, 2010

   

   janglinmannequin

   on Sep 25, 2010

   Mannequin

   More actions

   Martin is correct about this patch.

   In cases where we really can't propagate Py_ssize_t to (e.g.
   XML_Parse), we need to check for an int overflow, and raise
   an exception if it does overflow.

   Is this an appropriate approach?

   int
   PySize_AsInt(Py_ssize_t value)
   {
       if (value > (Py_ssize_t)INT_MAX || value < (Py_ssize_t)INT_MIN) {
           PyErr_SetString(PyExc_OverflowError, 
                           "Size value can not be represented as an integer");
       }
       return (int)value;
   }

   I would only define this when sizeof(Py_ssize_t) > sizeof(int) of course. In other cases it would be a macro that just evaluates to value.
   I would most likely need an unsigned version as well (although not for this particular issue).

   This code could be used in many C modules. Where in the Python code base should such functions be placed?
7. florentx commented on Jul 21, 2012

   

   florentxmannequin

   on Jul 21, 2012

   Mannequin

   More actions

   This warning is not specific to the _elementtree module.
   See related issue bpo-9566.
8. florentx

   closed this as completedon Jul 21, 2012
9. ezio-melotti

   transferred this issue fromon Apr 10, 2022