Hi Johannes, Thanks for the info! I appreciate the background.
In the future if you folks do find a bug, please let me know. Thanks! Arnold Johannes Schindelin <johannes.schinde...@gmx.de> wrote: > Hi Arnold, > > On Sun, 14 May 2017, arn...@skeeve.com wrote: > > > With respect to bug fixes that may have happened downstream, please do > > let me know of any. But I do request it as a bug report to > > bug-g...@gnu.org and not just a pull request with no commentary. > > I dabbled with updating our compat/regex/ myself, a while ago, and just > found my notes. Note: at least some of these notes should help with the > next iteration of Ævar's patch series. > > First of all, our original import could have been accompanied by better > documentation what was done. Granted, back then gawk was still maintained > in CVS, so things would have been a little tougher with regard to, say, > specifying which gawk revision was imported. In the meantime, gawk uses a > Git repository, though: http://git.savannah.gnu.org/r/gawk.git. Therefore, > we can say pretty precisely that gawk's 40b3741f (Bring in development > gawk changes., 2010-11-12)) was imported into Git as per d18f76dccf > (compat/regex: use the regex engine from gawk for compat, 2010-08-17). > > My approach of updating compat/regex/ differed from Ævar's in that I > checked out that Git commit, applied the interdiff to gawk's newest > commit, and rebased that onto the current commit of Git. But I think Ævar > & Junio's approach (replace compat/regex/ wholesale by the newest gawk > revision's files, then re-apply clean patches of our `git log 40b3741f.. > -- compat/regex/` on top, as individual commits) is saner, as it will make > future updates substantially easier. > > With my approach, I still had 16 merge conflicts, pointing in large part > to changes we do *not* want to contribute back: gawk's code style differs > from ours, and we adjusted the files in compat/regex/ to ours (which I > think was a mistake). > > I also reinstated support for compiling with NO_MBSUPPORT, which included > a new guard of the btowc() definition. > > I also had to reintroduce explicit #defines of bool, true and false, as > gawk's source code split those out into their own header file. > > I apparently also "skipped a guarded #include <stddef.h> that was not > actually necessary, but simply a late fixup to a997bf423d (compat/regex: > get the gawk regex engine to compile within git, 2010-08-17)", but I do > not remember what that was about. > > In summary, I do not think that any of our patches should go "upstream" > into gawk's source code, as they are pretty specific to Git's needs. > > Ciao, > Johannes
