Re: Re: [UnixOS2] libc

Sebastian Wittmeier (ShadoW) wrote:
> 
> On Mon, 23 Jun 2003 07:46:21 -0700, Ilya Zakharevich wrote:
> 
> >> There are some multi-user additions being developped, so setuid might well
> >> be able to get a uid != 0 in the not so distant future.
> 
> >???  We were discussing *existing* programs, did not we?
> 
> If we want to make "old programs work better without recompile" and
> OS/2 gets multi-user capable, setuid won't be a dummy function any
> longer, and will return the real uid. Some existing ports can't handle
> that added functionality. Either we leave the old setuid dummy for old
> programs (no improvement for existing programs), or we change the
> setuid (some existing programs cease to work correctly).

Apart from broken ports that define their own set/getuid(), is there
any reason why the program behaviour should rely on the current emx
behaviour? At the moment I can't think of any example but I've never
dealt with this API extensively.
I mean no code will contain something like
if (getuid() != -1) system("rm -fR /");
;-)


And for the case OS/2 might ever get multiuser capabilities,
If a program can't deal with user IDs or permissions then it can't deal
with user IDs or permissions (like a typical DOS program). In this
case it's irrelevant whether you use this program with the old emx
library (which doesn't support users) or the new libc (which does
support
users but the programs doesn't know). If you enable your multiuser
capabilities and the program fails then it fails unless you want to
run it as root.


As far as I can see we have three kinds of function problems:

a) Functions that have to be added (like the all times favorite
   strcasecmp): No problem, doesn't hurt old programs.

b) Functions with new behaviour (like set/getuid):
   - Current sources may contain dummy defines; nasty but must be
     removed anyway,
   - Old programs (binaries): Not effected if we keep the old
     ordinal number and the broken old function together (the
     new implementation of the function gets a new ordinal number).
   - Alternatively we don't keep the old implementation and the
     program has to deal with the new (correct) behaviour.
     We can decide this differently for every function depending on
     how likely is a software failure for this case.

c) Functions that change its declaration (like fseek if we change
   to 64 bit by default; how many of them are there?):
   - Old programs (binaries): If we want to keep binary compatibility
     the old function must keep its ordinal (but may get a new name
     -> fseek32)
   - We can make the new behaviour (fseek64) the default and still
     provide a macro to switch to the old behaviour.


Bye,
Andreas