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

[Jan P. <pa...@pi...>]

Hi,

I see we need several audits. One of them is for the types and formatting
sequences used.
1) libexif doesn't use size_t and ssize_t anywhere, except of exif-mem.c
  where the arguments to calloc and realloc are typecast to size_t
2) size members in all our structures are always unsigned int. Therefore
 I agree rather %u should be used, also to catch bugs and problems,
 like the recent iDefense problem and the Michele's report.
 Some functions use ExifLong which is supposed to be 32bit.
3) Again, I did unification - both %li and %i were used on different places
 in the same situation.
3) No, I don't know any compiler not supporting %li. Isn't it in the
 C standard?
4) However, I do know that 4=sizeof(int)<sizeof(long)=8 on 64bit
  Windows, but 8=sizeof(int)=sizeof(long)=8 on 64bit Mac OS.
  We have not declared 64bit support yet, but we will have to do so
  very soon.
5) sizeof(int) indeed is not the same as sizeof(void*).
6) Q: do we still have to bother with 16bit int?

 -- Jan

> 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?
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> libexif-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libexif-devel