Re: xalloc.h use idx_t

[Marc Nieper-Wißkirchen]

xalloc is now called with a size_t argument. If the argument type is silently changed to an idx_t, existing code which calls the new xalloc still with a size_t argument will trigger a compiler warning under GCC's -Wsign-conversion.

Fixing existing code isn't easy because the sizeof operator returns a size_t, which somehow would have to be converted to an idx_t without triggering any compiler warnings.

The coexistence of size_t and idx_t is problematic. If we want to drop size_t somewhere, we have to drop it everywhere it seems. This includes providing a signed sizeof operator and modules like flexmember may have to revisited as well.

Marc

Am Mi., 7. Apr. 2021 um 23:01 Uhr schrieb Bruno Haible <bruno@clisp.org>:

Hi Paul,

> I am planning to make xalloc.h use idx_t rather than size_t for object
> and byte counts, as we really should be using signed integers there, for
> all the usual reasons.

I agree that using idx_t in more places helps reduce overflow problem.

However, since 'xalloc' started out as "malloc() which can't return NULL",
this would introduce an inconsistency w.r.t. malloc().
Could programmers still replace calls to malloc() with calls to xmalloc()
without thinking, without considering the context?
And vice versa, when transforming code into library code, can programmers
still replace calls to xmalloc() with calls to malloc() and a NULL check,
mechanically?

(I hope the answer is "yes", but maybe I'm overlooking something?)

Bruno