| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| |
| | |
macros using Tcl_NewIntObj, Tcl_DbNewLongObj and Tcl_SetIntObj.
Starting with Tcl 8.5, this is exactly the same, it only eliminates code duplication.
Eliminate use of NO_WIDE_TYPE everywhere: It's exactly the same as TCL_WIDE_INT_IS_LONG
|
| |
| |
| |
| |
| | |
macros using Tcl_NewIntObj, Tcl_DbNewLongObj and Tcl_SetIntObj.
Starting with Tcl 8.5, this is exactly the same, it only eliminates code duplication.
|
|\ \
| |/ |
|
| | |
|
| | |
|
|\ \
| |/
| |
| | |
setFromAnyProc, create a proper error message.
|
| |
| |
| |
| | |
setFromAnyProc, create a proper error message.
|
| |
| |
| |
| | |
typePtr->setFromAnyProc (except the call from inside the Tcl_ConvertToType function) from the Tcl core.
|
|\ \
| |/ |
|
| |
| |
| |
| | |
the same field, but it allows twoPtrValue.ptr2 to be used for other purposes.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/ |
|
| |\ |
|
| | | |
|
| | |
| | |
| | | |
pipeline creation, package handling, procedures, [scan] formats)
|
| | | |
|
| | |
| | |
| | |
| | | |
TclFreeObj()
|
| | |
| | |
| | | |
rest of Tcl source code. No ABI change. API change *should* be harmless.
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | | |
* generic/tclCompile.c: with TclParseBackslash() where possible.
* generic/tclCompCmdsSZ.c:
* generic/tclParse.c:
* generic/tclUtil.c:
|
| |\ \
| | |/
| | |
| | |
| | | |
* generic/tclCompile.c: with TclParseBackslash() where possible.
* generic/tclParse.c:
* generic/tclUtil.c:
|
|\ \ \
| |/ /
| | | |
cause more harm than good. Purged them (except in zlib files).
|
| |\ \
| | |/
| | | |
more harm than good. Purged them.
|
| | |
| | |
| | | |
more harm than good. Purged them.
|
| | |
| | |
| | |
| | | |
[Bug 2895323]. Backport from Tcl 8.5 branch, change by Don Porter.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
EvalTokensStandard, Tcl_EvalEx, EvalEx, TclAdvanceContinuations,
TclEvalObjEx):
* generic/tclCmdMZ.c (Tcl_SwitchObjCmd, ListLines):
* generic/tclCompCmds.c (*):
* generic/tclCompile.c (TclSetByteCodeFromAny, TclInitCompileEnv,
TclFreeCompileEnv, TclCompileScript):
* generic/tclCompile.h (CompileEnv):
* generic/tclInt.h (ContLineLoc, Interp):
* generic/tclObj.c (ThreadSpecificData, ContLineLocFree,
TclThreadFinalizeObjects, TclInitObjSubsystem,
TclContinuationsEnter, TclContinuationsEnterDerived,
TclContinuationsCopy, TclContinuationsGet, TclFreeObj):
* generic/tclProc.c (TclCreateProc):
* generic/tclVar.c (TclPtrSetVar):
* tests/info.test (info-30.0-22):
Extended parser, compiler, and execution with code and attendant
data structures tracking the positions of continuation lines which
are not visible in script's, to properly account for them while
counting lines for #280, during direct and compiled execution.
|
| | |
| | |
| | |
| | |
| | |
| | | |
command; cannot trigger this from Tcl itself, but crash reported
on xotcl. This check is new to 8.4 but exists in 8.5, so this is a
backport or something. Thanks Gustaf Neumann.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* generic/tclCompile.h: tracing of proc and command entry &
* generic/tclBasic.c: return, bytecode execution, object
* generic/tclExecute.c: allocation and more; with essentially
* generic/tclInt.h: zero cost when tracing is inactive;
* generic/tclObj.c: enable with --enable-dtrace configure
* generic/tclProc.c: arg (disabled by default, will only
* unix/Makefile.in: enable if DTrace is present).
* unix/configure.in: [Patch 1793984]
* macosx/Makefile: enable DTrace support.
* unix/configure: autoconf-2.13
|
| | | |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
* generic/tclEvent.c: order of finalization routines.
* generic/tclInt.h: [Bug 1251399]
* generic/tclObj.c:
|
| | |
| | |
| | |
| | |
| | | |
* generic/tclObj.c (Tcl_GetIntFromObj): permit 0x80000000 to be
recognized as an integer on TCL_WIDE_INT_IS_LONG systems [Bug 1090869].
|
| | | |
|
| | |
| | |
| | |
| | | |
the int value of a wideInteger. [Bug 1027690]
|
| | |
| | |
| | |
| | | |
TCL_WIDE_INT_IS_LONG platforms.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
management of the cmdName Tcl_ObjType the opposite way, to always
use the twoPtrValue instead of always using the otherValuePtr.
Previous fix on 2003-05-12 broke several extensions that wanted
to poke around with the twoPtrValue.ptr2 value of a cmdName
Tcl_Obj, like TclBlend and e4graph. [Bug 726018]
|
| | |
| | |
| | |
| | |
| | | |
otherValuePtr or the twoPtrValue.ptr1 fields to store a
(ResolvedCmdName *) as the internal rep. [Bug 726018].
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* generic/tclObj.c is defined on all platforms, even those where
* generic/tclPort.h TCL_WIDE_INT_IS_LONG is defined. Also made
the Tcl_Value struct have a wideValue field on all platforms. This is
a ***POTENTIAL INCOMPATIBILITY*** for TCL_WIDE_INT_IS_LONG platforms
because that struct changes size. This is the same TIP 72
incompatibility that was seen on other platforms at the 8.4.0 release,
when this change should have happened as well. [Bug 713562]
* generic/tclInt.h: New internal macros TclGetWide() and
TclGetLongFromWide() to deal with both forms of the "wideInt"
Tcl_ObjType, so that conditional TCL_WIDE_INT_IS_LONG code
is confined to the header file.
* generic/tclCmdAH.c: Replaced most coding that was conditional
* generic/tclCmdIL.c: on TCL_WIDE_INT_IS_LONG with code that
* generic/tclExecute.c: works across platforms, sometimes using
* generic/tclTest.c: the new macros above to do it.
* generic/tclUtil.c:
* generic/tclVar.c:
|
| | |
| | |
| | |
| | | |
[Bug 713562]
|
| | |
| | |
| | |
| | |
| | | |
the validity tests on internal rep of a "cmdName" value to avoid
invalid reads reported by valgrind.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
comments to describe when the function can be entered for the same
Tcl_Obj* multiple times. This is a continuation of the 2009-11-10
entry where a memory leak was plugged, but where not sure if that
was just a band-aid to paper over some other error. It isn't, this
is a legal situation.
|
| | |
| | |
| | |
| | | |
[Bug 2895323]
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
objThreadMap and lineCLPtr hashtables. Also make the names of the
continuation line information initialization and finalization
functions more consistent. Patch supplied by Joe Mistachkin
<joe@mistachkin.com>.
|