From: Joerg H. <jo...@de...> - 2004-03-16 19:18:31
|
Hi I've seen in several files unter libexif/, that sizeof(long) is assumed to be 4 bytes. On all 32bit plattforms this is true, but on linux and 64bit plattforms (x86-64, alpha, sparc64, ...) it is 8 bytes in size. I'll try to convert to that to uint32_t, which is always 32 bits in size. Maybe all references to exif_get_short to exif_get_uint16, too? This would be the most portable and consequent way to do this. Joerg -- Fachbegriffe der Informatik (Nr 313): Next Generation Ada - Ada'Succ(s). Derek Mahony |
From: Hans U. N. <gp...@n-...> - 2004-03-18 14:46:22
|
Hi Joerg :-) Joerg Hoh <jo...@de...> writes: > I've seen in several files unter libexif/, that sizeof(long) is assumed to > be 4 bytes. On all 32bit plattforms this is true, but on linux and 64bit > plattforms (x86-64, alpha, sparc64, ...) it is 8 bytes in size. > > I'll try to convert to that to uint32_t, which is always 32 bits in size. > Maybe all references to exif_get_short to exif_get_uint16, too? This would > be the most portable and consequent way to do this. Definitely. For formats of a fixed size, one should always use u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake and #ifdef magic. Gru=DF, Uli --=20 Some gphoto2 links: http://www.teaser.fr/~hfiguiere/linux/digicam.html http://gphoto.sf.net/ http://n-dimensional.de/projects/digicam/ #gphoto on irc.freenode.net http://sf.net/projects/gphoto http://sf.net/projects/libusb http://sf.net/projects/libexif |
From: Joerg H. <jo...@de...> - 2004-03-19 09:52:27
|
Tach Hans Ulrich On Thu, Mar 18, 2004 at 03:45:52PM +0100, Hans Ulrich Niedermann wrote: > > Definitely. For formats of a fixed size, one should always use > u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake > and #ifdef magic. I've looked into exif-utils.h and did small changes to: typedef char ExifByte; /* 1 byte */ typedef char * ExifAscii; typedef uint16_t ExifShort; /* 2 bytes */ typedef uint32_t ExifLong; /* 4 bytes */ typedef struct {ExifLong numerator; ExifLong denominator;} ExifRational; typedef char ExifUndefined; /* 1 byte */ typedef int32_t ExifSLong; /* 4 bytes */ typedef struct {ExifSLong numerator; ExifSLong denominator;} ExifSRational; Now, all problems should disappear. Only some printf-Statements, which need format modifier for eg ExifLong, are throwing warnings. Are there any specifier for uint32_t which can be used with printf and friends? Joerg |
From: Jan P. <pa...@pi...> - 2004-03-19 15:54:53
|
Joerg, unless you equip libexif with definitions of uint16_t, uint32_t and int32_t, this "simple" change will break compilability for many platforms. E.g. MSVC does not know such types (is it in some latest C++ standard?). --- Jan > On Thu, Mar 18, 2004 at 03:45:52PM +0100, Hans Ulrich Niedermann wrote: > > > > Definitely. For formats of a fixed size, one should always use > > u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake > > and #ifdef magic. > > I've looked into exif-utils.h and did small changes to: > > typedef char ExifByte; /* 1 byte */ > typedef char * ExifAscii; > typedef uint16_t ExifShort; /* 2 bytes */ > typedef uint32_t ExifLong; /* 4 bytes */ > typedef struct {ExifLong numerator; ExifLong denominator;} ExifRational; > typedef char ExifUndefined; /* 1 byte */ > typedef int32_t ExifSLong; /* 4 bytes */ > typedef struct {ExifSLong numerator; ExifSLong denominator;} > ExifSRational; > > > Now, all problems should disappear. Only some printf-Statements, which > need format modifier for eg ExifLong, are throwing warnings. Are there > any specifier for uint32_t which can be used with printf and friends? > > Joerg |
From: Joerg H. <jo...@de...> - 2004-03-19 16:29:55
|
On Fri, Mar 19, 2004 at 04:54:43PM +0100, Jan Patera wrote: > Joerg, > > unless you equip libexif with definitions of uint16_t, uint32_t > and int32_t, this "simple" change will break compilability for many > platforms. E.g. MSVC does not know such types (is it in some latest C++ > standard?). Hm, where are my bookmarks? ... http://anubis.dkuug.dk/JTC1/SC22/WG14/www/docs/n897.pdf page 28 (37 in the pdf) says "C9X also allows extended integer types (see §7.8..." In paragraph 7.8 "the purpose of <inittypes.h> is to provide a set of integer types whose definitions are consistent across machines and independent of operating systems and other implementation idiosyncarsies..." It seems to me that this is a part of C99 and therefor all modern C compilers should implement it. I don't know, if VC is compatible with C99. Joerg -- Fachbegriffe der Informatik (Nr 203): Öffentliche Adressverzeichnisse - Spammers Umschreibung für das Usenet. Marc Haber |
From: matthieu c. <cas...@fr...> - 2004-03-19 17:49:49
|
Jan Patera wrote: >Joerg, > >unless you equip libexif with definitions of uint16_t, uint32_t >and int32_t, this "simple" change will break compilability for many >platforms. E.g. MSVC does not know such types (is it in some latest C++ >standard?). > > --- Jan > > > >>On Thu, Mar 18, 2004 at 03:45:52PM +0100, Hans Ulrich Niedermann wrote: >> >> >>>Definitely. For formats of a fixed size, one should always use >>>u?int(8|16|32)_t. If required, ship a _stdint.h and do some automake >>>and #ifdef magic. >>> >>> >>I've looked into exif-utils.h and did small changes to: >> >>typedef char ExifByte; /* 1 byte */ >>typedef char * ExifAscii; >>typedef uint16_t ExifShort; /* 2 bytes */ >>typedef uint32_t ExifLong; /* 4 bytes */ >>typedef struct {ExifLong numerator; ExifLong denominator;} ExifRational; >>typedef char ExifUndefined; /* 1 byte */ >>typedef int32_t ExifSLong; /* 4 bytes */ >>typedef struct {ExifSLong numerator; ExifSLong denominator;} >>ExifSRational; >> >> >>Now, all problems should disappear. Only some printf-Statements, which >>need format modifier for eg ExifLong, are throwing warnings. Are there >>any specifier for uint32_t which can be used with printf and friends? >> >>Joerg >> >> > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >_______________________________________________ >Libexif-devel mailing list >Lib...@li... >https://lists.sourceforge.net/lists/listinfo/libexif-devel > > > > you could add something like that for those broken compilers (from ffmpeg libavcodec/common.h) #ifndef EMULATE_INTTYPES # include <inttypes.h> #else typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef unsigned char uint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; # ifdef CONFIG_WIN32 typedef signed __int64 int64_t; typedef unsigned __int64 uint64_t; # else /* other OS */ typedef signed long long int64_t; typedef unsigned long long uint64_t; # endif /* other OS */ #endif /* HAVE_INTTYPES_H */ |
From: Joerg H. <jo...@de...> - 2004-04-01 20:53:08
|
Hi On Fri, Mar 19, 2004 at 06:48:10PM +0100, matthieu castet wrote: > you could add something like that for those broken compilers (from > ffmpeg libavcodec/common.h) > #ifndef EMULATE_INTTYPES > # include <inttypes.h> > #else > typedef signed char int8_t; > typedef signed short int16_t; > typedef signed int int32_t; > typedef unsigned char uint8_t; > typedef unsigned short uint16_t; > typedef unsigned int uint32_t; > > # ifdef CONFIG_WIN32 > typedef signed __int64 int64_t; > typedef unsigned __int64 uint64_t; > # else /* other OS */ > typedef signed long long int64_t; > typedef unsigned long long uint64_t; > # endif /* other OS */ > #endif /* HAVE_INTTYPES_H */ I've done the small solution for the moment; I include inttypes.h if its available, otherwise I use the old code. This introduces some warnings in printf-Statements, because I haven't found the respective modifiers for uint32_t... Is there a possibility to fix this? Joerg -- Fachbegriffe der Informatik (Nr 177): Mainframe-Admin - Arbeitsschutzschuhe Holger Spielmann |
From: Hans U. N. <gp...@n-...> - 2004-03-21 01:15:45
|
"Jan Patera" <pa...@pi...> writes: > unless you equip libexif with definitions of uint16_t, uint32_t > and int32_t, this "simple" change will break compilability for many > platforms. E.g. MSVC does not know such types (is it in some latest C++ > standard?). We should be able to copy that from libgphoto2. Including the autoconf magic. Gru=DF, Uli --=20 Some gphoto2 links: http://www.teaser.fr/~hfiguiere/linux/digicam.html http://gphoto.sf.net/ http://n-dimensional.de/projects/digicam/ #gphoto on irc.freenode.net http://sf.net/projects/gphoto http://sf.net/projects/libusb http://sf.net/projects/libexif |
From: Hans U. N. <gp...@n-...> - 2004-04-06 22:09:27
|
"Jan Patera" <pa...@pi...> writes: > unless you equip libexif with definitions of uint16_t, uint32_t > and int32_t, this "simple" change will break compilability for many > platforms. E.g. MSVC does not know such types (is it in some latest C++ > standard?). I have now added the macro from libgphoto2 which creates a _stdint.h which should always contain adequate definitions for u?int(8|16|32)_t. I don't have MSVC, so could you please test it? You can find a test tarball at http://n-dimensional.de/blaf/libexif-0.6.9.tar.gz http://n-dimensional.de/blaf/exif-0.6.9.tar.gz [ test tarballs for the 0.7.0 release ] BTW, how are you compiling libexif with MSVC? On unixoid systems, you run ./configure make make install On Windows, you don't have a shell to execute configure, so how do you do that? BTW, I managed to cross-compile the code from the tarball on a Debian system for a W32 target using mingw32 using ./configure --host=3Di586-mingw32msvc but I don't know how that helps you MSVC people, or how to create a .DLL file. The result is just a libexif.a file. Porting stuff to MSVC is new to me. I only have a little experience with Cygwin and Mingw32 on W2K. Gru=DF, Uli --=20 Some gphoto2 links: http://www.teaser.fr/~hfiguiere/linux/digicam.html http://gphoto.sf.net/ http://n-dimensional.de/projects/digicam/ #gphoto on irc.freenode.net http://sf.net/projects/gphoto http://sf.net/projects/libusb http://sf.net/projects/libexif |
From: Antonio S. <sc...@te...> - 2004-04-07 00:41:55
|
At 19:08 6/4/2004, Hans Ulrich Niedermann wrote: >BTW, how are you compiling libexif with MSVC? On unixoid systems, you >run > ./configure > make > make install > >On Windows, you don't have a shell to execute configure, so how do you >do that? In my case, I have Cygwin installed. I ran "bash" then "./configure" just to get a "config.h" file. Then I cleaned and adjusted the "config.h" to meet my needs. In fact it is really simple: #define GETTEXT_PACKAGE "libexif-9" #ifdef WIN32 #define snprintf _snprintf #endif Then I use it to compile the libexif in Visual C++ with a standard project, and I also use it in many Unices: Linux, IRIX, SunOS and AIX. I tested my application only in Windows up to now. But soon I will test it in UNIX to check the exif tags with libjpeg. With version 0.7 I will try to extract tags together with libTIFF. Best, Antonio Scuri |