Hi,
> Sadly, there's a bigger issue here. Namely that the caller and the
> definition of ASM_GENERATE_INTERNAL_LABEL both can include arbitrary
> length text into the label name. Furthermore, the buffer is allocated
> in the caller's context. It's a terrible API.
Yes. Even ASM_FORMAT_PRIVATE_NAME looks like a better way to define
the API.
# define ASM_FORMAT_PRIVATE_NAME(OUTPUT, NAME, LABELNO) \
do { const char *const name_ = (NAME); \
char *const output_ = (OUTPUT) = \
(char *) alloca (strlen (name_) + 32); \
sprintf (output_, ASM_PN_FORMAT, name_, (unsigned long)(LABELNO)); \
} while (0)
But it also depends on what ASM_PN_FORMAT looks like,
so also this "+ 32" should be a define, which tells us how much
overhead comes from the format string, then we should use that
in the allocation.
If the target overrides ASM_PN_FORMAT the target should also
define how long the ASM_PN_FORMAT prints minimum. Then the macro
can use strlen (name_) + ASM_PN_FORMAT_MIN_LENGH + max. space
for the LABELNO, maybe just use strlen(ASM_PN_FORMAT) if the
target fails to cooperate.
> ISTM the way "out" is to change very ASM_GENERATE_INTERNAL_LABEL
> implementation to use snprintf to first determine the length of the
> resulting string, then allocate an appropriate amount of memory
> (returning it to the caller). The caller is then changed to use the
> buffer allocated by ASM_GENERATE_INTERNAL_LABEL, free-ing it when
> appropriate. Major ick. We'd probably want to hook-ize the damn thing
> while we're at it.
I would like to have a simple solution, that does work with the current
code, without totally rewriting the users.
The middle end should be able to tell the target how long the longest
PREFIX will be, then the target should be able to give a formula how
long the total format will be. Then some users already use
MAX_ARTIFICIAL_LABEL_BYTES to allocate a sufficient buffer, that should
be based on the target definition, all others that don't do it already
should follow.
Bernd.
