RE: Don't export lt__error_strings

[Peter Ekberg]

Hi!

* Ralf Wildenhues wrote on Friday, September 23, 2005 15:37 CEST:
> Hi Peter,
> 
> * Peter Ekberg wrote on Fri, Sep 23, 2005 at 02:02:18PM CEST:

*snip*

> > So, here's a patch:
> 
> Major nit: it doesn't compile:
> 
> | +const char *
> | +lt__set_last_error_string (const char *errormsg)
> | +{
> | +  return lt__last_error = last_error;
> |  }
> 
> You wanted to set it to errormsg, not last_error.

Right. Sorry for wasting your time. I tested, then made one
last round of minor changes without retesting. I should know
better...

> Minor nit: I would have liked the issue to be solved _right_, i.e.,
> without any remaining necessary relocations.  Might as well show users
> how to achieve this with an array of strings.  Do you want 
> work on this?
> 
> If yes, please read dsohowto.pdf chapter 2.4.3 (or around 
> there) titled

Oh, that old worthless document. Who needs that crap? :-)

*reads again*

> "Arrays of Data Pointers" and Appendix B.  I would probably prefer
> the first described method (should be the least work, too), but we
> might need to adapt it a bit so all compilers grok it, i.e., do:
> 
>   static const char msgs[LT_ERROR_MAX][LT_ERROR_LEN_MAX + 1] = {
>     "msg1",
>     ...
>   };
> 
> instead of using C99 designated initializers
> 
>   static const char msgs[LT_ERROR_MAX][LT_ERROR_LEN_MAX + 1] = {
>     [ERR1] = "msg1",
>     ...
>   };
> 
> but you might want to look at the other proposed methods, too.

Ok, going with the first method. I could not think up a good
way to get the preprocessor to find out the longest error string
so I counted it and defined LT_ERROR_LEN_MAX to 35. I then did
some tests to see if gcc warned about too long strings in case
someone carelessly adds a longer error string without changing
the define. To my discomfort gcc does not seem to count the
nul terminator when it decides whether to warn or not (-Wall).
But I might be mistaken and might have made a mistake counting
or something, but I don't think so. I checked a couple of times
because I was so baffled.

> >     * libltdl/libltdl/lt__private.h, libltdl/lt_error.c:
> >     Don't export the lt__last_error and lt__error_strings
> >     variables.
> >     * libltdl/libltdl/lt__private.h (LT__STRERROR, LT__GETERROR)
> >     (LT__SETERRORSTR): Adjust to not use the above variables,
> >     instead use the following functions...
> >     * libltdl/lt_error.c: (lt__error_string, lt__last_error_string)
> >     (lt__set_last_error_string): Reimplement the functionallity
> >     in these functions instead.
> >     * libltdl/m4/ltdl.m4: Bump serial number.
> > 
> > The serial number bump in libltdl/m4/ltdl.m4 is just a guess...
> 
> It's wrong.  macro serial version and library interface version are
> independent of one another.  If at all, 
> Makefile.am:VERSION_INFO should
> be changed.  But we agreed not to do that (I only haven't updated
> HACKING yet).

Ok, striking that, new attempt attached.

        * libltdl/libltdl/lt__private.h, libltdl/lt_error.c:
        Don't export the lt__last_error and lt__error_strings
        variables. Define lt__error_strings so that no relocations
        are needed.
        * libltdl/libltdl/lt__private.h (LT__STRERROR, LT__GETERROR)
        (LT__SETERRORSTR): Adjust to not use the above variables,
        instead use the following functions...
        * libltdl/lt_error.c: (lt__error_string, lt__get_last_error)
        (lt__set_last_error): Reimplement the functionality in
        these functions instead.

Cheers,
Peter

head-do-not-export-lt__error_strings-2.patch
Description: head-do-not-export-lt__error_strings-2.patch