[9fans] mallocz in APE

[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.

Re: [9fans] mallocz in APE

[Steve Simon]

> 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.

> 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

Re: [9fans] mallocz in APE

[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?

Re: [9fans] mallocz in APE

[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

Re: [9fans] mallocz in APE

[tlaronde]

On Thu, Jul 18, 2013 at 03:48:17PM +0100, Steve Simon wrote:
>
> 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"...)

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] mallocz in APE

[erik quanstrom]

On Thu Jul 18 10:49:16 EDT 2013, steve@quintile.net wrote:
> >> 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