From: Hans U. N. <gp...@n-...> - 2007-06-15 14:19:58
|
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? |
From: Jan P. <pa...@pi...> - 2007-06-25 08:27:37
|
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 |
From: Hans U. N. <gp...@n-...> - 2007-06-25 15:03:55
|
Jan Patera wrote: > I see we need several audits. One of them is for the types and formatting > sequences used. I wholeheartedly agree. > 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 size_t and ssize_t should be for memory area sizes, and nothing else, right? > 2) size members in all our structures are always unsigned int. Therefore unsigned int is definitely wrong. However, changing that to unsigned long is going to break ABI compatibility, so we need to plan ahead a little before just breaking the ABI with each release every two weeks. One (mostly) API compatible ABI break for that stuff is OK imho. > I agree rather %u should be used, also to catch bugs and problems, > like the recent iDefense problem and the Michele's report. I doubt that using %u in format strings is going to help us find many integer type bugs. > Some functions use ExifLong which is supposed to be 32bit. EXIF defines an (EXIF) long to be 32bit. > 3) Again, I did unification - both %li and %i were used on different places > in the same situation. Well... we have no format strings available (unless we want to use inttypes.h and break the _("foo") macros) for uint32_t or ExifLong or size_t - so we're probably best off if we make sure the format string is large enough and provide the compiler with a value of the proper width. That would mean we use "%lu", (unsigned long)(foo) for foo types of size_t, uint32_t, ExifLong "%li", (signed long)(foo) for foo types of ssize_t, int32_t, ExifSLong right? > 3) No, I don't know any compiler not supporting %li. Isn't it in the > C standard? Which one? :) I do not know, as I do not have any C standard documents. > 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. Where can 64bit be problematic? Data structure size: Should not matter as we should be using uint8_t, uint16_t and uint32_t everywhere where size matters anyway. Right? Calculations done with more precision: When we need an overflow, & 0xffffffff should fix that, right? ... > 5) sizeof(int) indeed is not the same as sizeof(void*). I remember the rule that sizeof(long) == sizeof(anything*). Whether that is coincidence or definition, needs to be researched before building on it. > 6) Q: do we still have to bother with 16bit int? I would not go out of my way to prevent libexif from working with 16bit int systems. If we use all the proper type definitions, 16bit int systems should either just work or throw a compilation error. Uli |
From: Hubert F. <hfi...@te...> - 2007-06-26 00:55:33
|
Jan Patera wrote: > 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. On Linux x86_64 sizeof(int) == 4 sizeof(long) == 8 sizeof(void*) == 8 On Linux x86 and ppc sizeof(int) == 4 sizeof(long) == 4 sizeof(void*) == 4 > 5) sizeof(int) indeed is not the same as sizeof(void*). Never should me assumed. > 6) Q: do we still have to bother with 16bit int? Yes it can be useful. #include <stdint.h> and be done with one. There is one retarded platform that have to work around it. For the rest we have configure. Hub |