[9fans] mallocz in APE

[yaroslav]

APE programs which require libmp fail to link due to unresolved
mallocz symbol. Easily solved by providing a local implementation,
but why: it's already there - in an alternative form though:

cpu% nm /386/lib/ape/libap.a | grep -i mallocz
9mallocz.8: T _MALLOCZ
9mallocz.8: U malloc
9mallocz.8: U memset

I don't really see the reasons for this rename, yet other APE libs
like libsec follow it:

cpu% nm /386/lib/ape/libsec.a | grep -i mallocz
sha2_64.8: U _MALLOCZ
sha2_128.8: U _MALLOCZ
rsaalloc.8: U _MALLOCZ
egalloc.8: U _MALLOCZ
dsaalloc.8: U _MALLOCZ

And libmp does not:

cpu% nm /386/lib/ape/libmp.a | grep -i mallocz
mpaux.8: U mallocz
mpmul.8: U mallocz

Here's why:

cpu% grep -ni mallocz /sys/src/ape/lib/*/*.h /sys/src/ape/lib/*/*/*.h
/sys/src/ape/lib/9/libc.h:105: extern void *_MALLOCZ(int, int);
/sys/src/ape/lib/9/libc.h:132: #define mallocz _MALLOCZ
/sys/src/ape/lib/draw/libc.h:100: extern void *_MALLOCZ(int, int);
/sys/src/ape/lib/draw/libc.h:127: #define mallocz _MALLOCZ
/sys/src/ape/lib/mp/port/libc.h:14: extern void* mallocz(ulong, int);
/sys/src/ape/lib/sec/port/libc.h:105: extern void *_MALLOCZ(int, int);
/sys/src/ape/lib/sec/port/libc.h:132: #define mallocz _MALLOCZ

Note the libmp's one standing out.

A quick fix is to bring up mallocz bits in
/sys/src/ape/lib/mp/port/libc.h into agreement with the rest.

Replacing _MALLOCZ back with mallocz within APE realm seems to me a
better option to consider.

Comments are welcome.

[Steve Simon]

Post by yaroslav
A quick fix is to bring up mallocz bits in
/sys/src/ape/lib/mp/port/libc.h into agreement with the rest.

I would say this is the correct fix.

Post by yaroslav
Replacing _MALLOCZ back with mallocz within APE realm seems to me a
better option to consider.

I don't think this is better. APE generally tries very hard to be compliant
to the spirit of ANSI (or POSIX with _POSIX_EXTENSION defined), this
includes not poluting the namespace with plan9isms where possible.

Having said this what about setmalloctag() getcallerpc(), etc etc.

-Steve

[Yaroslav]

Post by Steve Simon

Post by yaroslav
Replacing _MALLOCZ back with mallocz within APE realm seems to me a
better option to consider.

I don't think this is better. APE generally tries very hard to be compliant
to the spirit of ANSI (or POSIX with _POSIX_EXTENSION defined), this
includes not poluting the namespace with plan9isms where possible.
Having said this what about setmalloctag() getcallerpc(), etc etc.

It is internal to the libraries and is not exposed to the APE apps, right?

[Steve Simon]

Post by Yaroslav

Post by Steve Simon
Having said this what about setmalloctag() getcallerpc(), etc etc.

It is internal to the libraries and is not exposed to the APE apps, right?

But because getcallerpc() is not prefexid by an underscore or file scope,
by the "rules" it is poluting the namespace of the APE app.

Its a minor thing I know but somone put a lot of effort into adding _MALLOCZ() and
all the other internal funcs it seems a pity to not do the same with
setmalloctag() and getcallerpc().

its not a major issue, probably OCD on my part.

-Steve

[erik quanstrom]

Post by Steve Simon

Post by Yaroslav

Post by Steve Simon
Having said this what about setmalloctag() getcallerpc(), etc etc.

It is internal to the libraries and is not exposed to the APE apps, right?

But because getcallerpc() is not prefexid by an underscore or file scope,
by the "rules" it is poluting the namespace of the APE app.
Its a minor thing I know but somone put a lot of effort into adding _MALLOCZ() and
all the other internal funcs it seems a pity to not do the same with
setmalloctag() and getcallerpc().

unfortunately the ape libmp and libsec work has gotten a bit out of sync.
i think patches have been submitted, but here's the state we're (9atom) at. mallocz
is #defined to _MALLOCZ for internal use only. the reason for the #define
is to avoid any additional source manipulation tricks for /sys/src/lib* source
directly compiled as ape source.

; g mallocz /sys/src/ape/lib
/sys/src/ape/lib/9/libc.h:149: #define mallocz _MALLOCZ
; nm /amd64/lib/ape/libsec.a|grep mallocz
; nm /amd64/lib/ape/libmp.a|grep mallocz
; nm /amd64/lib/ape/libauth.a|grep mallocz

getcallerpc is not defined in any header files, so it shouldn't be
a first-order issue. (there are so many of those to chose from!)

there is no (get|set)(re)?alloctag in ape malloc, so questions about
them are moot.

- erik

[t***@polynum.com]

Post by Steve Simon
But because getcallerpc() is not prefexid by an underscore or file scope,
by the "rules" it is poluting the namespace of the APE app.
Its a minor thing I know but somone put a lot of effort into adding _MALLOCZ() and
all the other internal funcs it seems a pity to not do the same with
setmalloctag() and getcallerpc().
its not a major issue, probably OCD on my part.

No, you are perfectly right. Having to deal with "porting" a software
to various OSes, every namespace pollution comes in the way because
one can not rely on one and only one doc: precisely the standard,
without having to know the various time dependent idiosynchrazies
(the standard says that it is that, and everything else should not
be here except with a leading '_' etc.). (I had to add macros for
several TeX routines whose names are not conflicting with ANSI C,
but happen to conflict with routines added by system X in its libc;
and generally, one add a macro definition to rename... before being
told that the new name is conflicting with a name added by system
Y version a.b.c.d in its libc...; so the "solution" is always a
temporary one; with the standard, one could prove being right;
without the standard, one can only prove being OK "so far"...)