[uClibc] sys_errlist

[Bernardo Innocenti]

On Wednesday 16 July 2003 08:49, Manuel Novoa III wrote:

> I checked the archives for the previous messages in this thread and
> found that you referenced strerror.c, which I removed from uClibc
> over a year ago.  It last appeared in version 0.9.12.  If you're not
> interested in upgrading to the latest version, you should at least
> look at the diffs to see what bugs got fixed.

I'm using version 0.9.19 from the latest uClinux distribution. The
problem is that for several months I did new imports into our
CVS using a stupid way to do the merge:

 cvs checkout -jUCLINUX:yesterday -jUCLINUX uclinux

instead of the correct way:

 cvs checkout -jUCLINUX_20030515 -jUCLINUX_20030525 uclinux

As a result, I have a lot of files in my HEAD branch which should
have been removed by the merge.

Fixing this requires a long and tedious search all over the source
tree so I've not bothered.


> Regarding your concerns about the size increase in staticly linked apps
> due to the system error messages, I'd be happy to add a an option to
> the current version of uClibc to force strerror (and strsignal for
> that matter) to omit the actual text messages.  Of course, that won't
> help applications still using sys_errlist[].  But any application still
> using sys_errlist[] really needs to be updated.
>
> If you wanted to store the system error message text in a file and
> load it dynamically, all you would have to do is replace the function
>   int _susv3_strerror_r(int errnum, char *strerrbuf, size_t buflen)
> in the current version of uClibc.  Well... that _and_ get rid of all
> the outdated sys_errlist[] cruft in any relevant apps.

So I'd better fix that instead. Does glibc provide sys_errlist[] to
applications? Is it required by any relevant standard? The fact that
there are no underscores in the name makes me think that it's not
something internal.

> Currently no uClibc routines use sys_errlist[].  About a year ago,
> I removed it completely and then reinstated it because of complaints
> that it was still used in some of the uClinux userland apps.  So I put
> a link warning in place that it was deprecated (in SUSv2) and it would
> eventually be removed (as it has from SUSv3).  In fact, I will probably
> make it a build-time config option in the next release.

Actually, the application where I've noticed this problem - telnetd -
does not use sys_errlist[] at all, but all the messages get linked into
the binary because of perror(). I'd like to drop this overhead.

> If you _still_ wanted to support sys_errlist[] with a scheme like you
> suggest above, you would need to do a bit more.  A failure in opening
> or reading the file, or in memory allocation, would result in one or
> more of the table entries being NULL. Last time I looked, at least 
> some of the uClinux userland apps using sys_errlist[] were not prepared
> for a NULL ptr corresponding to a valid errno.

Hmmm... if they're just passing to uClinux version of printf(),
they should be safe. Otherwise, we could always set all slots to point
at an empty string instead of storing NULL into them.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Please don't send Word attachments - http://www.gnu.org/philosophy/no-word-attachments.html