Long types in GraphicsMagick
Bob Friesenhahn <[email protected]> Wed, 3 Oct 2007 12:29:25 -0500 (CDT)
| Newsgroups | gmane.comp.video.graphicsmagick.apis |
|---|---|
| Message-ID | <Pine.SOC.4.64.0710031204430.7786@freddy> |
>From its ImageMagick-heritage, GraphicsMagick uses a profusion of 'long' and 'unsigned long' types in its API and implementation. The code has been verfied to work in traditional LP64 (long and pointer 64 bit) environments. While it may seem nice that the apparent capacity of the implementation expands for 64-bit applications, the actual capacity increase contributed by 64-bit longs is probably not realizable in my lifetime. Consider that a 32 bit type allows dimensions of at least 2,147,483,647 (or 4,294,967,295 if it is unsigned). When compiled for 64-bits, the current API supports images with dimensions 9,223,372,036,854,775,807 by 9,223,372,036,854,775,807, which is more than most people need at the moment. The 64-bit version of Windows does not use the LP64 64-bit scheme. Instead they use a scheme in which 'long' remains 32-bit but pointers are 64-bit. I am considering using explicit sized types in the GraphicsMagick API. With this change, 'long' and 'unsigned long' would change to a 32-bit type regardless of if the application is 32 or 64 bit. The 32-bit API would be the same, but the 64-bit API would be altered. Larger types would be used in the implementation when it is useful to do so. Pointer arithmetic would take care to use the correct sized type. The Magick++ C++ API has always used 32-bit types even though there may be 64-bit types underneath so there should be no user-visible change to this API. Does anyone see a significant problem with this? Would it negatively imact your software if 'unsigned long' types were changed to a fixed-size typedef like 'magick_uint32_t'? Bob ====================================== Bob Friesenhahn [email protected], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/