AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
May 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2009.05.16 05:38 "Potential problem in libtiff when compiled in MinGW", by Ari Jolma
2009.05.16 23:46 "Re: Potential problem in libtiff when compiled in MinGW", by Bob Friesenhahn
2009.05.17 08:51 "Re: Potential problem in libtiff when compiled in MinGW", by Ari Jolma
2009.05.17 09:30 "Re: Potential problem in libtiff when compiled in MinGW", by Ari Jolma
2009.05.17 16:44 "Re: Potential problem in libtiff when compiled in MinGW", by Bob Friesenhahn
2009.05.17 18:02 "Re: Potential problem in libtiff when compiled in MinGW", by Ari Jolma

2009.05.17 09:30 "Re: Potential problem in libtiff when compiled in MinGW", by Ari Jolma

Ari Jolma kirjoitti:
> Bob Friesenhahn kirjoitti:
>   
>> On Sat, 16 May 2009, Ari Jolma wrote:
>>
>>     
>>> As I've explained in a GDAL bug report
>>> http://trac.osgeo.org/gdal/ticket/2649, it is not enough to use WIN32
>>> and _MSC_VER to determine whether to use %I64 instead of %ll as MinGW
>>> uses msvcrt.dll but does not define _MSC_VER. This is an issue in
>>> several places in libtiff sources (tif_dumpmode.c, tif_luv.c, tif_lzw.c,
>>> tif_print.c, tif_read.c, tif_strip.c, and tif_thunder.c).
>>>       
>> Have you verified that this is an actual problem?  My experience with 
>> MinGW builds is that 'long long' works, including in printf type 
>> specifications.  I am not sure how MinGW accomplishes that but MinGW 
>> does provide a thin library which could do transformations if required.
>>     
>
> I have not, I'll try to put together a test. In the GDAL case there was 
> a verifiable problem, whose investigation led me to infer that this is 
> generally a problem, but admittably this may be a bit different. I'll be 
> back later.
>   

Here's a test:

#include "tiffiop.h"

main() {
    thandle_t fd;
    int i = 1;
    unsigned long long occ = 1;
    for (i = 1; i < 11; i++)
        occ *= 10;
    TIFFErrorExt(fd, "module", "test unsigned long long with I64: 
%I64u", occ);
    TIFFErrorExt(fd, "module", "test unsigned long long with ll:  %llu", 
occ);
}

testing:

ajolma@MOON /c/dev/libtiff/libtiff
$ gcc test.c -I libtiff/ -L libtiff/.libs/ -ltiff

ajolma@MOON /c/dev/libtiff/libtiff
$ ./a.exe
module: test unsigned long long with I64: 10000000000.
module: test unsigned long long with ll:  1410065408.

i.e., %ll does not work but %I64 works in MinGW. This is because MinGW 
uses msvcrt.dll, which is Microsoft, which.. see for example 
http://ascending.wordpress.com/2008/04/22/long-long-on-windows-dev-c-mingw/

Ari



> Ari
>
>   
>> Bob
>> -- 
>> Bob Friesenhahn
>> bfriesen@simple.dallas.tx.us, 
>> http://www.simplesystems.org/users/bfriesen/
>> GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
>>     
>
>
>   


-- 
Prof. Ari Jolma
Environmental Management Information Technology
Teknillinen Korkeakoulu / Helsinki University of Technology
tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland
Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi