Ok, one can of CC to whomever that can explain this:
pelix:~% co -p1.119 /pike/data/cvsroot/Pike/7.0/src/las.c,v > apa /pike/data/cvsroot/Pike/7.0/src/las.c,v --> standard output revision 1.119 pelix:~% co -p1.119 /pike/data/cvsroot/Pike/7.2/src/las.c,v > bepa /pike/data/cvsroot/Pike/7.2/src/las.c,v --> standard output revision 1.119 pelix:~% gdiff -u apa bepa --- apa Sun Aug 6 13:19:32 2006 +++ bepa Sun Aug 6 13:19:38 2006 @@ -2055,8 +2055,8 @@ push_type(T_VOID); /* not varargs */ push_type(T_MANY); function_type_max=0; + s = pop_type(); low_build_function_type(CDR(n)); - push_type(T_FUNCTION); s=pop_type(); f=CAR(n)->type?CAR(n)->type:mixed_type_string; n->type=check_call(s,f); pelix:~%
Now, version 1.119 is _well_ before the 7.0/7.1 split (which happens around 1.174-1.179 somewhere), so how can there be a difference? Did someone introduce a change in las.c by simply editing the last version in the ,v file? When _should_ this change happen?
Incidentally, if I get 1.119 from the 7.4, 7.6 or 7.7 repositories, I get the same version as in 7.0, so it looks like it's just las.c,v in 7.2 which is damaged. The question of what it _should_ look like still remains though...
In the repository on wyrm, revision 1.119 is identical in all versions from 7.0 onwards, and that snippet is the same as in your 7.0 repository.
I can only draw the conclusion that your las.c,v in 7.2 is corrupt. In that case one wonders where else similar corruption might have occurred.
How does the 1.119 revision look in the ,v file? It's like this on wyrm:
1.119 log @Fixed memory leak. @ text @d8 1 a8 1 RCSID("$Id: las.c,v 1.118 1999/11/20 03:41:15 grubba Exp $"); d2060 11 a2070 6 s=pop_type(); f=CAR(n)->type?CAR(n)->type:mixed_type_string; n->type=check_call(s,f); args=count_arguments(s); max_args=count_arguments(f); if(max_args<0) max_args=0x7fffffff; @
I can only draw the conclusion that your las.c,v in 7.2 is corrupt. In that case one wonders where else similar corruption might have occurred.
Well, my conversion script should be able to spot it as long as it affects a version on the mainline, since it cross-checks all the repositories.
How does the 1.119 revision look in the ,v file? It's like this on wyrm:
All the diffs in the ,v file are identical to the 7.4 version up to and including version 1.230, so it appears that the corruption is in a higher, post-split, version. The "pop_type" line which should not be there is introduced by this diff:
1.244 log @Fixed bug in fix_type_field() for function calls. The bug was triggered by function calls in enum assignments (eg negative literal s). @ text @d8 1 a8 1 RCSID("$Id: las.c,v 1.243 2002/11/19 14:00:14 mast Exp $"); d3086 2 d3098 3 a3098 1 s = pop_type(); @
Although it is of course possible that this diff is correct, and that the problem is in a version betweem 1.230 and 1.244 which was supposed to remove the line again.
All the diffs in the ,v file are identical to the 7.4 version up to and including version 1.230, so it appears that the corruption is in a higher, post-split, version.
Then the erroneous line shows in all checked-out revisions from 1.119 to 1.243, right? That's what I see when I compare some revisions between the pelix and wyrm (haven't compared every revision in this range though).
According to the change log, all changes up to and including 1.243 are the same on pelix and wyrm. 1.244 differ, and 1.244 is the head revision on wyrm (that change corresponds to 1.245 on pelix, according to the log message).
Could it be that the corruption is in the base contents in the head revision?
Then the erroneous line shows in all checked-out revisions from 1.119 to 1.243, right?
Up to and including 1.244, yes.
Could it be that the corruption is in the base contents in the head revision?
If I check out 1.230 from 7.2 and 7.4 respectively, the diff I get is this:
--- apa Sun Aug 6 16:44:55 2006 +++ bepa Sun Aug 6 16:44:59 2006 @@ -3043,9 +3043,9 @@ push_type(T_VOID); /* not varargs */ push_type(T_MANY); function_type_max=0; - s = pop_type(); low_build_function_type(CDR(n)); push_type(T_FUNCTION); + s = pop_type(); f = CAR(n)->type?CAR(n)->type:mixed_type_string; n->type = check_call(s, f, (lex.pragmas & ID_STRICT_TYPES) &&
So it seems that the addition of pop_type() in 1.244 might be correct, but that it has been applied two lines to early. This would happen if two extra lines were added in the base contents above this section, but it doesn't explain what would in that case then happen to these lines, as 1.230 does have the correct number of lines...
The corresponding diff I get between the wyrm and pelix versions:
--- las.c 2006-08-06 17:01:09.000000000 +0200 +++ /home/mast/Pike/7.2/src/las.c 2006-08-06 17:01:03.000000000 +0200 @@ -5,7 +5,7 @@ */ /**/ #include "global.h" -RCSID("$Id: las.c,v 1.230 2001-01-11 23:32:29 mast Exp $"); +RCSID("$Id: las.c,v 1.230 2001/01/11 23:32:29 mast Exp $");
#include "language.h" #include "interpret.h" @@ -3045,7 +3045,7 @@ function_type_max=0; low_build_function_type(CDR(n)); push_type(T_FUNCTION); - s = pop_type(); + f = CAR(n)->type?CAR(n)->type:mixed_type_string; n->type = check_call(s, f, (lex.pragmas & ID_STRICT_TYPES) &&
I.e. the wyrm repository is ok but the revision from the pelix 7.2 repository doesn't contain any pop_type line at all. This is fishy.
(The difference in date formatting must be due to a new "feature" in cvs 1.12.9.)
Hah, I think I just found something out. If I checkout the file with cvs co -p -r 1.119, then I get the right data. However, if I use co -p1.119 (the RCS equivalent), I get the broken data.
So it seems that it all boils down to some exciting incompatibility between GNU RCS and the builtin RCS in CVS... :-P
Well, fortunately cvs2svn has a switch to use cvs to checkout stuff instread of co, so it should be simple enough to fix the problem...
Interesting, but it doesn't explain the difference I get. I'm trying with cvs co -p -r... and cvs up -r..., both remotely from my box at Roxen and locally on pelix. I get no pop_type line anywhere in rev 1.230. Are you using the Pike/7.2 repository under /pike/data/cvsroot?
Are you using the Pike/7.2 repository under /pike/data/cvsroot?
Yes. I have investigated a little further, and the disparancy is indeed caused by version 1.244, since co and cvs produce the same result for version 1.245 and up. The original delta looks like this:
@d8 1 a8 1 RCSID("$Id: las.c,v 1.243 2002/11/19 14:00:14 mast Exp $"); d3086 2 d3098 3 a3098 1 s = pop_type(); @
However, if I check out 1.245 and 1.244 with CVS and compare them, I get this diff:
@@ -5,7 +5,7 @@ */ /**/ #include "global.h" -RCSID("$Id: las.c,v 1.245 2005/06/09 17:57:50 mast Exp $"); +RCSID("$Id: las.c,v 1.244 2005/05/15 13:16:56 grubba Exp $");
#include "language.h" #include "interpret.h" @@ -3084,8 +3084,6 @@ char *name; INT32 max_args,args;
- type_stack_mark(); - push_type(T_MIXED); /* match any return type */ push_type(T_VOID); /* even void */ push_type(T_OR); @@ -3095,8 +3093,6 @@ function_type_max=0; low_build_function_type(CDR(n)); push_type(T_FUNCTION); - - s = pop_unfinished_type();
f = CAR(n)->type?CAR(n)->type:mixed_type_string; n->type = check_call(s, f,
So CVS in fact interprets
d3098 3 a3098 1 s = pop_type();
as deleting two lines and not adding anything. It seems like it adds the line _first_, and then deletes the line it just added plus two more, for a total of three lines. RCS behaves in the more expected way of deleting three old lines, and adding the new one.
If I change the delta (in a local copy of the ,v file) to read
@d8 1 a8 1 RCSID("$Id: las.c,v 1.243 2002/11/19 14:00:14 mast Exp $"); d3086 2 d3098 2 @
instead, CVS and RCS produce the same result, and I get a correct version of 1.119...
... but of course that just gave the wrong data for 1.120 instead.
It seems like the correct delta should be
@d8 1 a8 1 RCSID("$Id: las.c,v 1.243 2002/11/19 14:00:14 mast Exp $"); d3086 2 d3098 3 a3100 1 s = pop_type(); @
This gives me identical results with both RCS and CVS for all versions on bhelliom, and pre-split versions which are identical to the ones I get from the 7.4 repository (using either RCS or CVS). However, I still get differences between RCS and CVS for some versions on pelix. As far as I can tell, it's the CVS which is installed on pelix (1.11.5) which is buggy, and that is probably the reason why the bad delta is there to start with.
Unless someone protests, I'm going to upgrade the CVS on pelix to 1.11.21 and fix the broken delta in the ,v file in the repository manually.
Unless someone protests, I'm going to upgrade the CVS on pelix to 1.11.21 and fix the broken delta in the ,v file in the repository manually.
Well, if you wanted to protest you're too late now. :-)
Incidentally, it looks like it was a user error rather than a CVS bug that gave me different results on pelix, but an upgrade can't hurt... (The old CVS installation is still available under /pike/sw/pkg/cvs-1.11.5/ should anyone need it.)
I can confirm that I get a "pop_type" line in the right place when I do an update in the 7.2 repository now. Good work.
The most likely cause is my hand merging of the Roxen and Pelix versions of Pike 7.2. There were two or three files where there where conflicting changes, and las.c may have been one of those.
The most likely cause is my hand merging of the Roxen and Pelix versions of Pike 7.2. There were two or three files where there where conflicting changes, and las.c may have been one of those.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum