EXTERN Macro Change to Support a Wider Set of AttributesDavid GravereauxDonal K. Fellows$Revision: 1.21 $
This TIP proposes a change to how the EXTERN macro in tcl.h works to support a wider range of compiler specific attributes.
With working on Borland support recently, I found that luckily the newest "free commandline tools" [] does support Microsoft's __declspec(dllexport) attribute. But at the same time, the older way with __export is still valid, but can't be used due to the order within the prototype declaration of the EXTERN macro.
What's this with the MS compiler:
CV9fZGVjbHNwZWMoZGxsZXhwb3J0KSBfX2NkZWNsIGludCBmdW5jIChpbnQgYSwgaW50IGIpOw==
will have to be this with Borland:
CWludCBfX2V4cG9ydCBfX2NkZWNsIGZ1bmMgKGludCBhLCBpbnQgYik7
The order of the attribute needs to be after the return type.
Even though __declspec is supported in the Microsoft style with version 5.5+ of the Borland compiler, if EXTERN could swap around the order a hair, old Turbo C v5.0 has a better chance to make a DOS library. Should someone feel the need.
Let's leave the existing EXTERN macro as-is and just make a new one called TCL_EXTERN to support the new behavior.
Karl Lembuaer (sp?) did a presentation @ OSCON regarding his recent tinytcl project %TODO: add link here% about his DOS port of Tcl 6.7 for use in a hand-held device.
Stepping backward for DOS support, may actually be a leap forward in an off-beat manner...
I saw something like this in a very old DDE extension that someone at Sun wrote. It was used as an example windows extension for years.
In example.h is this:
I2lmIGRlZmluZWQoX19XSU4zMl9fKQ==IyAgIGlmIGRlZmluZWQoX01TQ19WRVIpIwlkZWZpbmUgRVhQT1JUKGEsYikgX19kZWNsc3BlYyhkbGxleHBvcnQpIGEgYg==IyAgIGVsc2U=IwlpZiBkZWZpbmVkKF9fQk9STEFORENfXyk=IwkgICAgZGVmaW5lIEVYUE9SVChhLGIpIGEgX2V4cG9ydCBiIwllbHNlIwkgICAgZGVmaW5lIEVYUE9SVChhLGIpIGEgYg==IwllbmRpZg==IyAgIGVuZGlmI2Vsc2U=IyAgIGRlZmluZSBFWFBPUlQoYSxiKSBhIGI=I2VuZGlmRVhURVJOIEVYUE9SVChpbnQsRXhhbXBsZV9Jbml0KSBfQU5TSV9BUkdTXygoVGNsX0ludGVycCAqaW50ZXJwKSk7
That work is doing the same job, but I prefer the method that I'm proposing.
It is also mentioned on and feel it is rather out-of-date and the order issue with __export should be brought into the core with this patch and be fix for good.
Is>
CUVYVEVSTiBpbnQgRm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk7
Proposed>
CVRDTF9FWFRFUk4oaW50KSBGb29iYXJfSW5pdCAoVGNsX0ludGVycCAqaW50ZXJwKTs=
Is:
RVhURVJOIGludA==Rm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==I2lmZGVmIFVTRV9UQ0xfU1RVQlM=ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09IE5VTEwpIHs=ICAgICAgICByZXR1cm4gVENMX0VSUk9SOw==ICAgIH0=I2VuZGlmICAgIFRjbF9DcmVhdGVPYmpDb21tYW5kKGludGVycCwgImZvb2JhciIsIEZvb0JhciwgTlVMTCwgTlVMTCk7ICAgIHJldHVybiBUQ0xfT0s7fTs=
Proposed:
VENMX0VYVEVSTihpbnQpRm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==I2lmZGVmIFVTRV9UQ0xfU1RVQlM=ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09IE5VTEwpIHs=ICAgICAgICByZXR1cm4gVENMX0VSUk9SOw==ICAgIH0=I2VuZGlmICAgIFRjbF9DcmVhdGVPYmpDb21tYW5kKGludGVycCwgImZvb2JhciIsIEZvb0JhciwgTlVMTCwgTlVMTCk7ICAgIHJldHVybiBUQ0xfT0s7fTs=
Preprocessor output is the following:
Borland:
LyogZm9vYmFyLmMgMTQ6ICovZXh0ZXJuICBpbnQgX19leHBvcnQ=LyogZm9vYmFyLmMgMTU6ICovRm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=LyogZm9vYmFyLmMgMTY6ICovew==LyogZm9vYmFyLmMgMTc6ICovLyogZm9vYmFyLmMgMTg6ICovaWYgKFRjbF9Jbml0U3R1YnMoaW50ZXJwLCAiOC4xIiwgMCkgPT0gMCkgew==LyogZm9vYmFyLmMgMTk6ICovcmV0dXJuIDE7LyogZm9vYmFyLmMgMjA6ICovfQ==LyogZm9vYmFyLmMgMjE6ICovLyogZm9vYmFyLmMgMjI6ICovKHRjbFN0dWJzUHRyLT50Y2xfQ3JlYXRlT2JqQ29tbWFuZCkoaW50ZXJwLCAiZm9vYmFyIiwgRm9vQmFyLCAwLCAwKTs=LyogZm9vYmFyLmMgMjM6ICovcmV0dXJuIDA7LyogZm9vYmFyLmMgMjQ6ICovfTs=
VC++:
ZXh0ZXJuICBfX2RlY2xzcGVjKGRsbGV4cG9ydCkgaW50Rm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09ICgodm9pZCAqKTApKSB7ICAgICAgICByZXR1cm4gMTs=ICAgIH0=I2xpbmUgMjIgImZvb2Jhci5jIg==ICAgICh0Y2xTdHVic1B0ci0+dGNsX0NyZWF0ZU9iakNvbW1hbmQpKGludGVycCwgImZvb2JhciIsIEZvb0JhciwgKCh2b2lkICopMCksICgodm9pZCAqKTApKTs=ICAgIHJldHVybiAwOw==fTs=
MinGW (native gcc on win):
ZXh0ZXJuICAgICAgIGludA==Rm9vYmFyX0luaXQgKFRjbF9JbnRlcnAgKmludGVycCk=ew==ICAgIGlmIChUY2xfSW5pdFN0dWJzKGludGVycCwgIjguMSIsIDApID09ICgodm9pZCAqKTApICkgew==ICAgICAgICByZXR1cm4gMSA7ICAgIH0=ICAgICh0Y2xTdHVic1B0ci0+dGNsX0NyZWF0ZU9iakNvbW1hbmQpIChpbnRlcnAsICJmb29iYXIiLCBGb29CYXIsICgodm9pZCAqKTApICwgKCh2b2lkICopMCkgKTs=ICAgIHJldHVybiAwIDs=fTs=
In tclInt.h starting around line 1916, are prototypes for the internal cmdprocs. I can't think of any reason why they should be exported. Also note the comment about line:1673, as it states:
Lyo=ICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICogUHJvY2VkdXJlcyBzaGFyZWQgYW1vbmcgVGNsIG1vZHVsZXMgYnV0IG5vdCB1c2VkIGJ5IHRoZSBvdXRzaWRlICogd29ybGQ6ICotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tICov
As the current EXTERN macro places ""everything"" exportable, the use of EXTERN following this comment in tclInt.h is contradictory. In place of EXTERN for this purpose I used the new TCL_EXTRNC in the reference implementation.
This document has been placed in the public domain.