Re: [Libexif-devel] [libexif-cvs] libexif/libexif exif-entry.c, 1.101, 1.102

[Hans U. N. <gp...@n-...>]

Jan Patera wrote:

> Index: exif-entry.c
> ===================================================================
> RCS file: /cvsroot/libexif/libexif/libexif/exif-entry.c,v
> retrieving revision 1.101
> retrieving revision 1.102
> diff -u -p -d -r1.101 -r1.102
> --- exif-entry.c	15 May 2007 18:23:28 -0000	1.101
> +++ exif-entry.c	15 Jun 2007 06:49:42 -0000	1.102
> @@ -863,7 +863,7 @@ exif_entry_get_value (ExifEntry *e, char
>  	case EXIF_TAG_MAKER_NOTE:
>  		CF (e, EXIF_FORMAT_UNDEFINED, val, maxlen);
>  		snprintf (val, maxlen, _("%i bytes unknown data"),
> -			  (int) e->components);
> +			  e->size);
>  		break;
>  	case EXIF_TAG_SUBJECT_AREA:
>  		CF (e, EXIF_FORMAT_SHORT, val, maxlen);

Hmm. Does anyone have a proper reference on what format strings to use
for what data type on what platform? I have <inttypes.h> here, which
defines strings like PRIu32 as "u", and is supposed to be used to
construct format strings, I suppose. However, we cannot use those
together with gettext based translations, can we?

(At least a few of) those "%li" format strings made sense. IIRC someone
said pointer size was guaranteed to be equal to long, not to int. Thus
%li would be proper for size_t and ssize_t as well.

Jan, do you have a compiler which does not support %li?

And in this case at hand, e->components is unsigned, so it should at
least be an (unsigned int) and %u, not (int) and %i, right?