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 <br...@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 > >
