21
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
|
* special conditions in the parsing of a format specifier.
*/
#define BINARY_ALL -1 /* Use all elements in the argument. */
#define BINARY_NOCOUNT -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
|
|
|
|
21
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
|
* special conditions in the parsing of a format specifier.
*/
#define BINARY_ALL -1 /* Use all elements in the argument. */
#define BINARY_NOCOUNT -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
|
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
|
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);
|
|
|
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
|
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);
|
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
|
/*
*----------------------------------------------------------------------
*
* 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.
*
|
|
|
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
|
/*
*----------------------------------------------------------------------
*
* 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.
*
|