Re: [PATCH] diffseq: don’t assume integers lack padding

[Bruno Haible]

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