On 06/04/2013 02:47 AM, Thien-Thi Nguyen wrote:
() Paul Eggert<egg...@cs.ucla.edu>
() Mon, 03 Jun 2013 15:28:24 -0700
extern char const allsigstr[];
This would consist of a concatenation of null-terminated strings,
one per name, terminated by an empty string.
[compile time wins]
I seem to recall a paper several years back that argued against this
approach based on ldso issues. Drat, can't dredge the details...
I tried searching the Internet for such issues, but couldn't find any.
What do you recall as being the loader problem? The "extern" part? Or
use of a null string for termination?
I'm just thinking, Paul, if the null termination/index pointer idea were
used throughout the string array, one could continue to use the
int sig2str (int, char *);
function in a backward compatible way. (I had ruled that out with the
run-time dynamic creation of such a thing, but with the indexing, there
should be no re-entry problems.) The fundamental string array would
look like this, as an example:
{
"HUP",
"",
"INT",
"",
...
"STKFLT",
"",
"CHLD",
"CLD",
"",
"CONT",
"",
...
}
If the numname[] array then had a pointer to the first entry in the
above string array it would produce the equivalent of the existing
routine with the extension to continue reading null-terminated strings
until the empty string. However, this doesn't seem like an easy thing
to sort through at compile-time unless the macro were written in such a
way that it included duplicates. For example (assuming there would
never be more than two or three duplicates) the following illustrates
conceptually (but perhaps syntactically it's dubious):
#define NUMNAME(name) { SIG##name, #name }
#define NUMNAME2(name1, name2) { ??? some kind of ##ifdef logic }
#define NUMNAME3(name1, name2, name3) { ??? some kind of ##ifdef logic }
/* Signal names and numbers. Put the preferred name first. */
static struct numname { int num; char const name[8]; } numname_table[] =
{
NUMNAME (HUP)
NUMNAME (INT)
NUMNAME (QUIT)
...
NUMNAME2 (CHLD, CLD)
...
{ 0, "EXIT" }
};
Dan
