Re: [TCLCORE] Tcl_LinkVar changes Re: int types

On Mon, Jan 30, 2017 at 01:46:48PM +0100, Jan Nijtmans wrote:
> 2017-01-30 13:24 GMT+01:00 avl:> > Why doesn't the LinkVar-API not just take a sizeof(Ctype) argument,> > and let the TCL_LINK_... flag just specify the category: signed,> > unsigned, or float, then internally picking the right type (long,> > unsigned short, double, ...) for the given size and category?> That's an easy answer: Simply because no-one thought on that> before, or maybe someone thought of it before but didn't start> implementing it.

For the hypothetic case, that someone thought of separating size
and category, but gave up on that there just isn't an extra field,
(resp. argument for Tcl_LinkVar), then there's this option with
three more constants and three macros:
  LINK_CTG_SIGNED,      LINK_CTG_UNSIGNED,      LINK_CTG_FLOAT
  TCL_LINK_SIGNED_SIZE, TCL_LINK_UNSIGNED_SIZE, TCL_LINK_FLOAT_SIZE
(CTG is for category)

Then, users specify e.g.:   TCL_LINK_FLOAT_SIZE(sizeof(double))
as Tcl_LinkVar's 4th argument.

macro TCL_LINK_xxx_SIZE(bytesize) is #defined as:
  LINK_CTG_xxx + (LINK_SIZE_SCALE * min(1,max(MAX_LINK_SIZE,bytesize)))
for xxx in SIGNED,UNSIGNED,FLOAT
(not sure, if all constants used in a TCL_ macro need to have a TCL_
prefix, as well, but surely they need to go into tcl.h anyway.)

Then, most of those TCL_LINK_* constants describing standard C 
integer or float types could be declared as "legacy".
Afterall, they don't guarantee any particular size, anyway.

Only TCL_LINK_WIDE_INT, TCL_LINK_WIDE_UINT, TCL_LINK_STRING and
TCL_LINK_BOOLEAN would not be obsoleted (still supported, of c.).

Picking them apart within LinkTraceProc() and ObjValue():
   switch ( linkPtr->type & (LINK_SIZE_SCALE-1) ) ...
should be straightforward enough to map to local-arch agnostic
int##_t or uint_##_t types (not sure about float/double here).

> It would indeed make things simpler, the challenge> is keeping things compatible with how it is now.> So, go ahead ;-)

To my understanding, this is entirely compatible with the old
LINK-type constants.

Any feedback?
Anything outside
  tcl.h   tclLink.c  LinkVar.3
to care for?
Adopt tclExecute.c and tclCompile.c to use the new macros?
Any guidelines about or against macros?

> I'll happily sponsor such a TIP and implementation.

I certainly would need some help about Tcl's DOs and DONTs.

> > Is it possible for same-sized,same-category data to go awry, when> > the bits get written as one "same" type and read as another "same"> > type?> I think that would work fine.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core