[gdal-dev] port/md5 cvs_MD5*

[Even Rouault]

On mercredi 20 décembre 2017 06:39:37 CET Kurt Schwehr wrote:
> My personal opinion...
> 
> It was not in fact in the core of GDAL for all users.  My primary
> environment does not include the WMS *driver*.  My take is that only the
> memory and gtiff raster drivers are really required for GDAL (vector, I'm
> not so sure).
> 
> What do you mean by the same or similar for generic and geojson?  And
> because something isn't great elsewhere, that does not mean we want to
> introduce more similar code that is hard to impossible to opt out of.
> 
> Dmitry's question about a reasonable solution is a good one (if you buy my
> being seriously uncomfortable with cvs_MD5*).  Possibilities include:
> 
> - Make everything from md5.cpp and md5.h be internal to md5.cpp (aka static
> or inline) and move CPLMD5String to md5.{cpp,h} at least keeping the
> trouble localize
> - Refactor md5 to be cleaner
> - Reimplement md5 hashing for gdal
> - Find some other code that is license compatible that is cleaner
> 
> And why are you exposing this to python?  Python has md5 hashing already
> built in.
> 
> Can others please weigh in?

For consistency with the rest, I'd suggest:
- rename md5.* to cpl_md5.*
- rename cvs_MD5* to CPLMD5*
- include cpl_port.h in cpl_md5.h and remove the #if defined(CPL_BASE_H_INCLUDED) stuff. 
Currently if someone includes md5.h as the first header, cvs_uint32 will expand to a unsigned 
long, whereas the md5.cpp file has been compiled with GUInt32. Not good

Other follow-up cleanups can then be done by interested parties.

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171220/27ca01d6/attachment-0001.html>