[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposal for version mismatch

From: Eric Blake
Subject: Re: proposal for version mismatch
Date: Wed, 19 Jul 2006 06:53:28 -0600
User-agent: Thunderbird (Windows/20060516)

Hash: SHA1

Hi Gary,

According to Gary V. Vaughan on 7/18/2006 4:39 PM:
> In principle, I like this idea a lot, and think it is a worthy
> addition to branch-1_4.  BUT...
>>    VALIDATE ('V');
>> -  VALIDATE ('1');
>> +  GET_NUMBER (number[0]);
>> +  if (number[0] > 1)
>> +              "frozen file version %d greater than max supported of 1",
>> +          number[0]));
>> +  else if (number[0] < 1)
>> +    M4ERROR ((EXIT_FAILURE, 0,
>> +              "ill-formed frozen file, version directive expected"));
>>    VALIDATE ('\n');
> I don't like this particular patch though.  Is it not the case
> that m4-1.4.6 might actually run perfectly well with a file
> frozen by m4-1.4o/m4-1.9a/m4-2.x in many cases?

Files frozen by m4-1.4o (which used format 1) - yes.

Files frozen by m4-1.9a/m4-2.x - doubtful.  Format 2 was introduced Nov
2000, and it changed syntax (it now understands \ escape sequences), so


is valid in format 2 but ill-formed in format 1.  I think it is rather
invasive to teach the branch about parsing format 2, especially since that
format specification is not nailed down until we do a formal release of m4
using that format.  Also, by default, m4-1.9a currently emits 3-argument F
directives, but format 1 only understands 2-argument F directives.  Maybe
this is worth changing on CVS head, and teaching m4-1.9a how to emit
format 1 (either on an as-possible basis, or when requested by a
command-line option); but I don't want to hold up m4 1.4.6 based on what
might or might not happen in the future of m4 1.9a.

>  I think failing
> on the version number off the bat is not the most flexible approach,
> especially considering your earlier patch to not barf on changeword
> entries in the frozen file.  (Or did 1.4o still generate V1 files?)

Except that it was already that way - the previous error message was:
NONE:0: m4: expecting character `1' in frozen file
with exit status 1.  So all my patch does is make the message nicer, and
change the exit status to 63.

> Unfortunately, this opens a whole can of worms... and it is not
> at all straight forward to figure out whether a particular frozen
> state will cause problems subsequent to loading (maybe impossible
> infact).  More thought required :-(

Also, remember that we document that all frozen files can be opened with
the same m4 version or newer (ie. we will strive to make all newer
versions backward compatible, although there is still work to be done on
CVS head to achieve that).  But I don't think we can or need to promise
that all newer m4 versions can generate frozen files that can still be
read by older versions.  Normally, once you upgrade, you never go back.

I really do think it is easiest to key off the version directive.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]