Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1868171 ] AOLserver needs Tcl_GetMemoryInfo, but it's now MODULE_SCOPE
|
From: SourceForge.net <no...@so...> - 2008-03-19 23:28:59
|
Bugs item #1868171, was opened at 2008-01-10 04:28 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1868171&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 40. Memory Allocation Group: obsolete: 8.5.0 Status: Open Resolution: Fixed Priority: 9 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Donal K. Fellows (dkf) Summary: AOLserver needs Tcl_GetMemoryInfo, but it's now MODULE_SCOPE Initial Comment: Tcl_GetMemoryInfo was public in the 8.4 train, but it's now declared as MODULE_SCOPE in 8.5.0. AOLserver 4.5.0 requires this function. Assuming that this was an intentional change meant to (further?) deprecate Tcl_GetMemoryInfo, it would at least be nice to have a config option to make the function visible for applications like AOLserver that need it. ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2008-03-19 23:29 Message: Logged In: YES user_id=79902 Originator: NO It's not in any stubs table, and it has a void return type. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2008-03-19 20:06 Message: Logged In: YES user_id=72656 Originator: NO I meant internal decls, rather than public ones. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-03-19 19:58 Message: Logged In: YES user_id=80530 Originator: NO Taking it private would impose a significant burden on AOLserver, right? Having to add #include "tclInt.h" as well as all the build script machinery to find and depend on private headers.? ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2008-03-19 19:48 Message: Logged In: YES user_id=72656 Originator: NO Yes, the API should unconditionally exist if it is in public decls. In the case of non-thread-alloc, it should return a TCL_ERROR or some other mem info (if anything else is appropriate). Perhaps a better approach is to take the function private for 8.5. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-03-19 19:35 Message: Logged In: YES user_id=80530 Originator: NO Looks like this routine is declared unconditionally in tcl.h now, but is only defined in the TCL_THREADS and USE_THREAD_ALLOC configuration. Could that be a problem? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2008-03-19 16:03 Message: Logged In: YES user_id=79902 Originator: NO Now we know who needs it, we can expose this. Not currently in stubs table as intended for use in applications only; open another bug if this needs changing. Not documenting it; RTFS to find out what it does if you care! :-) ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-03-13 14:22 Message: Logged In: YES user_id=80530 Originator: NO raising priority again, since we're getting 8.5.2 ready for release. ---------------------------------------------------------------------- Comment By: gustafn (gneumann) Date: 2008-02-26 18:41 Message: Logged In: YES user_id=1781785 Originator: NO concerning: "it would at least be nice to have a config option to make the function visible for applications like AOLserver that need it." people will like to use aolserver with stock tcl-binaries (e.g. on debian), so, an -DAOLSERVER might not be a good solution for them. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-02-26 15:15 Message: Logged In: YES user_id=80530 Originator: NO raising priority; would be good to resolve this in time for 8.5.2. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-01-10 17:22 Message: Logged In: YES user_id=80530 Originator: NO And TclLookupSimpleVar() ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-01-10 17:19 Message: Logged In: YES user_id=80530 Originator: NO Seems to me that MODULE_SCOPE is fairly clearly the wrong thing for this routine, since there are no callers of it within the Tcl "module". Appears that the routines TclSetEnv() and TclUnsetEnv() have a similar status. Might as well fix them too. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-01-10 17:12 Message: Logged In: YES user_id=80530 Originator: NO Also not documented, and not in any stubs table, public or internal. I see the routine entered the code base just before Tcl 8.4b1 by hobbs. Perhaps he can clarify the intended status? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2008-01-10 16:58 Message: Logged In: YES user_id=80530 Originator: NO We should get this straightened out, I agree. Appears the status of Tcl_GetMemoryInfo() has long been ambiguous, since it does not appear in any header file, public or internal. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1868171&group_id=10894 |