[Openswan dev] [PATCH] fix format expect long int warning

[D. Hugh Redelmeier]

| From: Gilles Espinasse <g.esp at free.fr>
| To: dev at openswan.org
| Subject: [Openswan dev] [PATCH] fix format expect long int warning
| 
| /usr/src/openswan-2.6.22rc2/modobj26/pfkey_v2_build.c:99: warning: format '%ld' expects type 'long int', but argument 4 has type 'unsigned int'
| /usr/src/openswan-2.6.22rc2/modobj26/pfkey_v2_build.c:107: warning: format '%ld' expects type 'long int', but argument 4 has type 'unsigned int'
| /usr/src/openswan-2.6.22rc2/modobj26/pfkey_v2_build.c:1349: warning: format '%ld' expects type 'long int', but argument 3 has type 'unsigned int'
| /usr/src/openswan-2.6.22rc2/modobj26/pfkey_v2_build.c:1353: warning: format '%ld' expects type 'long int', but argument 3 has type 'unsigned int'

| -		DEBUGGING(PF_KEY_DEBUG_BUILD,"%s:Free extention %d (%ld)\n","pfkey_extensions_free",0, sizeof(struct sadb_msg));
| +		DEBUGGING(PF_KEY_DEBUG_BUILD,"%s:Free extention %d (%zu)\n","pfkey_extensions_free",0, sizeof(struct sadb_msg));

I'm glad you are de-linting the code.  I consider these to be real
bugs.

It seems that on Linux systems sizeof(long) is usually or always equal
to sizeof(void *) and sort of consequentially usually equal to
sizeof(size_t).  This assumption seems to be built into the code you
are fixing, and I think that it should not be.  The C Standard does
not promise these things.

Furthermore, size_t is never signed, so %ld should at least be %lu (as
you have recognized).

On the other hand, %z is a glibc-ism.  I think that it is better to
stay with Standard C.

Here's how I'd rewrite this line.  The other lines need quite similar 
treatment:
| -		DEBUGGING(PF_KEY_DEBUG_BUILD,"%s:Free extention %d (%ld)\n","pfkey_extensions_free",0, sizeof(struct sadb_msg));
| +		DEBUGGING(PF_KEY_DEBUG_BUILD,"%s:Free extention %d (%zu)\n","pfkey_extensions_free",0, sizeof(struct sadb_msg));
| ++		DEBUGGING(PF_KEY_DEBUG_BUILD,"%s:Free extention %d (%lu)\n","pfkey_extensions_free",0, (unsigned long)sizeof(struct sadb_msg));

If you want to think too hard, you could convince yourself that
unsigned int would be long enough to hold the length of such a
structure.  I would not recommend doing this.