Thank you for looking into this, I meant to, but was slightly turned off
by the depth of the rabbit hole. I'll annotate it below.
Matthias Kilian <k...@outback.escape.de> writes:
> +@@ -1024,8 +1024,10 @@ static void report_summary(const RTSSummaryStats* sum)
> +
> + for (g = 0; g < RtsFlags.GcFlags.generations; g++) {
> + int prefix_length = 0;
> +- statsPrintf("%*s" "gen[%" FMT_Word32 "%n",
> +- col_width[0], "", g, &prefix_length);
> ++ prefix_length = statsPrintf("%*s" "gen[%" FMT_Word32,
> ++ col_width[0], "", g);
> ++ if (prefix_length < 0)
> ++ prefix_length = 0;
> + prefix_length -= col_width[0];
> + int suffix_length = col_width[1] + prefix_length;
> + suffix_length =
This is all cool and proper.
> +@@ -1735,9 +1737,10 @@ void getRTSStats( RTSStats *s )
> + Dumping stuff in the stats file, or via the debug message interface
> +
> -------------------------------------------------------------------------- */
> +
> +-void
> ++int
> + statsPrintf( char *s, ... )
> + {
> ++ int ret = 0;
> + FILE *sf = RtsFlags.GcFlags.statsFile;
> + va_list ap;
> +
> +@@ -1745,9 +1748,10 @@ statsPrintf( char *s, ... )
> + if (sf == NULL) {
> + vdebugBelch(s,ap);
vdebugBelch should also count the bytes, right? Otherwise we return 0
below and introduce a bug. Looking into the depths of vdebugBelch shows
that we also need to change the type of debugMsgFn.
Are you at all intersted in shaving this yak all the way so we can push
this fix upstream?
The least appealing part is testing the change as %n this seems to only
be used with somewhat esoteric runtime settings.
Thanks
Greg
