On 06/05/2013 02:17 AM, Thien-Thi Nguyen wrote:
() Daniel J Sebald<daniel.seb...@ieee.org>
() Tue, 04 Jun 2013 12:35:00 -0500
> 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?
OK, found it. "How to Write Shared Libraries" by Ulrich Drepper,
version 4.0, section 2.4.3 "Arrays of Data Pointers". See also the
programs in Appendix B.
I think the problem is (relatively) high constant ldso overhead for a
rarely-used facility. However, i'm not sure if those concerns are
relevant in this context. If not, sorry for the noise!
Thanks for the reference. Lots of good info there. Yes, that is
Ulrich's point, but it seems to depend a bit on the programming and
storage method, i.e., using pointers versus array. Note that in one of
Ulrich's examples
static const char msgstr[] =
"message for err1\0"
"message for err2\0"
"message for err3";
static const size_t msgidx[] = {
0,
sizeof ("message for err1"),
sizeof ("message for err1")
+ sizeof ("message for err2")
}
const char *errstr (int nr) {
return msgstr + msgidx[nr];
}
is pretty much the same as what Paul described. The one thing I don't
like about Ulrich's example is the repeated use of the same expression
(could use definitions for the repeated expressions I suppose).
Well, taking this all into consideration, perhaps the easiest thing to
do is construct a table at runtime on the heap:
{
static char *strings_table = 0;
if (! strings_table)
{
bytes = compute_amount_of_memory_based_on_numname ();
strings_table = malloc (bytes);
construct_table_from_numname (strings_table);
}
return pointer_to_strings_table (strings_table, signal_number);
}
That wouldn't create excessive load overhead, nor would it require some
complex pre-processing macros. But how would one make that safe in a
multithreaded environment? If there are two instances of calling the
above at the same time there would be multiple mallocs and a potential
memory leak.
Dan
