Re: [MiNT] MiNTLib 0.51

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi!

On Fri, May 21, 1999 at 07:29:39AM +0200, Julian Reschke wrote:
> > That "who the hell" was me. ;-)
> > And all systems I know of that use the MiNTLib have 32 bit pointers and 32
> > bit long ints.
> 
> Sorry, I did not intend to flame you. My (mis)understanding was that this
> code was coming from some other Unix system, and I was wondering how in the
> "generic" Unix world would write code that would make these assumptions.

Don't worry, I did not feel to be the victim of a flame. ;-)

> For the Atari this is of course tolerable.

Kind of.  I will try my best to make it compile without warnings both with
gcc and Pure.

> Finally I understand what weak symbols are for. Thanks.

The main purpose of using weak symbols is something else however.  They
can aid you in keeping the namespace clean in multi-standard libraries.
Say, POSIX wants a lib function "int foo (int a, int b)" and Unix98 has a
similar function "int foobar (int a)" which is equivalent to 
"foo (int, 0)".  In the lib you would probably do the following:

int __foo (int a, int b)
{
  return retval;
}  
weak_alias (foo, __foo)

In another module:
int foobar (int a) { return __foo (a, 0); }

Now the library can call __foo (and foo.o gets dragged into the link) but
the user can still define his own version of foo() because that doesn't
conflict with the strong symbol __foo.  The library function "foobar" will
always call the right "__foo", never a user-defined "foo".

You probably know that situations like this are very common in the MiNTLib
and I hope that I can solve these problems with weak symbols.

> > internally doesn't care if an argument or return value is really a pointer
> > or a long (or unsigned long).
> 
> As Michael stated this is only true as long as nobody implements parameter
> passing through registers...

I will distinguish between pointers and scalars.

> Speaking of other solutions: it seems to me that all this could be avoided
> if we had MagiC style shared libraries under MiNT, and if MiNT lib would be
> implemented as shared library.

Nope, see below.

> In which case "open()" would just be a proxy, and you would dynamically link
> either mintlib.slb or a ZLIB-enabled replacement...

And how do you want to get the address of the "real" open function?  You
either need syscall() or some other way to access the internal library
implementation.  See the sources for the zlibc, even for shared libs you
still need some mechanism like this.

The problem is that the reference to "open" would get resolved within the
shared library and so you need another name for the library function.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de