Re[2]: [Gc] Patch for adjusting printf actual param types

Ivan Maidanski ivmai at mail.ru
Sun Oct 26 06:19:54 PST 2008


Hi!

Petter Urkedal <urkedal at nbi.dk> wrote:
> 
> On 2008-10-26, Ivan Maidanski wrote:
> > Petter Urkedal <urkedal at nbi.dk> wrote:
> > > 
> > > On 2008-10-25, Ivan Maidanski wrote:
> > > > This patch adjusts the types of actual parameters for GC_..._printf() according to its format specifiers.
> > > 
> > > Not to disagree with your patch, but how about imitating the C99
> > > standard and add the following definitions to gc.h (next to the GC_word
> > > typedef)?
> > > 
> > > #define GC_PRIdWORD "ld"
> > > #define GC_PRIiWORD "li"
> > > #define GC_PRIoWORD "lo"
> > > #define GC_PRIuWORD "ld"
> > > #define GC_PRIxWORD "lx"
> > > #define GC_PRIXWORD "lX"
> > > 
> > > One of the print statements below would then look like
> > > 
> > >     GC_printf("Free list %lu (total size %"GC_PRIuWORD");\n",
> > > 	      i, GC_free_bytes[i]);
> > 
> > This is technically possible... But some tips:
> > - this really only matters for LLP64 targets (like Win64 where
> > sizeof(ptr)>sizeof(long));
> 
> Interesting.  And I though the possibility that "(long)word" would
> truncate "word" was too hypothetical to mention.

Well, You are right, but note my tip about this printing major purpose (just below) and note that (if we are talking about values not pointers) truncation could generally arise only in case of a heap larger than 4GB. So, I think, the volunteer could be someone who really needs such correct printing. With my posted patch I've just wanted to say that passing values those types mismatch format specifiers is incorrect (even on 32-bit targets) and incorrect (not even truncated) values could be printed (depending on CPU endian). But, again, You are right.

> 
> > - printing in GC servers really the debugging and profiling purposes
> > only (if someone wants to print, eg., number of free bytes left then
> > he should use GC_get_free_space() call and print it manually);
> > - hex printing of GC_word value could be done thru "%p" modifier
> > (AFAIK, it's portable);
> 
> Yes, I think "%p" is in C89, at least, but it's not guaranteed to print
> a plain hexadecimal number.  glibc adds a "0x" in front, which may or
> may not be desirable.
And MinGW adds "0p" prefix...

> Using "%p" we still need to cast the argument to a pointer, which could be narrower than GC_word.
No! We are assuming that sizeof(word)==sizeof(ptrdiff_t)==sizeof(void*). To my knowledge, the GC heavily relies on this fact (and even, sometimes, it is assumed that sizeof(size_t)==sizeof(void*).

> 
> > - there should exist a volunteer to define these macros (across major
> > compilers) and to use them consistently across the whole GC.
> 
> Looking at the source code, there are only two cases.  Most platforms
> use "unsigned long" which has a portable format specifier.  The only
> exception is _WIN64.  I don't know if the library which define ULONG_PTR
> and LONG_PTR also defined the corresponding print specifiers.
Only MinGW, Watcom and DMC have PRIx64 macros family (in "inttypes.h").

> 
> Introducing the print specifiers for GC_word, does not mean they have be
> be consistently used across the whole GC.  They give you an option for
> new code and patches.
OK.

> 
> > > BTW, i is already long above, no cast needed.
> > "i" var is unsigned (to prevent compiler warning since N_HBLK_FLS is
> > unsigned) in my current snapshot version of GC (not CVS) - Hans still
> > has a backlog of my suggested patches (neither committed nor
> > rejected).
> 
> You're right.  Then I suggest changing the print specifier to "%u"
> rather than casting the argument to long.
Yes, "%u" would be pure solution here (and faster ;) on LP64 targets) but is it worth making the patch for it and ask to commit it - there is a plenty of such (and more serious to pay attention to) places in GC!

Bye.



More information about the Gc mailing list