typedef OPJ_INT64 OPJ_OFF_T;

[GoogleCodeExporter]

Is this reasonable to use in all cases:

typedef OPJ_INT64 OPJ_OFF_T; 

what if the compiler/OS does not expose a 64bits fseek/fread API ?

Original issue reported on code.google.com by mathieu.malaterre on 19 Mar 2012 at 9:54

[GoogleCodeExporter]

Original comment by mathieu.malaterre on 25 Feb 2014 at 4:05

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Then I guess you simply get a compilation warning in opj_skip_from_file, 
opj_seek_from_file and opj_get_data_length_from_file, telling you that you're 
passing a 64bit integer to a function accepting a 32bit integer.

Such a build will anyway not be able to deal with large files.
What I do not know is if it gracefully errors out or crashes, when presented 
with a > 2GB file.

Original comment by julien.m...@gmail.com on 5 Mar 2014 at 4:21

[GoogleCodeExporter]

The incantations are in opj_includes.
To reproduce you need :
- Windows 95
- or Borland C
- or VC6
- or a Linux without LFS, which means a very old distro, not even likely to be 
running anywhere today.

Original comment by julien.m...@gmail.com on 5 Mar 2014 at 4:25

[GoogleCodeExporter]

The way it is done in openjpeg is the same as it is done in GraphicsMagick.

See :
http://sourceforge.net/p/graphicsmagick/code/ci/default/tree/magick/studio.h#l41
5
http://sourceforge.net/p/graphicsmagick/code/ci/default/tree/magick/magick_types
.h.in
http://sourceforge.net/p/graphicsmagick/code/ci/default/tree/magick/blob.c#l2655

Just to verify that there was no explicit cast when using the fseek macro.

Original comment by julien.m...@gmail.com on 5 Mar 2014 at 4:54

[GoogleCodeExporter]

Thanks for all the low level explanation. I can close this issue. Thx

Original comment by mathieu.malaterre on 6 Mar 2014 at 7:56

• Added labels: Milestone-Release2.0

[GoogleCodeExporter]

I can *actually* close this issue. Thx

Original comment by mathieu.malaterre on 7 Mar 2014 at 2:27

• Changed state: Fixed