Menu
▾
▴
libexif-devel
|
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 |
Thanks for helping keep SourceForge clean.
X