After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 127914 - wrong format specifier on LP64 systems in gimpimagefile.c
wrong format specifier on LP64 systems in gimpimagefile.c
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
1.x
Other OSF/1
: Normal major
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on: 113033
Blocks:
 
 
Reported: 2003-11-25 20:05 UTC by Tim Mooney
Modified: 2003-12-08 09:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tim Mooney 2003-11-25 20:05:17 UTC
gimp-1.3.23, glib-2.2.3, atk-1.2.4, pango-1.2.5, gtk+-2.2.4

While reviewing warnings from a build of gimp-1.3.23 earlier today, I noted
one that's a real problem, at least on LP64 systems:

cc: Warning: gimpimagefile.c, line 909: In this statement, this argument to
sscanf is of "pointer to int" type and is not appropriate for the
conversion specifier "%ld".  The value may overwrite other data or produce
unexpected results. (inptrtype)
  if (!option || sscanf (option, "%ld", &thumb_image_mtime) != 1)
----------------------------------------^
Comment 1 Sven Neumann 2003-11-25 20:17:50 UTC
So time_t is always an integer? I thought a long would be used.
Comment 2 Tim Mooney 2003-11-25 20:26:29 UTC
On Tru64/OSF1, time_t defaults to being a 32bit quantity (int), for
backwards compatibility.  You must specify additional preprocessor
defines to get the alternate 64 bit size for time_t, and functions
that expect a 64 bit quantity.

Other LP64 platforms (or LP64-capable platforms) like IRIX and Solaris
also may default to either a 32 bit quantity or a 64 bit quantity,
depending on all kinds of things (primarily preprocessor directives).
It's by no means assured that time_t will be a 64bit quantity, even on
"fully" LP64 systems.
Comment 3 Sven Neumann 2003-11-25 20:30:54 UTC
The thumbnail spec doesn't specify the size of the Thumb::MTime value:

 http://triq.net/~jens/thumbnail-spec/creation.html#ADDINFOS

The time is stored as a string so I think we should always use a 64bit
value. I will take this into account in the implementation that I am
working on for bug #113033.
Comment 4 Raphaël Quinet 2003-11-25 20:39:41 UTC
A quick workaround for this problem may be to store the results of the
sscanf into a temporary 64bit variable and then copy its value to a
time_t variable (which is easier to use later in the code).

By the way, I can confirm that a Solaris 8 system has some interesting
things in <sys/time.h>, such as #if defined(_SYSCALL32) and so on...
Comment 5 Sven Neumann 2003-11-25 20:46:12 UTC
That workaround is exactly what libgimpthumb will be doing.
Comment 6 Sven Neumann 2003-12-08 09:28:12 UTC
The new routines are now in CVS and replace the code in question:

2003-12-08  Sven Neumann  <sven@gimp.org>
        
   * app/core/gimpimagefile.[ch]: removed thumbnail handling routines
   and use libgimpthumb instead. Fixes bug #127914.