Subject: Re: locale library (was Re: Back in June...)
To: None <firstname.lastname@example.org>
From: T.SHIOZAKI <AoiMoe@imou.to>
Date: 01/08/2000 22:39:59
From: Noriyuki Soda <email@example.com>
Subject: locale library (was Re: Back in June...)
Date: Sat, 8 Jan 2000 02:27:38 +0900 (JST)
> There are numbers of problems to integrate this to NetBSD, though.
> For example,
> - NetBSD has a problem to call dlopen()/dlsym()/... from
> functions in libc. (FreeBSD doesn't have this particular
Currently, this runelocale (XPG4DL) library has the peculiar functions
named ___locale_dl* instead of native dl* functions on the NetBSD/ELF
platform. The background of this problem:
- GNU ld does not embed all unreferenced global symbols into
.dynsym section of executable in default of -export-dynamic option.
-export-dynamic option is usually unused.
- The body of dl* functions are defined in the startup code (crt0.c)
on the current NetBSD.
- So far, there is no reference to dl* functions from inside of libc.
Thus, if new function using dl* functions is added into libc,
ld.so cannot resolve such functions for the old binaries which is linked
with old libc.
I think that dl* functions should be defined in libc instead of crt0.c.
> - Native issetugid(2) system call is really needed, otherwise
> very serious security flaw will appear. Since this library
> loads user configurable shared object, this user
> configuration feature should be avoided on setuid/setgid
> executables by checking issetugid(2).
To avoid this security hole, codes which compare setuid and
seteuid are used now, but not enough. However, it is able to
avoid easily: ignore any environment variable in the locale stuff.
> - We have to consider how to extend FILE structure without
> losing binary compatibilty.
Perhaps, we need not to take care of this problem, because of
the following reasons:
- Most programs usually use FILE as the opaque handle.
- To keep binary compatibility with MB_LEN_MAX, I have already separated
setlocale into compatible one and new (renamed) one.
Thus, when we will the wide-char I/O functions, we will be able to
avoid this problem by the following way:
- If the compatible version of setlocale function is called
(or, setlocale is not called), fopen and others also work in
the compatible mode.
- If the new setlocale is called, I/O functions work in the new mode.
Takuya SHIOZAKI - Chair of IMOU.
The I18n/M17n project On Unix environments (IMOU), Japan.