| ︙ | | | ︙ | |
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
* special conditions in the parsing of a format specifier.
*/
#define BINARY_ALL ((size_t)-1) /* Use all elements in the argument. */
#define BINARY_NOCOUNT ((size_t)-2) /* No count was specified in format. */
/*
* The following flags may be ORed together and returned by GetFormatSpec
*/
#define BINARY_SIGNED 0 /* Field to be read as signed data */
#define BINARY_UNSIGNED 1 /* Field to be read as unsigned data */
/*
* The following defines the maximum number of different (integer) numbers
* placed in the object cache by 'binary scan' before it bails out and
* switches back to Plan A (creating a new object for each value.)
* Theoretically, it would be possible to keep the cache about for the values
* that are already in it, but that makes the code slower in practise when
* overflow happens, and makes little odds the rest of the time (as measured
* on my machine.) It is also slower (on the sample I tried at least) to grow
* the cache to hold all items we might want to put in it; presumably the
* extra cost of managing the memory for the enlarged table outweighs the
* benefit from allocating fewer objects. This is probably because as the
* number of objects increases, the likelihood of reuse of any particular one
* drops, and there is very little gain from larger maximum cache sizes (the
|
|
|
|
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
* special conditions in the parsing of a format specifier.
*/
#define BINARY_ALL ((size_t)-1) /* Use all elements in the argument. */
#define BINARY_NOCOUNT ((size_t)-2) /* No count was specified in format. */
/*
* The following flags may be OR'ed together and returned by GetFormatSpec
*/
#define BINARY_SIGNED 0 /* Field to be read as signed data */
#define BINARY_UNSIGNED 1 /* Field to be read as unsigned data */
/*
* The following defines the maximum number of different (integer) numbers
* placed in the object cache by 'binary scan' before it bails out and
* switches back to Plan A (creating a new object for each value.)
* Theoretically, it would be possible to keep the cache about for the values
* that are already in it, but that makes the code slower in practice when
* overflow happens, and makes little odds the rest of the time (as measured
* on my machine.) It is also slower (on the sample I tried at least) to grow
* the cache to hold all items we might want to put in it; presumably the
* extra cost of managing the memory for the enlarged table outweighs the
* benefit from allocating fewer objects. This is probably because as the
* number of objects increases, the likelihood of reuse of any particular one
* drops, and there is very little gain from larger maximum cache sizes (the
|
| ︙ | | | ︙ | |
374
375
376
377
378
379
380
381
382
383
384
385
386
387
|
if (numBytesPtr != NULL) {
*numBytesPtr = baPtr->used;
}
return baPtr->bytes;
}
unsigned char *
TclGetBytesFromObj(
Tcl_Interp *interp, /* For error reporting */
Tcl_Obj *objPtr, /* Value to extract from */
int *numBytesPtr) /* If non-NULL, write the number of bytes
* in the array here */
{
|
>
|
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
|
if (numBytesPtr != NULL) {
*numBytesPtr = baPtr->used;
}
return baPtr->bytes;
}
#if !defined(TCL_NO_DEPRECATED)
unsigned char *
TclGetBytesFromObj(
Tcl_Interp *interp, /* For error reporting */
Tcl_Obj *objPtr, /* Value to extract from */
int *numBytesPtr) /* If non-NULL, write the number of bytes
* in the array here */
{
|
| ︙ | | | ︙ | |
401
402
403
404
405
406
407
408
409
410
411
412
413
414
|
return NULL;
} else {
*numBytesPtr = (int) numBytes;
}
}
return bytes;
}
/*
*----------------------------------------------------------------------
*
* Tcl_SetByteArrayLength --
*
* This procedure changes the length of the byte array for this object.
|
>
|
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
|
return NULL;
} else {
*numBytesPtr = (int) numBytes;
}
}
return bytes;
}
#endif
/*
*----------------------------------------------------------------------
*
* Tcl_SetByteArrayLength --
*
* This procedure changes the length of the byte array for this object.
|
| ︙ | | | ︙ | |
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
|
length = offset;
}
if (length == 0) {
return TCL_OK;
}
/*
* Prepare the result object by preallocating the caclulated number of
* bytes and filling with nulls.
*/
TclNewObj(resultPtr);
buffer = Tcl_SetByteArrayLength(resultPtr, length);
memset(buffer, 0, length);
|
|
|
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
|
length = offset;
}
if (length == 0) {
return TCL_OK;
}
/*
* Prepare the result object by preallocating the calculated number of
* bytes and filling with nulls.
*/
TclNewObj(resultPtr);
buffer = Tcl_SetByteArrayLength(resultPtr, length);
memset(buffer, 0, length);
|
| ︙ | | | ︙ | |
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
|
/*
*----------------------------------------------------------------------
*
* NeedReversing --
*
* This routine determines, if bytes of a number need to be re-ordered,
* and returns a numeric code indicating the re-ordering to be done.
* This depends on the endiannes of the machine and the desired format.
* It is in effect a table (whose contents depend on the endianness of
* the system) describing whether a value needs reversing or not. Anyone
* porting the code to a big-endian platform should take care to make
* sure that they define WORDS_BIGENDIAN though this is already done by
* configure for the Unix build; little-endian platforms (including
* Windows) don't need to do anything.
*
|
|
|
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
|
/*
*----------------------------------------------------------------------
*
* NeedReversing --
*
* This routine determines, if bytes of a number need to be re-ordered,
* and returns a numeric code indicating the re-ordering to be done.
* This depends on the endianness of the machine and the desired format.
* It is in effect a table (whose contents depend on the endianness of
* the system) describing whether a value needs reversing or not. Anyone
* porting the code to a big-endian platform should take care to make
* sure that they define WORDS_BIGENDIAN though this is already done by
* configure for the Unix build; little-endian platforms (including
* Windows) don't need to do anything.
*
|
| ︙ | | | ︙ | |