Hi,
On Wed, Sep 08, 2021 at 06:56:05AM -0700, Greg Steuck wrote:
> 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.
Wouldn't this just cause badly formatted output? I'm not sure for what
that whole beast (report_summary()) is used for, except for looking at
the outpu.
> Looking into the depths of vdebugBelch shows
> that we also need to change the type of debugMsgFn.
The funny thing is that debugMsgFn is only assigned in one place
in the code. The same for the other three RtsMsgFunction function
pointers. This smells like overengineering to me ;-)
> Are you at all intersted in shaving this yak all the way so we can push
> this fix upstream?
I'll have a look. Shouldn't be too much work, since there are only
those four function pointers and only for functions actually defined.
> The least appealing part is testing the change as %n this seems to only
> be used with somewhat esoteric runtime settings.
Well, %n popped up in /var/log/messages of the bulk build machines,
so it shouldn't appear with the fix.
At the moment I'm waiting for the rebuild of all haskell ports on
my machine (with my diff from yesterday). When that is ready, I'll look
at the debugMsgFn stuff.
Ciao,
Kili
