Paul Eggert <eggert@cs.ucla.edu> schrieb am So., 22. Nov. 2015 um 19:38 Uhr:

> I'm not going to belabor the point. If you want to use sizes as version
> numbers
> it's not worth fighting over. If we ever change a function API without
> changing
> the structure layout, I guess we'll have to insert a dummy structure
> member to
> make the size grow. Sounds like a kludge, but there are worse kludges in
> Emacs.
>


Adding back Daniel. Not sure whether he follows this discussion, but he
should definitely participate.


>
> Getting back to the original issue, your worry was that a ptrdiff_t size
> would
> lead to unnecessary warnings.  I didn't get any such warning when
> compiling this
> with gcc -Wall:
>
> #include <stddef.h>
> ptrdiff_t size;
>
> int main (void) { return size < sizeof size; }
>
> I expect the warnings you're worried about occur when comparing an unknown
> ptrdiff_t with an unknown size_t; they should not occur when comparing an
> unknown ptrdiff_t with a size_t constant.


I get a warning with both Clang and GCC when compiling with -Wextra.


>   If that's the case, let's leave it
> ptrdiff_t.  And even if it's not the case, I'm inclined to leave it
> ptrdiff_t,
> as any module code will run into similar issues with the other ptrdiff_t
> components, so why make an exception for this one?
>

What other ptrdiff_t components are there? The only other occurrences I see
are the argument counts (which are never compared to sizes), and the string
lengths (where callers might run into trouble if a buffer is larger than
PTRDIFF_MAX, but that seems unlikely).