Paul Eggert wrote: > > Why this? What was wrong with the previous formula > > There's nothing wrong with it if we assume no padding bits, which the > Gnulib coding conventions allow us to assume, so the other examples you > mention are OK in Gnulib.
Good; I was worried some new weird hardware was appearing on the horizon :) > However, I thought it nicer if we didn't have > to assume it in this particular case. > > It's not a big deal. If you like, we could have OFFSET_MAX be optional, > with the default being the old value. Yes, please. This would be good. You already changed two uses of the module: - gnulib/lib/fstrcmp.c - diffutils/src/analyze.c but there are more (according to https://codesearch.debian.net/search?q=include+%22diffseq.h%22&literal=1 ): - patch/src/merge.c - emacs/src/editfns.c - gnulib/lib/git-merge-changelog.c - dwdiff/src/diff/analyze.c It's better if we can keep the module source-compatible with the existing uses. Bruno
