Bug with handling of SAVEHIST?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

The doc for "fc" says:
     'fc -R' reads the history from the given file, 'fc -W' writes the
     history out to the given file, and 'fc -A' appends the history out
     to the given file.  If no filename is specified, the $HISTFILE is
     assumed.  If the -I option is added to -R, only those events that
     are not already contained within the internal history list are
     added.  If the -I option is added to -A or -W, only those events
     that are new since last incremental append/write to the history
     file are appended/written.  In any case, the created file will have
     no more than $SAVEHIST entries.

That implies that:

% SAVEHIST=0; fc -W

should truncate the file, but in fact it does not, because
savehistfile() is over-optimized to a no-op when savehistsiz==0.  (I
assume this is intended to prevent accidentally clobbering the history
on logout.)

However, this also doesn't work:

% SAVEHIST=1; fc -W

The entire current in-memory shell history is always written to the
file when ((SAVEHIST > 0)).

Digging in, savehistfile() pays attention to savehistsiz only when the
HFILE_FAST bit is passed, and bin_fc() never uses that bit; it is used
only by hbegin() and hend() to handle incremental history, and even
then savehistsiz is only compared in order to disable HFILE_FAST again
if too many incremental updates have been done.

There seems to be an assumption that SAVEHIST will never be smaller
than HISTSIZE, and as far as I can tell this has been the case for as
far back as there are git revisions to look through ... despite the
documentation explicitly discussing that scenario for added safety
when using HIST_EXPIRE_DUPS_FIRST.

Am I missing something?  Is this just something we should correct in
the documentation?