bug#11519: "Wrong type argument: characterp" building custom-deps while boostrapping

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> Note that the address of buffer text has changed from 0x10757948 to
> 0x10826948.  And the culprit is ...

>   #7  0x010397fb in xmalloc (size=786436) at alloc.c:727
>   #8  0x0120da2d in load_charset_map_from_file (charset=0x1944970,
>       mapfile=57455953, control_flag=1) at charset.c:501

Huh!  Indeed, I always assumed that relocation would be something that
can only happen during GC, not in a mere xmalloc.

> The marked line calls string_char, which calls maybe_unify_char, which
> calls load_charset, which causes memory allocation and relocation of
> buffer text.

This brings up back to the issue of calling maybe_unify_char in
STRING_CHAR_AND_LENGTH.  One more strike against it.  Handa, could you
prepare a patch that removes this?

> If you agree with the diagnosis, then how about the change below?

Might be an acceptable workaround for the emacs-24 branch, yes (tho I'd
replace "inhibit ? 0 : 1" with "!inhibit").  But is it really new in
Emacs-24?  It seems the same problem is already present in Emacs-23, so
it's probably not so urgent to fix it for 24.1.

> It fixes the problem for me.  (Or is there a better way?)  If accepted, I
> will add the necessary commentary to this code and a prototype for the
> new function.  In any case, I suggest to install the fix on the
> emacs-24 branch, because this issue is a disaster waiting to happen.

I wonder: why do we use REL_ALLOC?


        Stefan