Granularity of zcompile header magic

Granularity of zcompile header magic

[Bart Schaefer]

It's possible that we're encountering spurious errors because changes in
the structure of exec.c and/or parse.c invalidate the wordcode in zcompile
output files, but that's not detected by autoload because the header only
contains $ZSH_VERSION (and not the patchlevel).

Originally this was done with the expectation that most people would need
to re-zcompile when installing a major new release, but maybe we should be
bumping along in smaller steps -- or at least have a mechanism for doing
some bumping when a wordcode-altering change is made?

See parse.c: write_dump() and load_dump_header(), though I can't think of
any simple way to automate such version-bumping (other than to just use
the full ZSH_PATCHLEVEL).

Re: Granularity of zcompile header magic

[Peter Stephenson]

On Thu, 12 Feb 2015 20:09:33 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> It's possible that we're encountering spurious errors because changes in
> the structure of exec.c and/or parse.c invalidate the wordcode in zcompile
> output files, but that's not detected by autoload because the header only
> contains $ZSH_VERSION (and not the patchlevel).
> 
> Originally this was done with the expectation that most people would need
> to re-zcompile when installing a major new release, but maybe we should be
> bumping along in smaller steps -- or at least have a mechanism for doing
> some bumping when a wordcode-altering change is made?

I think you're right: we should be more disciplined about updating the
number after the "dev" when making incompatible changes to the wordcode
(which aren't actually that common).  I don't think there's any
effective way of automating this with the way the wordode works --- it's
a question of adding or changing a word in the parser, then its use in
the execution code and its text decode.

pws