Bstrlib

Better String library
---------------------
by Paul Hsieh
The bstring library is an attempt to provide improved string processing
functionality to the C and C++ language. At the heart of the bstring library
(Bstrlib for short) is the management of "bstring"s which are a significant
improvement over '\0' terminated char buffers.
===============================================================================
Motivation
----------
The standard C string library has serious problems:
1) Its use of '\0' to denote the end of the string means knowing a
string's length is O(n) when it could be O(1).
2) It imposes an interpretation for the character value '\0'.
3) gets() always exposes the application to a buffer overflow.
4) strtok() modifies the string its parsing and thus may not be usable in
programs which are re-entrant or multithreaded.
5) fgets has the unusual semantic of ignoring '\0's that occur before
'\n's are consumed.
6) There is no memory management, and actions performed such as strcpy,
strcat and sprintf are common places for buffer overflows.
7) strncpy() doesn't '\0' terminate the destination in some cases.
8) Passing NULL to C library string functions causes an undefined NULL
pointer access.
9) Parameter aliasing (overlapping, or self-referencing parameters)
within most C library functions has undefined behavior.
10) Many C library string function calls take integer parameters with
restricted legal ranges. Parameters passed outside these ranges are
not typically detected and cause undefined behavior.
So the desire is to create an alternative string library that does not suffer
from the above problems and adds in the following functionality:
1) Incorporate string functionality seen from other languages.
a) MID$() - from BASIC
b) split()/join() - from Python
c) string/char x n - from Perl
2) Implement analogs to functions that combine stream IO and char buffers
without creating a dependency on stream IO functionality.
3) Implement the basic text editor-style functions insert, delete, find,
and replace.
4) Implement reference based sub-string access (as a generalization of
pointer arithmetic.)
5) Implement runtime write protection for strings.
There is also a desire to avoid "API-bloat". So functionality that can be
implemented trivially in other functionality is omitted. So there is no
left$() or right$() or reverse() or anything like that as part of the core
functionality.
Explaining Bstrings
-------------------
A bstring is basically a header which wraps a pointer to a char buffer. Lets
start with the declaration of a struct tagbstring:
struct tagbstring {
int mlen;
int slen;
unsigned char * data;
};
This definition is considered exposed, not opaque (though it is neither
necessary nor recommended that low level maintenance of bstrings be performed
whenever the abstract interfaces are sufficient). The mlen field (usually)
describes a lower bound for the memory allocated for the data field. The
slen field describes the exact length for the bstring. The data field is a
single contiguous buffer of unsigned chars. Note that the existence of a '\0'
character in the unsigned char buffer pointed to by the data field does not
necessarily denote the end of the bstring.
To be a well formed modifiable bstring the mlen field must be at least the
length of the slen field, and slen must be non-negative. Furthermore, the
data field must point to a valid buffer in which access to the first mlen
characters has been acquired. So the minimal check for correctness is:
(slen >= 0 && mlen >= slen && data != NULL)
bstrings returned by bstring functions can be assumed to be either NULL or
satisfy the above property. (When bstrings are only readable, the mlen >=
slen restriction is not required; this is discussed later in this section.)
A bstring itself is just a pointer to a struct tagbstring:
typedef struct tagbstring * bstring;
Note that use of the prefix "tag" in struct tagbstring is required to work
around the inconsistency between C and C++'s struct namespace usage. This
definition is also considered exposed.
Bstrlib basically manages bstrings allocated as a header and an associated
data-buffer. Since the implementation is exposed, they can also be
constructed manually. Functions which mutate bstrings assume that the header
and data buffer have been malloced; the bstring library may perform free() or
realloc() on both the header and data buffer of any bstring parameter.
Functions which return bstring's create new bstrings. The string memory is
freed by a bdestroy() call (or using the bstrFree macro).
The following related typedef is also provided:
typedef const struct tagbstring * const_bstring;
which is also considered exposed. These are directly bstring compatible (no
casting required) but are just used for parameters which are meant to be
non-mutable. So in general, bstring parameters which are read as input but
not meant to be modified will be declared as const_bstring, and bstring
parameters which may be modified will be declared as bstring. This convention
is recommended for user written functions as well.
Since bstrings maintain interoperability with C library char-buffer style
strings, all functions which modify, update or create bstrings also append a
'\0' character into the position slen + 1. This trailing '\0' character is
not required for bstrings input to the bstring functions; this is provided
solely as a convenience for interoperability with standard C char-buffer
functionality.
Analogs for the ANSI C string library functions have been created when they
are necessary, but have also been left out when they are not. In particular
there are no functions analogous to fwrite, or puts just for the purposes of
bstring. The ->data member of any string is exposed, and therefore can be
used just as easily as char buffers for C functions which read strings.
For those that wish to hand construct bstrings, the following should be kept
in mind:
1) While bstrlib can accept constructed bstrings without terminating
'\0' characters, the rest of the C language string library will not
function properly on such non-terminated strings. This is obvious
but must be kept in mind.
2) If it is intended that a constructed bstring be written to by the
bstring library functions then the data portion should be allocated
by the malloc function and the slen and mlen fields should be entered
properly. The struct tagbstring header is not reallocated, and only
freed by bdestroy.
3) Writing arbitrary '\0' characters at various places in the string
will not modify its length as perceived by the bstring library
functions. In fact, '\0' is a legitimate non-terminating character
for a bstring to contain.
4) For read only parameters, bstring functions do not check the mlen.
I.e., the minimal correctness requirements are reduced to:
(slen >= 0 && data != NULL)
Better pointer arithmetic
-------------------------
One built-in feature of '\0' terminated char * strings, is that its very easy
and fast to obtain a reference to the tail of any string using pointer
arithmetic. Bstrlib does one better by providing a way to get a reference to
any substring of a bstring (or any other length delimited block of memory.)
So rather than just having pointer arithmetic, with bstrlib one essentially
has segment arithmetic. This is achieved using the macro blk2tbstr() which
builds a reference to a block of memory and the macro bmid2tbstr() which
builds a reference to a segment of a bstring. Bstrlib also includes
functions for direct consumption of memory blocks into bstrings, namely
bcatblk () and blk2bstr ().
One scenario where this can be extremely useful is when string contains many
substrings which one would like to pass as read-only reference parameters to
some string consuming function without the need to allocate entire new
containers for the string data. More concretely, imagine parsing a command
line string whose parameters are space delimited. This can only be done for
tails of the string with '\0' terminated char * strings.
Improved NULL semantics and error handling
------------------------------------------
Unless otherwise noted, if a NULL pointer is passed as a bstring or any other
detectably illegal parameter, the called function will return with an error
indicator (either NULL or BSTR_ERR) rather than simply performing a NULL
pointer access, or having undefined behavior.
To illustrate the value of this, consider the following example:
strcpy (p = malloc (13 * sizeof (char)), "Hello,");
strcat (p, " World");
This is not correct because malloc may return NULL (due to an out of memory
condition), and the behaviour of strcpy is undefined if either of its
parameters are NULL. However:
bstrcat (p = bfromcstr ("Hello,"), q = bfromcstr (" World"));
bdestroy (q);
is well defined, because if either p or q are assigned NULL (indicating a
failure to allocate memory) both bstrcat and bdestroy will recognize it and
perform no detrimental action.
Note that it is not necessary to check any of the members of a returned
bstring for internal correctness (in particular the data member does not need
to be checked against NULL when the header is non-NULL), since this is
assured by the bstring library itself.
bStreams
--------
In addition to the bgets and bread functions, bstrlib can abstract streams
with a high performance read only stream called a bStream. In general, the
idea is to open a core stream (with something like fopen) then pass its
handle as well as a bNread function pointer (like fread) to the bsopen
function which will return a handle to an open bStream. Then the functions
bsread, bsreadln or bsreadlns can be called to read portions of the stream.
Finally, the bsclose function is called to close the bStream -- it will
return a handle to the original (core) stream. So bStreams, essentially,
wrap other streams.
The bStreams have two main advantages over the bgets and bread (as well as
fgets/ungetc) paradigms:
1) Improved functionality via the bunread function which allows a stream to
unread characters, giving the bStream stack-like functionality if so
desired.
2) A very high performance bsreadln function. The C library function fgets()
(and the bgets function) can typically be written as a loop on top of
fgetc(), thus paying all of the overhead costs of calling fgetc on a per
character basis. bsreadln will read blocks at a time, thus amortizing the
overhead of fread calls over many characters at once.
However, clearly bStreams are suboptimal or unusable for certain kinds of
streams (stdin) or certain usage patterns (a few spotty, or non-sequential
reads from a slow stream.) For those situations, using bgets will be more
appropriate.
The semantics of bStreams allows practical construction of layerable data
streams. What this means is that by writing a bNread compatible function on
top of a bStream, one can construct a new bStream on top of it. This can be
useful for writing multi-pass parsers that don't actually read the entire
input more than once and don't require the use of intermediate storage.
Aliasing
--------
Aliasing occurs when a function is given two parameters which point to data
structures which overlap in the memory they occupy. While this does not
disturb read only functions, for many libraries this can make functions that
write to these memory locations malfunction. This is a common problem of the
C standard library and especially the string functions in the C standard
library.
The C standard string library is entirely char by char oriented (as is
bstring) which makes conforming implementations alias safe for some
scenarios. However no actual detection of aliasing is typically performed,
so it is easy to find cases where the aliasing will cause anomolous or
undesirable behaviour (consider: strcat (p, p).) The C99 standard includes
the "restrict" pointer modifier which allows the compiler to document and
assume a no-alias condition on usage. However, only the most trivial cases
can be caught (if at all) by the compiler at compile time, and thus there is
no actual enforcement of non-aliasing.
Bstrlib, by contrast, permits aliasing and is completely aliasing safe, in
the C99 sense of aliasing. That is to say, under the assumption that
pointers of incompatible types from distinct objects can never alias, bstrlib
is completely aliasing safe. (In practice this means that the data buffer
portion of any bstring and header of any bstring are assumed to never alias.)
With the exception of the reference building macros, the library behaves as
if all read-only parameters are first copied and replaced by temporary
non-aliased parameters before any writing to any output bstring is performed
(though actual copying is extremely rarely ever done.)
Besides being a useful safety feature, bstring searching/comparison
functions can improve to O(1) execution when aliasing is detected.
Note that aliasing detection and handling code in Bstrlib is generally
extremely cheap. There is almost never any appreciable performance penalty
for using aliased parameters.
Reenterancy
-----------
Nearly every function in Bstrlib is a leaf function, and is completely
reenterable with the exception of writing to common bstrings. The split
functions which use a callback mechanism requires only that the source string
not be destroyed by the callback function unless the callback function returns
with an error status (note that Bstrlib functions which return an error do
not modify the string in any way.) The string can in fact be modified by the
callback and the behaviour is deterministic. See the documentation of the
various split functions for more details.
Undefined scenarios
-------------------
One of the basic important premises for Bstrlib is to not to increase the
propogation of undefined situations from parameters that are otherwise legal
in of themselves. In particular, except for extremely marginal cases, usages
of bstrings that use the bstring library functions alone cannot lead to any
undefined action. But due to C/C++ language and library limitations, there
is no way to define a non-trivial library that is completely without
undefined operations. All such possible undefined operations are described
below:
1) bstrings or struct tagbstrings that are not explicitely initialized cannot
be passed as a parameter to any bstring function.
2) The members of the NULL bstring cannot be accessed directly. (Though all
APIs and macros detect the NULL bstring.)
3) A bstring whose data member has not been obtained from a malloc or
compatible call and which is write accessible passed as a writable
parameter will lead to undefined results. (i.e., do not writeAllow any
constructed bstrings unless the data portion has been obtained from the
heap.)
4) If the headers of two strings alias but are not identical (which can only
happen via a defective manual construction), then passing them to a
bstring function in which one is writable is not defined.
5) If the mlen member is larger than the actual accessible length of the data
member for a writable bstring, or if the slen member is larger than the
readable length of the data member for a readable bstring, then the
corresponding bstring operations are undefined.
6) Any bstring definition whose header or accessible data portion has been
assigned to inaccessible or otherwise illegal memory clearly cannot be
acted upon by the bstring library in any way.
7) Destroying the source of an incremental split from within the callback
and not returning with a negative value (indicating that it should abort)
will lead to undefined behaviour. (Though *modifying* or adjusting the
state of the source data, even if those modification fail within the
bstrlib API, has well defined behavior.)
8) Modifying a bstring which is write protected by direct access has
undefined behavior.
While this may seem like a long list, with the exception of invalid uses of
the writeAllow macro, and source destruction during an iterative split
without an accompanying abort, no usage of the bstring API alone can cause
any undefined scenario to occurr. I.e., the policy of restricting usage of
bstrings to the bstring API can significantly reduce the risk of runtime
errors (in practice it should eliminate them) related to string manipulation
due to undefined action.
C++ wrapper
-----------
A C++ wrapper has been created to enable bstring functionality for C++ in the
most natural (for C++ programers) way possible. The mandate for the C++
wrapper is different from the base C bstring library. Since the C++ language
has far more abstracting capabilities, the CBString structure is considered
fully abstracted -- i.e., hand generated CBStrings are not supported (though
conversion from a struct tagbstring is allowed) and all detectable errors are
manifest as thrown exceptions.
- The C++ class definitions are all under the namespace Bstrlib. bstrwrap.h
enables this namespace (with a using namespace Bstrlib; directive at the
end) unless the macro BSTRLIB_DONT_ASSUME_NAMESPACE has been defined before
it is included.
- Erroneous accesses results in an exception being thrown. The exception
parameter is of type "struct CBStringException" which is derived from
std::exception if STL is used. A verbose description of the error message
can be obtained from the what() method.
- CBString is a C++ structure derived from a struct tagbstring. An address
of a CBString cast to a bstring must not be passed to bdestroy. The bstring
C API has been made C++ safe and can be used directly in a C++ project.
- It includes constructors which can take a char, '\0' terminated char
buffer, tagbstring, (char, repeat-value), a length delimited buffer or a
CBStringList to initialize it.
- Concatenation is performed with the + and += operators. Comparisons are
done with the ==, !=, <, >, <= and >= operators. Note that == and != use
the biseq call, while <, >, <= and >= use bstrcmp.
- CBString's can be directly cast to const character buffers.
- CBString's can be directly cast to double, float, int or unsigned int so
long as the CBString are decimal representations of those types (otherwise
an exception will be thrown). Converting the other way should be done with
the format(a) method(s).
- CBString contains the length, character and [] accessor methods. The
character and [] accessors are aliases of each other. If the bounds for
the string are exceeded, an exception is thrown. To avoid the overhead for
this check, first cast the CBString to a (const char *) and use [] to
dereference the array as normal. Note that the character and [] accessor
methods allows both reading and writing of individual characters.
- The methods: format, formata, find, reversefind, findcaseless,
reversefindcaseless, midstr, insert, insertchrs, replace, findreplace,
findreplacecaseless, remove, findchr, nfindchr, alloc, toupper, tolower,
gets, read are analogous to the functions that can be found in the C API.
- The caselessEqual and caselessCmp methods are analogous to biseqcaseless
and bstricmp functions respectively.
- Note that just like the bformat function, the format and formata methods do
not automatically cast CBStrings into char * strings for "%s"-type
substitutions:
CBString w("world");
CBString h("Hello");
CBString hw;
/* The casts are necessary */
hw.format ("%s, %s", (const char *)h, (const char *)w);
- The methods trunc and repeat have been added instead of using pattern.
- ltrim, rtrim and trim methods have been added. These remove characters
from a given character string set (defaulting to the whitespace characters)
from either the left, right or both ends of the CBString, respectively.
- The method setsubstr is also analogous in functionality to bsetstr, except
that it cannot be passed NULL. Instead the method fill and the fill-style
constructor have been supplied to enable this functionality.
- The writeprotect(), writeallow() and iswriteprotected() methods are
analogous to the bwriteprotect(), bwriteallow() and biswriteprotected()
macros in the C API. Write protection semantics in CBString are stronger
than with the C API in that indexed character assignment is checked for
write protection. However, unlike with the C API, a write protected
CBString can be destroyed by the destructor.
- CBStream is a C++ structure which wraps a struct bStream (its not derived
from it, since destruction is slightly different). It is constructed by
passing in a bNread function pointer and a stream parameter cast to void *.
This structure includes methods for detecting eof, setting the buffer
length, reading the whole stream or reading entries line by line or block
by block, an unread function, and a peek function.
- If STL is available, the CBStringList structure is derived from a vector of
CBString with various split methods. The split method has been overloaded
to accept either a character or CBString as the second parameter (when the
split parameter is a CBString any character in that CBString is used as a
seperator). The splitstr method takes a CBString as a substring seperator.
Joins can be performed via a CBString constructor which takes a
CBStringList as a parameter, or just using the CBString::join() method.
- If there is proper support for std::iostreams, then the >> and << operators
and the getline() function have been added (with semantics the same as
those for std::string).
Multithreading
--------------
A mutable bstring is kind of analogous to a small (two entry) linked list
allocated by malloc, with all aliasing completely under programmer control.
I.e., manipulation of one bstring will never affect any other distinct
bstring unless explicitely constructed to do so by the programmer via hand
construction or via building a reference. Bstrlib also does not use any
static or global storage, so there are no hidden unremovable race conditions.
Bstrings are also clearly not inherently thread local. So just like
char *'s, bstrings can be passed around from thread to thread and shared and
so on, so long as modifications to a bstring correspond to some kind of
exclusive access lock as should be expected (or if the bstring is read-only,
which can be enforced by bstring write protection) for any sort of shared
object in a multithreaded environment.
Bsafe module
------------
For convenience, a bsafe module has been included. The idea is that if this
module is included, inadvertant usage of the most dangerous C functions will
be overridden and lead to an immediate run time abort. Of course, it should
be emphasized that usage of this module is completely optional. The
intention is essentially to provide an option for creating project safety
rules which can be enforced mechanically rather than socially. This is
useful for larger, or open development projects where its more difficult to
enforce social rules or "coding conventions".
Problems not solved
-------------------
Bstrlib is written for the C and C++ languages, which have inherent weaknesses
that cannot be easily solved:
1. Memory leaks: Forgetting to call bdestroy on a bstring that is about to be
unreferenced, just as forgetting to call free on a heap buffer that is
about to be dereferenced. Though bstrlib itself is leak free.
2. Read before write usage: In C, declaring an auto bstring does not
automatically fill it with legal/valid contents. This problem has been
somewhat mitigated in C++. (The bstrDeclare and bstrFree macros from
bstraux can be used to help mitigate this problem.)
Other problems not addressed:
3. Built-in mutex usage to automatically avoid all bstring internal race
conditions in multitasking environments: The problem with trying to
implement such things at this low a level is that it is typically more
efficient to use locks in higher level primitives. There is also no
platform independent way to implement locks or mutexes.
4. Unicode/widecharacter support.
Note that except for spotty support of wide characters, the default C
standard library does not address any of these problems either.
Configurable compilation options
--------------------------------
All configuration options are meant solely for the purpose of compiler
compatibility. Configuration options are not meant to change the semantics
or capabilities of the library, except where it is unavoidable.
Since some C++ compilers don't include the Standard Template Library and some
have the options of disabling exception handling, a number of macros can be
used to conditionally compile support for each of this:
BSTRLIB_CAN_USE_STL
- defining this will enable the used of the Standard Template Library.
Defining BSTRLIB_CAN_USE_STL overrides the BSTRLIB_CANNOT_USE_STL macro.
BSTRLIB_CANNOT_USE_STL
- defining this will disable the use of the Standard Template Library.
Defining BSTRLIB_CAN_USE_STL overrides the BSTRLIB_CANNOT_USE_STL macro.
BSTRLIB_CAN_USE_IOSTREAM
- defining this will enable the used of streams from class std. Defining
BSTRLIB_CAN_USE_IOSTREAM overrides the BSTRLIB_CANNOT_USE_IOSTREAM macro.
BSTRLIB_CANNOT_USE_IOSTREAM
- defining this will disable the use of streams from class std. Defining
BSTRLIB_CAN_USE_IOSTREAM overrides the BSTRLIB_CANNOT_USE_IOSTREAM macro.
BSTRLIB_THROWS_EXCEPTIONS
- defining this will enable the exception handling within bstring.
Defining BSTRLIB_THROWS_EXCEPTIONS overrides the
BSTRLIB_DOESNT_THROWS_EXCEPTIONS macro.
BSTRLIB_DOESNT_THROW_EXCEPTIONS
- defining this will disable the exception handling within bstring.
Defining BSTRLIB_THROWS_EXCEPTIONS overrides the
BSTRLIB_DOESNT_THROW_EXCEPTIONS macro.
Note that these macros must be defined consistently throughout all modules
that use CBStrings including bstrwrap.cpp.
Some older C compilers do not support functions such as vsnprintf. This is
handled by the following macro variables:
BSTRLIB_NOVSNP
- defining this indicates that the compiler does not support vsnprintf.
This will cause bformat and bformata to not be declared. Note that
for some compilers, such as Turbo C, this is set automatically.
Defining BSTRLIB_NOVSNP overrides the BSTRLIB_VSNP_OK macro.
BSTRLIB_VSNP_OK
- defining this will disable the autodetection of compilers the do not
support of compilers that do not support vsnprintf.
Defining BSTRLIB_NOVSNP overrides the BSTRLIB_VSNP_OK macro.
Semantic compilation options
----------------------------
Bstrlib comes with very few compilation options for changing the semantics of
of the library. These are described below.
BSTRLIB_DONT_ASSUME_NAMESPACE
- Defining this before including bstrwrap.h will disable the automatic
enabling of the Bstrlib namespace for the C++ declarations.
BSTRLIB_DONT_USE_VIRTUAL_DESTRUCTOR
- Defining this will make the CBString destructor non-virtual.
BSTRLIB_MEMORY_DEBUG
- Defining this will cause the bstrlib modules bstrlib.c and bstrwrap.cpp
to invoke a #include "memdbg.h". memdbg.h has to be supplied by the user.
Note that these macros must be defined consistently throughout all modules
that use bstrings or CBStrings including bstrlib.c, bstraux.c and
bstrwrap.cpp.
===============================================================================
Files
-----
bstrlib.c - C implementaion of bstring functions.
bstrlib.h - C header file for bstring functions.
bstraux.c - C example that implements trivial additional functions.
bstraux.h - C header for bstraux.c
bstest.c - C unit/regression test for bstrlib.c
bstrwrap.cpp - C++ implementation of CBString.
bstrwrap.h - C++ header file for CBString.
test.cpp - C++ unit/regression test for bstrwrap.cpp
bsafe.c - C runtime stubs to abort usage of unsafe C functions.
bsafe.h - C header file for bsafe.c functions.
C projects need only include bstrlib.h and compile/link bstrlib.c to use the
bstring library. C++ projects need to additionally include bstrwrap.h and
compile/link bstrwrap.cpp. For both, there may be a need to make choices
about feature configuration as described in the "Configurable compilation
options" in the section above.
Other files that are included in this archive are:
license.txt - The 3 clause BSD license for Bstrlib
gpl.txt - The GPL version 2
security.txt - A security statement useful for auditting Bstrlib
porting.txt - A guide to porting Bstrlib
bstrlib.txt - This file
===============================================================================
The functions
-------------
extern bstring bfromcstr (const char * str);
Take a standard C library style '\0' terminated char buffer and generate
a bstring with the same contents as the char buffer. If an error occurs
NULL is returned.
So for example:
bstring b = bfromcstr ("Hello");
if (!b) {
fprintf (stderr, "Out of memory");
} else {
puts ((char *) b->data);
}
..........................................................................
extern bstring bfromcstralloc (int mlen, const char * str);
Create a bstring which contains the contents of the '\0' terminated
char * buffer str. The memory buffer backing the bstring is at least
mlen characters in length. If an error occurs NULL is returned.
So for example:
bstring b = bfromcstralloc (64, someCstr);
if (b) b->data[63] = 'x';
The idea is that this will set the 64th character of b to 'x' if it is at
least 64 characters long otherwise do nothing. And we know this is well
defined so long as b was successfully created, since it will have been
allocated with at least 64 characters.
..........................................................................
extern bstring blk2bstr (const void * blk, int len);
Create a bstring whose contents are described by the contiguous buffer
pointing to by blk with a length of len bytes. Note that this function
creates a copy of the data in blk, rather than simply referencing it.
Compare with the blk2tbstr macro. If an error occurs NULL is returned.
..........................................................................
extern char * bstr2cstr (const_bstring s, char z);
Create a '\0' terminated char buffer which contains the contents of the
bstring s, except that any contained '\0' characters are converted to the
character in z. This returned value should be freed with bcstrfree(), by
the caller. If an error occurs NULL is returned.
..........................................................................
extern int bcstrfree (char * s);
Frees a C-string generated by bstr2cstr (). This is normally unnecessary
since it just wraps a call to free (), however, if malloc () and free ()
have been redefined as a macros within the bstrlib module (via macros in
the memdbg.h backdoor) with some difference in behaviour from the std
library functions, then this allows a correct way of freeing the memory
that allows higher level code to be independent from these macro
redefinitions.
..........................................................................
extern bstring bstrcpy (const_bstring b1);
Make a copy of the passed in bstring. The copied bstring is returned if
there is no error, otherwise NULL is returned.
..........................................................................
extern int bassign (bstring a, const_bstring b);
Overwrite the bstring a with the contents of bstring b. Note that the
bstring a must be a well defined and writable bstring. If an error
occurs BSTR_ERR is returned and a is not overwritten.
..........................................................................
int bassigncstr (bstring a, const char * str);
Overwrite the string a with the contents of char * string str. Note that
the bstring a must be a well defined and writable bstring. If an error
occurs BSTR_ERR is returned and a may be partially overwritten.
..........................................................................
int bassignblk (bstring a, const void * s, int len);
Overwrite the string a with the contents of the block (s, len). Note that
..........................................................................
extern int bassignmidstr (bstring a, const_bstring b, int left, int len);
Overwrite the bstring a with the middle of contents of bstring b
starting from position left and running for a length len. left and
len are clamped to the ends of b as with the function bmidstr. Note that
..........................................................................
extern bstring bmidstr (const_bstring b, int left, int len);
Create a bstring which is the substring of b starting from position left
and running for a length len (clamped by the end of the bstring b.) If
there was no error, the value of this constructed bstring is returned
otherwise NULL is returned.
..........................................................................
extern int bdelete (bstring s1, int pos, int len);
Removes characters from pos to pos+len-1 and shifts the tail of the
bstring starting from pos+len to pos. len must be positive for this call
to have any effect. The section of the bstring described by (pos, len)
is clamped to boundaries of the bstring b. The value BSTR_OK is returned
if the operation is successful, otherwise BSTR_ERR is returned.
..........................................................................
extern int bconcat (bstring b0, const_bstring b1);
Concatenate the bstring b1 to the end of bstring b0. The value BSTR_OK
is returned if the operation is successful, otherwise BSTR_ERR is
returned.
..........................................................................
extern int bconchar (bstring b, char c);
Concatenate the character c to the end of bstring b. The value BSTR_OK
is returned if the operation is successful, otherwise BSTR_ERR is
returned.
..........................................................................
extern int bcatcstr (bstring b, const char * s);
Concatenate the char * string s to the end of bstring b. The value
BSTR_OK is returned if the operation is successful, otherwise BSTR_ERR is
returned.
..........................................................................
extern int bcatblk (bstring b, const void * s, int len);
Concatenate a fixed length buffer (s, len) to the end of bstring b. The
value BSTR_OK is returned if the operation is successful, otherwise
BSTR_ERR is returned.
..........................................................................
extern int biseq (const_bstring b0, const_bstring b1);
Compare the bstring b0 and b1 for equality. If the bstrings differ, 0
is returned, if the bstrings are the same, 1 is returned, if there is an
error, -1 is returned. If the length of the bstrings are different, this
function has O(1) complexity. Contained '\0' characters are not treated
as a termination character.
Note that the semantics of biseq are not completely compatible with
bstrcmp because of its different treatment of the '\0' character.
..........................................................................
extern int bisstemeqblk (const_bstring b, const void * blk, int len);
Compare beginning of bstring b0 with a block of memory of length len for
equality. If the beginning of b0 differs from the memory block (or if b0
is too short), 0 is returned, if the bstrings are the same, 1 is returned,
if there is an error, -1 is returned.
..........................................................................
extern int biseqcaseless (const_bstring b0, const_bstring b1);
Compare two bstrings for equality without differentiating between case.
If the bstrings differ other than in case, 0 is returned, if the bstrings
are the same, 1 is returned, if there is an error, -1 is returned. If
the length of the bstrings are different, this function is O(1). '\0'
termination characters are not treated in any special way.
..........................................................................
extern int bisstemeqcaselessblk (const_bstring b0, const void * blk, int len
);
Compare beginning of bstring b0 with a block of memory of length len
without differentiating between case for equality. If the beginning of b0
differs from the memory block other than in case (or if b0 is too short),
0 is returned, if the bstrings are the same, 1 is returned, if there is an
error, -1 is returned.
..........................................................................
extern int biseqcstr (const_bstring b, const char *s);
Compare the bstring b and char * bstring s. The C string s must be '\0'
terminated at exactly the length of the bstring b, and the contents
between the two must be identical with the bstring b with no '\0'
characters for the two contents to be considered equal. This is
equivalent to the condition that their current contents will be always be
equal when comparing them in the same format after converting one or the
other. If they are equal 1 is returned, if they are unequal 0 is
returned and if there is a detectable error BSTR_ERR is returned.
..........................................................................
extern int biseqcstrcaseless (const_bstring b, const char *s);
Compare the bstring b and char * string s. The C string s must be '\0'
terminated at exactly the length of the bstring b, and the contents
between the two must be identical except for case with the bstring b with
no '\0' characters for the two contents to be considered equal. This is
equivalent to the condition that their current contents will be always be
equal ignoring case when comparing them in the same format after
converting one or the other. If they are equal, except for case, 1 is
returned, if they are unequal regardless of case 0 is returned and if
there is a detectable error BSTR_ERR is returned.
..........................................................................
extern int bstrcmp (const_bstring b0, const_bstring b1);
Compare the bstrings b0 and b1 for ordering. If there is an error,
SHRT_MIN is returned, otherwise a value less than or greater than zero,
indicating that the bstring pointed to by b0 is lexicographically less
than or greater than the bstring pointed to by b1 is returned. If the
bstring lengths are unequal but the characters up until the length of the
shorter are equal then a value less than, or greater than zero,
indicating that the bstring pointed to by b0 is shorter or longer than the
bstring pointed to by b1 is returned. 0 is returned if and only if the
two bstrings are the same. If the length of the bstrings are different,
this function is O(n). Like its standard C library counter part, the
comparison does not proceed past any '\0' termination characters
encountered.
The seemingly odd error return value, merely provides slightly more
granularity than the undefined situation given in the C library function
strcmp. The function otherwise behaves very much like strcmp().
Note that the semantics of bstrcmp are not completely compatible with
biseq because of its different treatment of the '\0' termination
character.
..........................................................................
extern int bstrncmp (const_bstring b0, const_bstring b1, int n);
Compare the bstrings b0 and b1 for ordering for at most n characters. If
there is an error, SHRT_MIN is returned, otherwise a value is returned as
if b0 and b1 were first truncated to at most n characters then bstrcmp
was called with these new bstrings are paremeters. If the length of the
bstrings are different, this function is O(n). Like its standard C
library counter part, the comparison does not proceed past any '\0'
termination characters encountered.
The seemingly odd error return value, merely provides slightly more
granularity than the undefined situation given in the C library function
strncmp. The function otherwise behaves very much like strncmp().
..........................................................................
extern int bstricmp (const_bstring b0, const_bstring b1);
Compare two bstrings without differentiating between case. The return
value is the difference of the values of the characters where the two
bstrings first differ, otherwise 0 is returned indicating that the
bstrings are equal. If the lengths are different, then a difference from
0 is given, but if the first extra character is '\0', then it is taken to
be the value UCHAR_MAX+1.
..........................................................................
extern int bstrnicmp (const_bstring b0, const_bstring b1, int n);
Compare two bstrings without differentiating between case for at most n
characters. If the position where the two bstrings first differ is
before the nth position, the return value is the difference of the values
of the characters, otherwise 0 is returned. If the lengths are different
and less than n characters, then a difference from 0 is given, but if the
first extra character is '\0', then it is taken to be the value
UCHAR_MAX+1.
..........................................................................
extern int bdestroy (bstring b);
Deallocate the bstring passed. Passing NULL in as a parameter will have
no effect. Note that both the header and the data portion of the bstring
will be freed. No other bstring function which modifies one of its
parameters will free or reallocate the header. Because of this, in
general, bdestroy cannot be called on any declared struct tagbstring even
if it is not write protected. A bstring which is write protected cannot
be destroyed via the bdestroy call. Any attempt to do so will result in
no action taken, and BSTR_ERR will be returned.
Note to C++ users: Passing in a CBString cast to a bstring will lead to
undefined behavior (free will be called on the header, rather than the
CBString destructor.) Instead just use the ordinary C++ language
facilities to dealloc a CBString.
..........................................................................
extern int binstr (const_bstring s1, int pos, const_bstring s2);
Search for the bstring s2 in s1 starting at position pos and looking in a
forward (increasing) direction. If it is found then it returns with the
first position after pos where it is found, otherwise it returns BSTR_ERR.
The algorithm used is brute force; O(m*n).
..........................................................................
extern int binstrr (const_bstring s1, int pos, const_bstring s2);
backward (decreasing) direction. If it is found then it returns with the
first position after pos where it is found, otherwise return BSTR_ERR.
Note that the current position at pos is tested as well -- so to be
disjoint from a previous forward search it is recommended that the
position be backed up (decremented) by one position. The algorithm used
is brute force; O(m*n).
..........................................................................
extern int binstrcaseless (const_bstring s1, int pos, const_bstring s2);
forward (increasing) direction but without regard to case. If it is
found then it returns with the first position after pos where it is
found, otherwise it returns BSTR_ERR. The algorithm used is brute force;
O(m*n).
..........................................................................
extern int binstrrcaseless (const_bstring s1, int pos, const_bstring s2);
backward (decreasing) direction but without regard to case. If it is
found then it returns with the first position after pos where it is
found, otherwise return BSTR_ERR. Note that the current position at pos
is tested as well -- so to be disjoint from a previous forward search it
is recommended that the position be backed up (decremented) by one
position. The algorithm used is brute force; O(m*n).
..........................................................................
extern int binchr (const_bstring b0, int pos, const_bstring b1);
Search for the first position in b0 starting from pos or after, in which
one of the characters in b1 is found. This function has an execution
time of O(b0->slen + b1->slen). If such a position does not exist in b0,
then BSTR_ERR is returned.
..........................................................................
extern int binchrr (const_bstring b0, int pos, const_bstring b1);
Search for the last position in b0 no greater than pos, in which one of
the characters in b1 is found. This function has an execution time
of O(b0->slen + b1->slen). If such a position does not exist in b0,
then BSTR_ERR is returned.
..........................................................................
extern int bninchr (const_bstring b0, int pos, const_bstring b1);
Search for the first position in b0 starting from pos or after, in which
none of the characters in b1 is found and return it. This function has
an execution time of O(b0->slen + b1->slen). If such a position does
not exist in b0, then BSTR_ERR is returned.
..........................................................................
extern int bninchrr (const_bstring b0, int pos, const_bstring b1);

Search for the last position in b0 no greater than pos, in which none of
the characters in b1 is found and return it. This function has an
execution time of O(b0->slen + b1->slen). If such a position does not
exist in b0, then BSTR_ERR is returned.
..........................................................................
extern int bstrchr (const_bstring b, int c);
Search for the character c in the bstring b forwards from the start of
the bstring. Returns the position of the found character or BSTR_ERR if
it is not found.
NOTE: This has been implemented as a macro on top of bstrchrp ().
..........................................................................
extern int bstrrchr (const_bstring b, int c);
Search for the character c in the bstring b backwards from the end of the
bstring. Returns the position of the found character or BSTR_ERR if it is
not found.
NOTE: This has been implemented as a macro on top of bstrrchrp ().
..........................................................................
extern int bstrchrp (const_bstring b, int c, int pos);

Search for the character c in b forwards from the position pos
(inclusive). Returns the position of the found character or BSTR_ERR if
it is not found.
..........................................................................
extern int bstrrchrp (const_bstring b, int c, int pos);
Search for the character c in b backwards from the position pos in bstring
(inclusive). Returns the position of the found character or BSTR_ERR if
it is not found.
..........................................................................
extern int bsetstr (bstring b0, int pos, const_bstring b1, unsigned char fil
l);
Overwrite the bstring b0 starting at position pos with the bstring b1. If
the position pos is past the end of b0, then the character "fill" is
appended as necessary to make up the gap between the end of b0 and pos.
If b1 is NULL, it behaves as if it were a 0-length bstring. The value
BSTR_OK is returned if the operation is successful, otherwise BSTR_ERR is
returned.
..........................................................................
extern int binsert (bstring s1, int pos, const_bstring s2, unsigned char fil
l);
Inserts the bstring s2 into s1 at position pos. If the position pos is
past the end of s1, then the character "fill" is appended as necessary to
make up the gap between the end of s1 and pos. The value BSTR_OK is
returned if the operation is successful, otherwise BSTR_ERR is returned.
..........................................................................
extern int binsertch (bstring s1, int pos, int len, unsigned char fill);
Inserts the character fill repeatedly into s1 at position pos for a
length len. If the position pos is past the end of s1, then the
character "fill" is appended as necessary to make up the gap between the
end of s1 and the position pos + len (exclusive). The value BSTR_OK is
returned if the operation is successful, otherwise BSTR_ERR is returned.
..........................................................................
extern int breplace (bstring b1, int pos, int len, const_bstring b2,
unsigned char fill);
Replace a section of a bstring from pos for a length len with the bstring
b2. If the position pos is past the end of b1 then the character "fill"
is appended as necessary to make up the gap between the end of b1 and
pos.
..........................................................................
extern int bfindreplace (bstring b, const_bstring find,
const_bstring replace, int position);
Replace all occurrences of the find substring with a replace bstring
after a given position in the bstring b. The find bstring must have a
length > 0 otherwise BSTR_ERR is returned. This function does not
perform recursive per character replacement; that is to say successive
searches resume at the position after the last replace.
So for example:
bfindreplace (a0 = bfromcstr("aabaAb"), a1 = bfromcstr("a"),
a2 = bfromcstr("aa"), 0);
Should result in changing a0 to "aaaabaaAb".
This function performs exactly (b->slen - position) bstring comparisons,
and data movement is bounded above by character volume equivalent to size
of the output bstring.
..........................................................................
extern int bfindreplacecaseless (bstring b, const_bstring find,
const_bstring replace, int position);
Replace all occurrences of the find substring, ignoring case, with a
replace bstring after a given position in the bstring b. The find bstring
must have a length > 0 otherwise BSTR_ERR is returned. This function
does not perform recursive per character replacement; that is to say
successive searches resume at the position after the last replace.
So for example:
bfindreplacecaseless (a0 = bfromcstr("AAbaAb"), a1 = bfromcstr("a"),
a2 = bfromcstr("aa"), 0);
Should result in changing a0 to "aaaabaaaab".
This function performs exactly (b->slen - position) bstring comparisons,
and data movement is bounded above by character volume equivalent to size
of the output bstring.
..........................................................................
extern int balloc (bstring b, int length);
Increase the allocated memory backing the data buffer for the bstring b
to a length of at least length. If the memory backing the bstring b is
already large enough, not action is performed. This has no effect on the
bstring b that is visible to the bstring API. Usually this function will
only be used when a minimum buffer size is required coupled with a direct
access to the ->data member of the bstring structure.
Be warned that like any other bstring function, the bstring must be well
defined upon entry to this function. I.e., doing something like:
b->slen *= 2; /* ?? Most likely incorrect */
balloc (b, b->slen);
is invalid, and should be implemented as:
int t;
if (BSTR_OK == balloc (b, t = (b->slen * 2))) b->slen = t;
This function will return with BSTR_ERR if b is not detected as a valid
bstring or length is not greater than 0, otherwise BSTR_OK is returned.
..........................................................................
extern int ballocmin (bstring b, int length);
Change the amount of memory backing the bstring b to at least length.
This operation will never truncate the bstring data including the
extra terminating '\0' and thus will not decrease the length to less than
b->slen + 1. Note that repeated use of this function may cause
performance problems (realloc may be called on the bstring more than
the O(log(INT_MAX)) times). This function will return with BSTR_ERR if b
is not detected as a valid bstring or length is not greater than 0,
otherwise BSTR_OK is returned.
So for example:
if (BSTR_OK == ballocmin (b, 64)) b->data[63] = 'x';
The idea is that this will set the 64th character of b to 'x' if it is at
least 64 characters long otherwise do nothing. And we know this is well
defined so long as the ballocmin call was successfully, since it will
ensure that b has been allocated with at least 64 characters.
..........................................................................
int btrunc (bstring b, int n);
Truncate the bstring to at most n characters. This function will return
with BSTR_ERR if b is not detected as a valid bstring or n is less than
0, otherwise BSTR_OK is returned.
..........................................................................
extern int bpattern (bstring b, int len);
Replicate the starting bstring, b, end to end repeatedly until it
surpasses len characters, then chop the result to exactly len characters.
This function operates in-place. This function will return with BSTR_ERR
if b is NULL or of length 0, otherwise BSTR_OK is returned.
..........................................................................
extern int btoupper (bstring b);
Convert contents of bstring to upper case. This function will return with
BSTR_ERR if b is NULL or of length 0, otherwise BSTR_OK is returned.
..........................................................................
extern int btolower (bstring b);
Convert contents of bstring to lower case. This function will return with
BSTR_ERR if b is NULL or of length 0, otherwise BSTR_OK is returned.
..........................................................................
extern int bltrimws (bstring b);
Delete whitespace contiguous from the left end of the bstring. This
function will return with BSTR_ERR if b is NULL or of length 0, otherwise
BSTR_OK is returned.
..........................................................................
extern int brtrimws (bstring b);
Delete whitespace contiguous from the right end of the bstring. This
function will return with BSTR_ERR if b is NULL or of length 0, otherwise
BSTR_OK is returned.
..........................................................................
extern int btrimws (bstring b);
Delete whitespace contiguous from both ends of the bstring. This function
will return with BSTR_ERR if b is NULL or of length 0, otherwise BSTR_OK
is returned.
..........................................................................
extern int bstrListCreate (void);
Create an empty struct bstrList. The struct bstrList output structure is
declared as follows:
struct bstrList {
int qty, mlen;
bstring * entry;
};
The entry field actually is an array with qty number entries. The mlen
record counts the maximum number of bstring's for which there is memory
in the entry record.
The Bstrlib API does *NOT* include a comprehensive set of functions for
full management of struct bstrList in an abstracted way. The reason for
this is because aliasing semantics of the list are best left to the user
of this function, and performance varies wildly depending on the
assumptions made. For a complete list of bstring data type it is
recommended that the C++ public std::vector<CBString> be used, since its
semantics are usage are more standard.
..........................................................................
extern int bstrListDestroy (struct bstrList * sl);
Destroy a struct bstrList structure that was returned by the bsplit
function. Note that this will destroy each bstring in the ->entry array
as well. See bstrListCreate() above for structure of struct bstrList.
..........................................................................
extern int bstrListAlloc (struct bstrList * sl, int msz);
Ensure that there is memory for at least msz number of entries for the
list.
..........................................................................
extern int bstrListAllocMin (struct bstrList * sl, int msz);
Try to allocate the minimum amount of memory for the list to include at
least msz entries or sl->qty whichever is greater.
..........................................................................
extern struct bstrList * bsplit (bstring str, unsigned char splitChar);
Create an array of sequential substrings from str divided by the
character splitChar. Successive occurrences of the splitChar will be
divided by empty bstring entries, following the semantics from the Python
programming language. To reclaim the memory from this output structure,
bstrListDestroy () should be called. See bstrListCreate() above for
structure of struct bstrList.
..........................................................................
extern struct bstrList * bsplits (bstring str, const_bstring splitStr);
Create an array of sequential substrings from str divided by any
character contained in splitStr. An empty splitStr causes a single entry
bstrList containing a copy of str to be returned. See bstrListCreate()
above for structure of struct bstrList.
..........................................................................
extern struct bstrList * bsplitstr (bstring str, const_bstring splitStr);
Create an array of sequential substrings from str divided by the entire
substring splitStr. An empty splitStr causes a single entry bstrList
containing a copy of str to be returned. See bstrListCreate() above for
structure of struct bstrList.
..........................................................................
extern bstring bjoin (const struct bstrList * bl, const_bstring sep);
Join the entries of a bstrList into one bstring by sequentially
concatenating them with the sep bstring in between. If sep is NULL, it
is treated as if it were the empty bstring. Note that:
bjoin (l = bsplit (b, s->data[0]), s);
should result in a copy of b, if s->slen is 1. If there is an error NULL
is returned, otherwise a bstring with the correct result is returned.
See bstrListCreate() above for structure of struct bstrList.
..........................................................................
extern int bsplitcb (const_bstring str, unsigned char splitChar, int pos,
int (* cb) (void * parm, int ofs, int len), void * parm);
Iterate the set of disjoint sequential substrings over str starting at
position pos divided by the character splitChar. The parm passed to
bsplitcb is passed on to cb. If the function cb returns a value < 0,
then further iterating is halted and this value is returned by bsplitcb.
Note: Non-destructive modification of str from within the cb function
while performing this split is not undefined. bsplitcb behaves in
sequential lock step with calls to cb. I.e., after returning from a cb
that return a non-negative integer, bsplitcb continues from the position
1 character after the last detected split character and it will halt
immediately if the length of str falls below this point. However, if the
cb function destroys str, then it *must* return with a negative value,
otherwise bsplitcb will continue in an undefined manner.
This function is provided as an incremental alternative to bsplit that is
abortable and which does not impose additional memory allocation.
..........................................................................
extern int bsplitscb (const_bstring str, const_bstring splitStr, int pos,
position pos divided by any of the characters in splitStr. An empty
splitStr causes the whole str to be iterated once. The parm passed to
bsplitcb is passed on to cb. If the function cb returns a value < 0,
then further iterating is halted and this value is returned by bsplitcb.
while performing this split is not undefined. bsplitscb behaves in
that return a non-negative integer, bsplitscb continues from the position
otherwise bsplitscb will continue in an undefined manner.
This function is provided as an incremental alternative to bsplits that
is abortable and which does not impose additional memory allocation.
..........................................................................
extern int bsplitstrcb (const_bstring str, const_bstring splitStr, int pos,
position pos divided by the entire substring splitStr. An empty splitStr
causes each character of str to be iterated. The parm passed to bsplitcb
is passed on to cb. If the function cb returns a value < 0, then further
iterating is halted and this value is returned by bsplitcb.
while performing this split is not undefined. bsplitstrcb behaves in
that return a non-negative integer, bsplitstrcb continues from the position
otherwise bsplitscb will continue in an undefined manner.
This function is provided as an incremental alternative to bsplitstr that
is abortable and which does not impose additional memory allocation.
..........................................................................
extern bstring bformat (const char * fmt, ...);
Takes the same parameters as printf (), but rather than outputting
results to stdio, it forms a bstring which contains what would have been
output. Note that if there is an early generation of a '\0' character,
the bstring will be truncated to this end point.
Note that %s format tokens correspond to '\0' terminated char * buffers,
not bstrings. To print a bstring, first dereference data element of the
the bstring:
/* b1->data needs to be '\0' terminated, so tagbstrings generated
by blk2tbstr () might not be suitable. */
b0 = bformat ("Hello, %s", b1->data);
Note that if the BSTRLIB_NOVSNP macro has been set when bstrlib has been
compiled the bformat function is not present.
..........................................................................
extern int bformata (bstring b, const char * fmt, ...);
In addition to the initial output buffer b, bformata takes the same
parameters as printf (), but rather than outputting results to stdio, it
appends the results to the initial bstring parameter. Note that if
there is an early generation of a '\0' character, the bstring will be
truncated to this end point.
the bstring:
bformata (b0 = bfromcstr ("Hello"), ", %s", b1->data);
compiled the bformata function is not present.
..........................................................................
extern int bassignformat (bstring b, const char * fmt, ...);
After the first parameter, it takes the same parameters as printf (), but
rather than outputting results to stdio, it outputs the results to
the bstring parameter b. Note that if there is an early generation of a
'\0' character, the bstring will be truncated to this end point.
the bstring:
bassignformat (b0 = bfromcstr ("Hello"), ", %s", b1->data);
compiled the bassignformat function is not present.
..........................................................................
extern int bvcformata (bstring b, int count, const char * fmt, va_list argli
st);
The bvcformata function formats data under control of the format control
string fmt and attempts to append the result to b. The fmt parameter is
the same as that of the printf function. The variable argument list is
replaced with arglist, which has been initialized by the va_start macro.
The size of the output is upper bounded by count. If the required output
exceeds count, the string b is not augmented with any contents and a value
below BSTR_ERR is returned. If a value below -count is returned then it
is recommended that the negative of this value be used as an update to the
count in a subsequent pass. On other errors, such as running out of
memory, parameter errors or numeric wrap around BSTR_ERR is returned.
BSTR_OK is returned when the output is successfully generated and
appended to b.
Note: There is no sanity checking of arglist, and this function is
destructive of the contents of b from the b->slen point onward. If there
is an early generation of a '\0' character, the bstring will be truncated
to this end point.
Although this function is part of the external API for Bstrlib, the
interface and semantics (length limitations, and unusual return codes)
are fairly atypical. The real purpose for this function is to provide an
engine for the bvformata macro.
compiled the bvcformata function is not present.
..........................................................................
extern bstring bread (bNread readPtr, void * parm);
typedef size_t (* bNread) (void *buff, size_t elsize, size_t nelem,
void *parm);
Read an entire stream into a bstring, verbatum. The readPtr function
pointer is compatible with fread sematics, except that it need not obtain
the stream data from a file. The intention is that parm would contain
the stream data context/state required (similar to the role of the FILE*
I/O stream parameter of fread.)
Abstracting the block read function allows for block devices other than
file streams to be read if desired. Note that there is an ANSI
compatibility issue if "fread" is used directly; see the ANSI issues
section below.
..........................................................................
extern int breada (bstring b, bNread readPtr, void * parm);
Read an entire stream and append it to a bstring, verbatum. Behaves
like bread, except that it appends it results to the bstring b.
BSTR_ERR is returned on error, otherwise 0 is returned.
..........................................................................
extern bstring bgets (bNgetc getcPtr, void * parm, char terminator);
typedef int (* bNgetc) (void * parm);
Read a bstring from a stream. As many bytes as is necessary are read
until the terminator is consumed or no more characters are available from
the stream. If read from the stream, the terminator character will be
appended to the end of the returned bstring. The getcPtr function must
have the same semantics as the fgetc C library function (i.e., returning
an integer whose value is negative when there are no more characters
available, otherwise the value of the next available unsigned character
from the stream.) The intention is that parm would contain the stream
data context/state required (similar to the role of the FILE* I/O stream
parameter of fgets.) If no characters are read, or there is some other
detectable error, NULL is returned.
bgets will never call the getcPtr function more often than necessary to
construct its output (including a single call, if required, to determine
that the stream contains no more characters.)
Abstracting the character stream function and terminator character allows
for different stream devices and string formats other than '\n'
terminated lines in a file if desired (consider \032 terminated email
messages, in a UNIX mailbox for example.)
For files, this function can be used analogously as fgets as follows:
fp = fopen ( ... );
if (fp) b = bgets ((bNgetc) fgetc, fp, '\n');
(Note that only one terminator character can be used, and that '\0' is
not assumed to terminate the stream in addition to the terminator
character. This is consistent with the semantics of fgets.)
..........................................................................
extern int bgetsa (bstring b, bNgetc getcPtr, void * parm, char terminator);
Read from a stream and concatenate to a bstring. Behaves like bgets,
except that it appends it results to the bstring b. The value 1 is
returned if no characters are read before a negative result is returned
from getcPtr. Otherwise BSTR_ERR is returned on error, and 0 is returned
in other normal cases.
..........................................................................
extern int bassigngets (bstring b, bNgetc getcPtr, void * parm, char termina
tor);
Read from a stream and concatenate to a bstring. Behaves like bgets,
except that it assigns the results to the bstring b. The value 1 is
returned if no characters are read before a negative result is returned
from getcPtr. Otherwise BSTR_ERR is returned on error, and 0 is returned
in other normal cases.
..........................................................................
extern struct bStream * bsopen (bNread readPtr, void * parm);

Wrap a given open stream (described by a fread compatible function
pointer and stream handle) into an open bStream suitable for the bstring
library streaming functions.

..........................................................................
extern void * bsclose (struct bStream * s);

Close the bStream, and return the handle to the stream that was
originally used to open the given stream. If s is NULL or detectably
invalid, NULL will be returned.
..........................................................................
extern int bsbufflength (struct bStream * s, int sz);
Set the length of the buffer used by the bStream. If sz is the macro
BSTR_BS_BUFF_LENGTH_GET (which is 0), the length is not set. If s is
NULL or sz is negative, the function will return with BSTR_ERR, otherwise
this function returns with the previous length.
..........................................................................
extern int bsreadln (bstring r, struct bStream * s, char terminator);

Read a bstring terminated by the terminator character or the end of the
stream from the bStream (s) and return it into the parameter r. The
matched terminator, if found, appears at the end of the line read. If
the stream has been exhausted of all available data, before any can be
read, BSTR_ERR is returned. This function may read additional characters
into the stream buffer from the core stream that are not returned, but
will be retained for subsequent read operations. When reading from high
speed streams, this function can perform significantly faster than bgets.
..........................................................................
extern int bsreadlna (bstring r, struct bStream * s, char terminator);

Read a bstring terminated by the terminator character or the end of the
stream from the bStream (s) and concatenate it to the parameter r. The
matched terminator, if found, appears at the end of the line read. If
the stream has been exhausted of all available data, before any can be
read, BSTR_ERR is returned. This function may read additional characters
into the stream buffer from the core stream that are not returned, but
will be retained for subsequent read operations. When reading from high
speed streams, this function can perform significantly faster than bgets.
..........................................................................
extern int bsreadlns (bstring r, struct bStream * s, bstring terminators);
Read a bstring terminated by any character in the terminators bstring or
the end of the stream from the bStream (s) and return it into the
parameter r. This function may read additional characters from the core
stream that are not returned, but will be retained for subsequent read
operations.
..........................................................................
extern int bsreadlnsa (bstring r, struct bStream * s, bstring terminators);
Read a bstring terminated by any character in the terminators bstring or
the end of the stream from the bStream (s) and concatenate it to the
parameter r. If the stream has been exhausted of all available data,
before any can be read, BSTR_ERR is returned. This function may read
additional characters from the core stream that are not returned, but
will be retained for subsequent read operations.
..........................................................................
extern int bsread (bstring r, struct bStream * s, int n);

Read a bstring of length n (or, if it is fewer, as many bytes as is
remaining) from the bStream. This function will read the minimum
required number of additional characters from the core stream. When the
stream is at the end of the file BSTR_ERR is returned, otherwise BSTR_OK
is returned.
..........................................................................
extern int bsreada (bstring r, struct bStream * s, int n);

Read a bstring of length n (or, if it is fewer, as many bytes as is
remaining) from the bStream and concatenate it to the parameter r. This
function will read the minimum required number of additional characters
from the core stream. When the stream is at the end of the file BSTR_ERR
is returned, otherwise BSTR_OK is returned.

..........................................................................

extern int bsunread (struct bStream * s, const_bstring b);

Insert a bstring into the bStream at the current position. These
characters will be read prior to those that actually come from the core
stream.
..........................................................................
extern int bspeek (bstring r, const struct bStream * s);

Return the number of currently buffered characters from the bStream that
will be read prior to reads from the core stream, and append it to the
the parameter r.
..........................................................................
extern int bssplitscb (struct bStream * s, const_bstring splitStr,
int (* cb) (void * parm, int ofs, const_bstring entry), void * parm);
Iterate the set of disjoint sequential substrings over the stream s
divided by any character from the bstring splitStr. The parm passed to
bssplitscb is passed on to cb. If the function cb returns a value < 0,
then further iterating is halted and this return value is returned by
bssplitscb.
Note: At the point of calling the cb function, the bStream pointer is
pointed exactly at the position right after having read the split
character. The cb function can act on the stream by causing the bStream
pointer to move, and bssplitscb will continue by starting the next split
at the position of the pointer after the return from cb.
However, if the cb causes the bStream s to be destroyed then the cb must
return with a negative value, otherwise bssplitscb will continue in an
undefined manner.
This function is provided as way to incrementally parse through a file
or other generic stream that in total size may otherwise exceed the
practical or desired memory available. As with the other split callback
based functions this is abortable and does not impose additional memory
allocation.
..........................................................................

extern int bssplitstrcb (struct bStream * s, const_bstring splitStr,
int (* cb) (void * parm, int ofs, const_bstring entry), void * parm);
Iterate the set of disjoint sequential substrings over the stream s
divided by the entire substring splitStr. The parm passed to
bssplitstrcb is passed on to cb. If the function cb returns a
value < 0, then further iterating is halted and this return value is
returned by bssplitstrcb.
Note: At the point of calling the cb function, the bStream pointer is
pointed exactly at the position right after having read the split
character. The cb function can act on the stream by causing the bStream
pointer to move, and bssplitstrcb will continue by starting the next
split at the position of the pointer after the return from cb.
However, if the cb causes the bStream s to be destroyed then the cb must
return with a negative value, otherwise bssplitscb will continue in an
undefined manner.
This function is provided as way to incrementally parse through a file
or other generic stream that in total size may otherwise exceed the
practical or desired memory available. As with the other split callback
based functions this is abortable and does not impose additional memory
allocation.

..........................................................................

extern int bseof (const struct bStream * s);
Return the defacto "EOF" (end of file) state of a stream (1 if the
bStream is in an EOF state, 0 if not, and BSTR_ERR if stream is closed or
detectably erroneous.) When the readPtr callback returns a value <= 0
the stream reaches its "EOF" state. Note that bunread with non-empty
content will essentially turn off this state, and the stream will not be
in its "EOF" state so long as its possible to read more data out of it.
Also note that the semantics of bseof() are slightly different from
something like feof(). I.e., reaching the end of the stream does not
necessarily guarantee that bseof() will return with a value indicating
that this has happened. bseof() will only return indicating that it has
reached the "EOF" and an attempt has been made to read past the end of
the bStream.
The macros
----------
The macros described below are shown in a prototype form indicating their
intended usage. Note that the parameters passed to these macros will be
referenced multiple times. As with all macros, programmer care is
required to guard against unintended side effects.
int blengthe (const_bstring b, int err);
Returns the length of the bstring. If the bstring is NULL err is
returned.
..........................................................................
int blength (const_bstring b);
Returns the length of the bstring. If the bstring is NULL, the length
returned is 0.
..........................................................................
int bchare (const_bstring b, int p, int c);
Returns the p'th character of the bstring b. If the position p refers to
a position that does not exist in the bstring or the bstring is NULL,
then c is returned.
..........................................................................
char bchar (const_bstring b, int p);
Returns the p'th character of the bstring b. If the position p refers to
a position that does not exist in the bstring or the bstring is NULL,
then '\0' is returned.
..........................................................................
char * bdatae (bstring b, char * err);
Returns the char * data portion of the bstring b. If b is NULL, err is
returned.
..........................................................................
char * bdata (bstring b);
Returns the char * data portion of the bstring b. If b is NULL, NULL is
returned.
..........................................................................
char * bdataofse (bstring b, int ofs, char * err);
Returns the char * data portion of the bstring b offset by ofs. If b is
NULL, err is returned.
..........................................................................
char * bdataofs (bstring b, int ofs);
Returns the char * data portion of the bstring b offset by ofs. If b is
NULL, NULL is returned.
..........................................................................
struct tagbstring var = bsStatic ("...");
The bsStatic macro allows for static declarations of literal string
constants as struct tagbstring structures. The resulting tagbstring does
not need to be freed or destroyed. Note that this macro is only well
defined for string literal arguments. For more general string pointers,
use the btfromcstr macro.
The resulting struct tagbstring is permanently write protected. Attempts
to write to this struct tagbstring from any bstrlib function will lead to
BSTR_ERR being returned. Invoking the bwriteallow macro onto this struct
tagbstring has no effect.
..........................................................................
<void * blk, int len> <- bsStaticBlkParms ("...")
The bsStaticBlkParms macro emits a pair of comma seperated parameters
corresponding to the block parameters for the block functions in Bstrlib
(i.e., blk2bstr, bcatblk, blk2tbstr, bisstemeqblk, bisstemeqcaselessblk.)
Note that this macro is only well defined for string literal arguments.
Examples:
bstring b = blk2bstr (bsStaticBlkParms ("Fast init. "));
bcatblk (b, bsStaticBlkParms ("No frills fast concatenation."));
These are faster than using bfromcstr() and bcatcstr() respectively
because the length of the inline string is known as a compile time
constant. Also note that seperate struct tagbstring declarations for
holding the output of a bsStatic() macro are not required.
..........................................................................
void btfromcstr (struct tagbstring& t, const char * s);
Fill in the tagbstring t with the '\0' terminated char buffer s. This
action is purely reference oriented; no memory management is done. The
data member is just assigned s, and slen is assigned the strlen of s.
The s parameter is accessed exactly once in this macro.
The resulting struct tagbstring is initially write protected. Attempts
to write to this struct tagbstring in a write protected state from any
bstrlib function will lead to BSTR_ERR being returned. Invoke the
bwriteallow on this struct tagbstring to make it writeable (though this
requires that s be obtained from a function compatible with malloc.)
..........................................................................
void btfromblk (struct tagbstring& t, void * s, int len);
Fill in the tagbstring t with the data buffer s with length len. This
action is purely reference oriented; no memory management is done. The
data member of t is just assigned s, and slen is assigned len. Note that
the buffer is not appended with a '\0' character. The s and len
parameters are accessed exactly once each in this macro.
The resulting struct tagbstring is initially write protected. Attempts
bstrlib function will lead to BSTR_ERR being returned. Invoke the
bwriteallow on this struct tagbstring to make it writeable (though this
requires that s be obtained from a function compatible with malloc.)
..........................................................................
void btfromblkltrimws (struct tagbstring& t, void * s, int len);
Fill in the tagbstring t with the data buffer s with length len after it
has been left trimmed. This action is purely reference oriented; no
memory management is done. The data member of t is just assigned to a
pointer inside the buffer s. Note that the buffer is not appended with a
'\0' character. The s and len parameters are accessed exactly once each
in this macro.
..........................................................................
void btfromblkrtrimws (struct tagbstring& t, void * s, int len);
has been right trimmed. This action is purely reference oriented; no
memory management is done. The data member of t is just assigned to a
pointer inside the buffer s. Note that the buffer is not appended with a
'\0' character. The s and len parameters are accessed exactly once each
in this macro.
..........................................................................
void btfromblktrimws (struct tagbstring& t, void * s, int len);
has been left and right trimmed. This action is purely reference
oriented; no memory management is done. The data member of t is just
assigned to a pointer inside the buffer s. Note that the buffer is not
appended with a '\0' character. The s and len parameters are accessed
exactly once each in this macro.
..........................................................................
void bmid2tbstr (struct tagbstring& t, bstring b, int pos, int len);
Fill the tagbstring t with the substring from b, starting from position
pos with a length len. The segment is clamped by the boundaries of
the bstring b. This action is purely reference oriented; no memory
management is done. Note that the buffer is not appended with a '\0'
character. Note that the t parameter to this macro may be accessed
multiple times. Note that the contents of t will become undefined
if the contents of b change or are destroyed.
bstrlib function will lead to BSTR_ERR being returned. Invoking the
bwriteallow macro on this struct tagbstring will have no effect.
..........................................................................
void bvformata (int& ret, bstring b, const char * format, lastarg);
Append the bstring b with printf like formatting with the format control
string, and the arguments taken from the ... list of arguments after
lastarg passed to the containing function. If the containing function
does not have ... parameters or lastarg is not the last named parameter
before the ... then the results are undefined. If successful, the
results are appended to b and BSTR_OK is assigned to ret. Otherwise
BSTR_ERR is assigned to ret.
Example:
void dbgerror (FILE * fp, const char * fmt, ...) {
int ret;
bstring b;
bvformata (ret, b = bfromcstr ("DBG: "), fmt, fmt);
if (BSTR_OK == ret) fputs ((char *) bdata (b), fp);
bdestroy (b);
}
Note that if the BSTRLIB_NOVSNP macro was set when bstrlib had been
compiled the bvformata macro will not link properly. If the
BSTRLIB_NOVSNP macro has been set, the bvformata macro will not be
available.
..........................................................................
void bwriteprotect (struct tagbstring& t);
Disallow bstring from being written to via the bstrlib API. Attempts to
write to the resulting tagbstring from any bstrlib function will lead to
BSTR_ERR being returned.
Note: bstrings which are write protected cannot be destroyed via bdestroy.
Note to C++ users: Setting a CBString as write protected will not prevent
it from being destroyed by the destructor.
..........................................................................
void bwriteallow (struct tagbstring& t);
Allow bstring to be written to via the bstrlib API. Note that such an
action makes the bstring both writable and destroyable. If the bstring is
not legitimately writable (as is the case for struct tagbstrings
initialized with a bsStatic value), the results of this are undefined.
Note that invoking the bwriteallow macro may increase the number of
reallocs by one more than necessary for every call to bwriteallow
interleaved with any bstring API which writes to this bstring.
..........................................................................
int biswriteprotected (struct tagbstring& t);
Returns 1 if the bstring is write protected, otherwise 0 is returned.
===============================================================================
The bstest module
-----------------
The bstest module is just a unit test for the bstrlib module. For correct
implementations of bstrlib, it should execute with 0 failures being reported.
This test should be utilized if modifications/customizations to bstrlib have
been performed. It tests each core bstrlib function with bstrings of every
mode (read-only, NULL, static and mutable) and ensures that the expected
semantics are observed (including results that should indicate an error). It
also tests for aliasing support. Passing bstest is a necessary but not a
sufficient condition for ensuring the correctness of the bstrlib module.
The test module
---------------
The test module is just a unit test for the bstrwrap module. For correct
implementations of bstrwrap, it should execute with 0 failures being
reported. This test should be utilized if modifications/customizations to
bstrwrap have been performed. It tests each core bstrwrap function with
CBStrings write protected or not and ensures that the expected semantics are
observed (including expected exceptions.) Note that exceptions cannot be
disabled to run this test. Passing test is a necessary but not a sufficient
condition for ensuring the correctness of the bstrwrap module.
===============================================================================
Using Bstring and CBString as an alternative to the C library
-------------------------------------------------------------
First let us give a table of C library functions and the alternative bstring
functions and CBString methods that should be used instead of them.
C-library Bstring alternative CBString alternative
--------- ------------------- --------------------
gets bgets ::gets
strcpy bassign = operator
strncpy bassignmidstr ::midstr
strcat bconcat += operator
strncat bconcat + btrunc += operator + ::trunc
strtok bsplit, bsplits ::split
sprintf b(assign)format ::format
snprintf b(assign)format + btrunc ::format + ::trunc
vsprintf bvformata bvformata
vsnprintf bvformata + btrunc bvformata + btrunc
vfprintf bvformata + fputs use bvformata + fputs
strcmp biseq, bstrcmp comparison operators.
strncmp bstrncmp, memcmp bstrncmp, memcmp
strlen ->slen, blength ::length
strdup bstrcpy constructor
strset bpattern ::fill
strstr binstr ::find
strpbrk binchr ::findchr
stricmp bstricmp cast & use bstricmp
strlwr btolower cast & use btolower
strupr btoupper cast & use btoupper
strrev bReverse (aux module) cast & use bReverse
strchr bstrchr cast & use bstrchr
strspnp use strspn use strspn
ungetc bsunread bsunread
The top 9 C functions listed here are troublesome in that they impose memory
management in the calling function. The Bstring and CBstring interfaces have
built-in memory management, so there is far less code with far less potential
for buffer overrun problems. strtok can only be reliably called as a "leaf"
calculation, since it (quite bizarrely) maintains hidden internal state. And
gets is well known to be broken no matter what. The Bstrlib alternatives do
not suffer from those sorts of problems.
The substitute for strncat can be performed with higher performance by using
the blk2tbstr macro to create a presized second operand for bconcat.
--------- ------------------- --------------------
strspn strspn acceptable strspn acceptable
strcspn strcspn acceptable strcspn acceptable
strnset strnset acceptable strnset acceptable
printf printf acceptable printf acceptable
puts puts acceptable puts acceptable
fprintf fprintf acceptable fprintf acceptable
fputs fputs acceptable fputs acceptable
memcmp memcmp acceptable memcmp acceptable
Remember that Bstring (and CBstring) functions will automatically append the
'\0' character to the character data buffer. So by simply accessing the data
buffer directly, ordinary C string library functions can be called directly
on them. Note that bstrcmp is not the same as memcmp in exactly the same way
that strcmp is not the same as memcmp.
--------- ------------------- --------------------
fread balloc + fread ::alloc + fread
fgets balloc + fgets ::alloc + fgets
These are odd ones because of the exact sizing of the buffer required. The
Bstring and CBString alternatives requires that the buffers are forced to
hold at least the prescribed length, then just use fread or fgets directly.
However, typically the automatic memory management of Bstring and CBstring
will make the typical use of fgets and fread to read specifically sized
strings unnecessary.
Implementation Choices
----------------------
Overhead:
.........
The bstring library has more overhead versus straight char buffers for most
functions. This overhead is essentially just the memory management and
string header allocation. This overhead usually only shows up for small
string manipulations. The performance loss has to be considered in
light of the following:
1) What would be the performance loss of trying to write this management
code in one's own application?
2) Since the bstring library source code is given, a sufficiently powerful
modern inlining globally optimizing compiler can remove function call
overhead.
Since the data type is exposed, a developer can replace any unsatisfactory
function with their own inline implementation. And that is besides the main
point of what the better string library is mainly meant to provide. Any
overhead lost has to be compared against the value of the safe abstraction
for coupling memory management and string functionality.
Performance of the C interface:
...............................
The algorithms used have performance advantages versus the analogous C
library functions. For example:
1. bfromcstr/blk2str/bstrcpy versus strcpy/strdup. By using memmove instead
of strcpy, the break condition of the copy loop is based on an independent
counter (that should be allocated in a register) rather than having to
check the results of the load. Modern out-of-order executing CPUs can
parallelize the final branch mis-predict penality with the loading of the
source string. Some CPUs will also tend to have better built-in hardware
support for counted memory moves than load-compare-store. (This is a
minor, but non-zero gain.)
2. biseq versus strcmp. If the strings are unequal in length, bsiseq will
return in O(1) time. If the strings are aliased, or have aliased data
buffers, biseq will return in O(1) time. strcmp will always be O(k),
where k is the length of the common prefix or the whole string if they are
identical.
3. ->slen versus strlen. ->slen is obviously always O(1), while strlen is
always O(n) where n is the length of the string.
4. bconcat versus strcat. Both rely on precomputing the length of the
destination string argument, which will favor the bstring library. On
iterated concatenations the performance difference can be enormous.
5. bsreadln versus fgets. The bsreadln function reads large blocks at a time
from the given stream, then parses out lines from the buffers directly.
Some C libraries will implement fgets as a loop over single fgetc calls.
Testing indicates that the bsreadln approach can be several times faster
for fast stream devices (such as a file that has been entirely cached.)
6. bsplits/bsplitscb versus strspn. Accelerators for the set of match
characters are generated only once.
7. binstr versus strstr. The binstr implementation unrolls the loops to
help reduce loop overhead. This will matter if the target string is
long and source string is not found very early in the target string.
With strstr, while it is possible to unroll the source contents, it is
not possible to do so with the destination contents in a way that is
effective because every destination character must be tested against
'\0' before proceeding to the next character.
8. bReverse versus strrev. The C function must find the end of the string
first before swaping character pairs.
9. bstrrchr versus no comparable C function. Its not hard to write some C
code to search for a character from the end going backwards. But there
is no way to do this without computing the length of the string with
strlen.
Practical testing indicates that in general Bstrlib is never signifcantly
slower than the C library for common operations, while very often having a
performance advantage that ranges from significant to massive. Even for
functions like b(n)inchr versus str(c)spn() (where, in theory, there is no
advantage for the Bstrlib architecture) the performance of Bstrlib is vastly
superior to most tested C library implementations.
Some of Bstrlib's extra functionality also lead to inevitable performance
advantages over typical C solutions. For example, using the blk2tbstr macro,
one can (in O(1) time) generate an internal substring by reference while not
disturbing the original string. If disturbing the original string is not an
option, typically, a comparable char * solution would have to make a copy of
the substring to provide similar functionality. Another example is reverse
character set scanning -- the str(c)spn functions only scan in a forward
direction which can complicate some parsing algorithms.
Where high performance char * based algorithms are available, Bstrlib can
still leverage them by accessing the ->data field on bstrings. So
realistically Bstrlib can never be significantly slower than any standard
'\0' terminated char * based solutions.
Performance of the C++ interface:
.................................
The C++ interface has been designed with an emphasis on abstraction and safety
first. However, since it is substantially a wrapper for the C bstring
functions, for longer strings the performance comments described in the
"Performance of the C interface" section above still apply. Note that the
(CBString *) type can be directly cast to a (bstring) type, and passed as
parameters to the C functions (though a CBString must never be passed to
bdestroy.)
Probably the most controversial choice is performing full bounds checking on
the [] operator. This decision was made because 1) the fast alternative of
not bounds checking is still available by first casting the CBString to a
(const char *) buffer or to a (struct tagbstring) then derefencing .data and
2) because the lack of bounds checking is seen as one of the main weaknesses
of C/C++ versus other languages. This check being done on every access leads
to individual character extraction being actually slower than other languages
in this one respect (other language's compilers will normally dedicate more
resources on hoisting or removing bounds checking as necessary) but otherwise
bring C++ up to the level of other languages in terms of functionality.
It is common for other C++ libraries to leverage the abstractions provided by
C++ to use reference counting and "copy on write" policies. While these
techniques can speed up some scenarios, they impose a problem with respect to
thread safety. bstrings and CBStrings can be properly protected with
"per-object" mutexes, meaning that two bstrlib calls can be made and execute
simultaneously, so long as the bstrings and CBstrings are distinct. With a
reference count and alias before copy on write policy, global mutexes are
required that prevent multiple calls to the strings library to execute
simultaneously regardless of whether or not the strings represent the same
string.
One interesting trade off in CBString is that the default constructor is not
trivial. I.e., it always prepares a ready to use memory buffer. The purpose
is to ensure that there is a uniform internal composition for any functioning
CBString that is compatible with bstrings. It also means that the other
methods in the class are not forced to perform "late initialization" checks.
In the end it means that construction of CBStrings are slower than other
comparable C++ string classes. Initial testing, however, indicates that
CBString outperforms std::string and MFC's CString, for example, in all other
operations. So to work around this weakness it is recommended that CBString
declarations be pushed outside of inner loops.
Practical testing indicates that with the exception of the caveats given
above (constructors and safe index character manipulations) the C++ API for
Bstrlib generally outperforms popular standard C++ string classes. Amongst
the standard libraries and compilers, the quality of concatenation operations
varies wildly and very little care has gone into search functions. Bstrlib
dominates those performance benchmarks.
Memory management:
..................
The bstring functions which write and modify bstrings will automatically
reallocate the backing memory for the char buffer whenever it is required to
grow. The algorithm for resizing chosen is to snap up to sizes that are a
power of two which are sufficient to hold the intended new size. Memory
reallocation is not performed when the required size of the buffer is
decreased. This behavior can be relied on, and is necessary to make the
behaviour of balloc deterministic. This trades off additional memory usage
for decreasing the frequency for required reallocations:
1. For any bstring whose size never exceeds n, its buffer is not ever
reallocated more than log_2(n) times for its lifetime.
2. For any bstring whose size never exceeds n, its buffer is never more than
2*(n+1) in length. (The extra characters beyond 2*n are to allow for the
implicit '\0' which is always added by the bstring modifying functions.)
Decreasing the buffer size when the string decreases in size would violate 1)
above and in real world case lead to pathological heap thrashing. Similarly,
allocating more tightly than "least power of 2 greater than necessary" would
lead to a violation of 1) and have the same potential for heap thrashing.
Property 2) needs emphasizing. Although the memory allocated is always a
power of 2, for a bstring that grows linearly in size, its buffer memory also
grows linearly, not exponentially. The reason is that the amount of extra
space increases with each reallocation, which decreases the frequency of
future reallocations.
Obviously, given that bstring writing functions may reallocate the data
buffer backing the target bstring, one should not attempt to cache the data
buffer address and use it after such bstring functions have been called.
This includes making reference struct tagbstrings which alias to a writable
bstring.
balloc or bfromcstralloc can be used to preallocate the minimum amount of
space used for a given bstring. This will reduce even further the number of
times the data portion is reallocated. If the length of the string is never
more than one less than the memory length then there will be no further
reallocations.
Note that invoking the bwriteallow macro may increase the number of reallocs
by one more than necessary for every call to bwriteallow interleaved with any
bstring API which writes to this bstring.
The library does not use any mechanism for automatic clean up for the C API.
Thus explicit clean up via calls to bdestroy() are required to avoid memory
leaks.
Constant and static tagbstrings:
................................
A struct tagbstring can be write protected from any bstrlib function using
the bwriteprotect macro. A write protected struct tagbstring can then be
reset to being writable via the bwriteallow macro. There is, of course, no
protection from attempts to directly access the bstring members. Modifying a
bstring which is write protected by direct access has undefined behavior.
static struct tagbstrings can be declared via the bsStatic macro. They are
considered permanently unwritable. Such struct tagbstrings's are declared
such that attempts to write to it are not well defined. Invoking either
bwriteallow or bwriteprotect on static struct tagbstrings has no effect.
struct tagbstring's initialized via btfromcstr or blk2tbstr are protected by
default but can be made writeable via the bwriteallow macro. If bwriteallow
is called on such struct tagbstring's, it is the programmer's responsibility
to ensure that:
1) the buffer supplied was allocated from the heap.
2) bdestroy is not called on this tagbstring (unless the header itself has
also been allocated from the heap.)
3) free is called on the buffer to reclaim its memory.
bwriteallow and bwriteprotect can be invoked on ordinary bstrings (they have
to be dereferenced with the (*) operator to get the levels of indirection
correct) to give them write protection.
Buffer declaration:
...................
The memory buffer is actually declared "unsigned char *" instead of "char *".
The reason for this is to trigger compiler warnings whenever uncasted char
buffers are assigned to the data portion of a bstring. This will draw more
diligent programmers into taking a second look at the code where they
have carelessly left off the typically required cast. (Research from
AT&T/Lucent indicates that additional programmer eyeballs is one of the most
effective mechanisms at ferreting out bugs.)
Function pointers:
..................
The bgets, bread and bStream functions use function pointers to obtain
strings from data streams. The function pointer declarations have been
specifically chosen to be compatible with the fgetc and fread functions.
While this may seem to be a convoluted way of implementing fgets and fread
style functionality, it has been specifically designed this way to ensure
that there is no dependency on a single narrowly defined set of device
interfaces, such as just stream I/O. In the embedded world, its quite
possible to have environments where such interfaces may not exist in the
standard C library form. Furthermore, the generalization that this opens up
allows for more sophisticated uses for these functions (performing an fgets
like function on a socket, for example.) By using function pointers, it also
allows such abstract stream interfaces to be created using the bstring library
itself while not creating a circular dependency.
Use of int's for sizes:
.......................
This is just a recognition that 16bit platforms with requirements for strings
that are larger than 64K and 32bit+ platforms with requirements for strings
that are larger than 4GB are pretty marginal. The main focus is for 32bit
platforms, and emerging 64bit platforms with reasonable < 4GB string
requirements. Using ints allows for negative values which has meaning
internally to bstrlib.
Semantic consideration:
.......................
Certain care needs to be taken when copying and aliasing bstrings. A bstring
is essentially a pointer type which points to a multipart abstract data
structure. Thus usage, and lifetime of bstrings have semantics that follow
these considerations. For example:
bstring a, b;
struct tagbstring t;
a = bfromcstr("Hello"); /* Create new bstring and copy "Hello" into it. */
b = a; /* Alias b to the contents of a. */
t = *a; /* Create a current instance pseudo-alias of a. */
bconcat (a, b); /* Double a and b, t is now undefined. */
bdestroy (a); /* Destroy the contents of both a and b. */
Variables of type bstring are really just references that point to real
bstring objects. The equal operator (=) creates aliases, and the asterisk
dereference operator (*) creates a kind of alias to the current instance (which
is generally not useful for any purpose.) Using bstrcpy() is the correct way
of creating duplicate instances. The ampersand operator (&) is useful for
creating aliases to struct tagbstrings (remembering that constructed struct
tagbstrings are not writable by default.)
CBStrings use complete copy semantics for the equal operator (=), and thus do
not have these sorts of issues.
Debugging:
..........
Bstrings have a simple, exposed definition and construction, and the library
itself is open source. So most debugging is going to be fairly straight-
forward. But the memory for bstrings come from the heap, which can often be
corrupted indirectly, and it might not be obvious what has happened even from
direct examination of the contents in a debugger or a core dump. There are
some tools such as Purify, Insure++ and Electric Fence which can help solve
such problems, however another common approach is to directly instrument the
calls to malloc, realloc, calloc, free, memcpy, memmove and/or other calls
by overriding them with macro definitions.
Although the user could hack on the Bstrlib sources directly as necessary to
perform such an instrumentation, Bstrlib comes with a built-in mechanism for
doing this. By defining the macro BSTRLIB_MEMORY_DEBUG and providing an
include file named memdbg.h this will force the core Bstrlib modules to
attempt to include this file. In such a file, macros could be defined which
overrides Bstrlib's useage of the C standard library.
Rather than calling malloc, realloc, free, memcpy or memmove directly, Bstrlib
emits the macros bstr__alloc, bstr__realloc, bstr__free, bstr__memcpy and
bstr__memmove in their place respectively. By default these macros are simply
assigned to be equivalent to their corresponding C standard library function
call. However, if they are given earlier macro definitions (via the back
door include file) they will not be given their default definition. In this
way Bstrlib's interface to the standard library can be changed but without
having to directly redefine or link standard library symbols (both of which
are not strictly ANSI C compliant.)
An example definition might include:
#define bstr__alloc(sz) X_malloc ((sz), __LINE__, __FILE__)
which might help contextualize heap entries in a debugging environment.
The NULL parameter and sanity checking of bstrings is part of the Bstrlib
API, and thus Bstrlib itself does not present any different modes which would
correspond to "Debug" or "Release" modes. Bstrlib always contains mechanisms
which one might think of as debugging features, but retains the performance
and small memory footprint one would normally associate with release mode
code.
Integration Microsoft's Visual Studio debugger:
...............................................
Microsoft's Visual Studio debugger has a capability of customizable mouse
float over data type descriptions. This is accomplished by editting the
AUTOEXP.DAT file to include the following:
; new for CBString
tagbstring =slen=<slen> mlen=<mlen> <data,st>
Bstrlib::CBStringList =count=<size()>
In Visual C++ 6.0 this file is located in the directory:
C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin
and in Visual Studio .NET 2003 its located here:
C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Packages\Debugger
This will improve the ability of debugging with Bstrlib under Visual Studio.
Security
--------
Bstrlib does not come with explicit security features outside of its fairly
comprehensive error detection, coupled with its strict semantic support.
That is to say that certain common security problems, such as buffer overrun,
constant overwrite, arbitrary truncation etc, are far less likely to happen
inadvertently. Where it does help, Bstrlib maximizes its advantage by
providing developers a simple adoption path that lets them leave less secure
string mechanisms behind. The library will not leave developers wanting, so
they will be less likely to add new code using a less secure string library
to add functionality that might be missing from Bstrlib.
That said there are a number of security ideas not addressed by Bstrlib:
1. Race condition exploitation (i.e., verifying a string's contents, then
raising the privilege level and execute it as a shell command as two
non-atomic steps) is well beyond the scope of what Bstrlib can provide. It
should be noted that MFC's built-in string mutex actually does not solve this
problem either -- it just removes immediate data corruption as a possible
outcome of such exploit attempts (it can be argued that this is worse, since
it will leave no trace of the exploitation). In general race conditions have
to be dealt with by careful design and implementation; it cannot be assisted
by a string library.
2. Any kind of access control or security attributes to prevent usage in
dangerous interfaces such as system(). Perl includes a "trust" attribute
which can be endowed upon strings that are intended to be passed to such
dangerous interfaces. However, Perl's solution reflects its own limitations
-- notably that it is not a strongly typed language. In the example code for
Bstrlib, there is a module called taint.cpp. It demonstrates how to write a
simple wrapper class for managing "untainted" or trusted strings using the
type system to prevent questionable mixing of ordinary untrusted strings with
untainted ones then passing them to dangerous interfaces. In this way the
security correctness of the code reduces to auditing the direct usages of
dangerous interfaces or promotions of tainted strings to untainted ones.
3. Encryption of string contents is way beyond the scope of Bstrlib.
Maintaining encrypted string contents in the futile hopes of thwarting things
like using system-level debuggers to examine sensitive string data is likely
to be a wasted effort (imagine a debugger that runs at a higher level than a
virtual processor where the application runs). For more standard encryption
usages, since the bstring contents are simply binary blocks of data, this
should pose no problem for usage with other standard encryption libraries.
Compatibility
-------------
The Better String Library is known to compile and function correctly with the
following compilers:
- Microsoft Visual C++
- Watcom C/C++
- Intel's C/C++ compiler (Windows)
- The GNU C/C++ compiler (cygwin and Linux on PPC64)
- Borland C
- Turbo C
Setting of configuration options should be unnecessary for these compilers
(unless exceptions are being disabled or STLport has been added to WATCOM
C/C++). Bstrlib has been developed with an emphasis on portability. As such
porting it to other compilers should be straight forward. This package
includes a porting guide (called porting.txt) which explains what issues may
exist for porting Bstrlib to different compilers and environments.
ANSI issues
-----------
1. The function pointer types bNgetc and bNread have prototypes which are very
similar to, but not exactly the same as fgetc and fread respectively.
Basically the FILE * parameter is replaced by void *. The purpose of this
was to allow one to create other functions with fgetc and fread like
semantics without being tied to ANSI C's file streaming mechanism. I.e., one
could very easily adapt it to sockets, or simply reading a block of memory,
or procedurally generated strings (for fractal generation, for example.)
The problem is that invoking the functions (bNgetc)fgetc and (bNread)fread is
not technically legal in ANSI C. The reason being that the compiler is only
able to coerce the function pointers themselves into the target type, however
are unable to perform any cast (implicit or otherwise) on the parameters
passed once invoked. I.e., if internally void * and FILE * need some kind of
mechanical coercion, the compiler will not properly perform this conversion
and thus lead to undefined behavior.
Apparently a platform from Data General called "Eclipse" and another from
Tandem called "NonStop" have a different representation for pointers to bytes
and pointers to words, for example, where coercion via casting is necessary.
(Actual confirmation of the existence of such machines is hard to come by, so
it is prudent to be skeptical about this information.) However, this is not
an issue for any known contemporary platforms. One may conclude that such
platforms are effectively apocryphal even if they do exist.
To correctly work around this problem to the satisfaction of the ANSI
limitations, one needs to create wrapper functions for fgets and/or
fread with the prototypes of bNgetc and/or bNread respectively which performs
no other action other than to explicitely cast the void * parameter to a
FILE *, and simply pass the remaining parameters straight to the function
pointer call.
The wrappers themselves are trivial:
size_t freadWrap (void * buff, size_t esz, size_t eqty, void * parm) {
return fread (buff, esz, eqty, (FILE *) parm);
}
int fgetcWrap (void * parm) {
return fgetc ((FILE *) parm);
}
These have not been supplied in bstrlib or bstraux to prevent unnecessary
linking with file I/O functions.
2. vsnprintf is not available on all compilers. Because of this, the bformat
and bformata functions (and format and formata methods) are not guaranteed to
work properly. For those compilers that don't have vsnprintf, the
BSTRLIB_NOVSNP macro should be set before compiling bstrlib, and the format
functions/method will be disabled.
The more recent ANSI C standards have specified the required inclusion of a
vsnprintf function.
3. The bstrlib function names are not unique in the first 6 characters. This
is only an issue for older C compiler environments which do not store more
than 6 characters for function names.
4. The bsafe module defines macros and function names which are part of the
C library. This simply overrides the definition as expected on all platforms
tested, however it is not sanctioned by the ANSI standard. This module is
clearly optional and should be omitted on platforms which disallow its
undefined semantics.
In practice the real issue is that some compilers in some modes of operation
can/will inline these standard library functions on a module by module basis
as they appear in each. The linker will thus have no opportunity to override
the implementation of these functions for those cases. This can lead to
inconsistent behaviour of the bsafe module on different platforms and
compilers.
===============================================================================
Comparison with Microsoft's CString class
-----------------------------------------
Although developed independently, CBStrings have very similar functionality to
Microsoft's CString class. However, the bstring library has significant
advantages over CString:
1. Bstrlib is a C-library as well as a C++ library (using the C++ wrapper).
- Thus it is compatible with more programming environments and
available to a wider population of programmers.
2. The internal structure of a bstring is considered exposed.
- A single contiguous block of data can be cut into read-only pieces by
simply creating headers, without allocating additional memory to create
reference copies of each of these sub-strings.
- In this way, using bstrings in a totally abstracted way becomes a choice
rather than an imposition. Further this choice can be made differently
at different layers of applications that use it.
3. Static declaration support precludes the need for constructor
invocation.
- Allows for static declarations of constant strings that has no
additional constructor overhead.
4. Bstrlib is not attached to another library.
- Bstrlib is designed to be easily plugged into any other library
collection, without dependencies on other libraries or paradigms (such
as "MFC".)
The bstring library also comes with a few additional functions that are not
available in the CString class:
- bsetstr
- bsplit
- bread
- breplace (this is different from CString::Replace())
- Writable indexed characters (for example a[i]='x')
Interestingly, although Microsoft did implement mid$(), left$() and right$()
functional analogues (these are functions from GWBASIC) they seem to have
forgotten that mid$() could be also used to write into the middle of a string.
This functionality exists in Bstrlib with the bsetstr() and breplace()
functions.
Among the disadvantages of Bstrlib is that there is no special support for
localization or wide characters. Such things are considered beyond the scope
of what bstrings are trying to deliver. CString essentially supports the
older UCS-2 version of Unicode via widechar_t as an application-wide compile
time switch.
CString's also use built-in mechanisms for ensuring thread safety under all
situations. While this makes writing thread safe code that much easier, this
built-in safety feature has a price -- the inner loops of each CString method
runs in its own critical section (grabbing and releasing a light weight mutex
on every operation.) The usual way to decrease the impact of a critical
section performance penalty is to amortize more operations per critical
section. But since the implementation of CStrings is fixed as a one critical
section per-operation cost, there is no way to leverage this common
performance enhancing idea.
The search facilities in Bstrlib are comparable to those in MFC's CString
class, though it is missing locale specific collation. But because Bstrlib
is interoperable with C's char buffers, it will allow programmers to write
their own string searching mechanism (such as Boyer-Moore), or be able to
choose from a variety of available existing string searching libraries (such
as those for regular expressions) without difficulty.
Microsoft used a very non-ANSI conforming trick in its implementation to
allow printf() to use the "%s" specifier to output a CString correctly. This
can be convenient, but it is inherently not portable. CBString requires an
explicit cast, while bstring requires the data member to be dereferenced.
Microsoft's own documentation recommends casting, instead of relying on this
feature.
Comparison with C++'s std::string
---------------------------------
This is the C++ language's standard STL based string class.
1. There is no C implementation.
2. The [] operator is not bounds checked.
3. Missing a lot of useful functions like printf-like formatting.
4. Some sub-standard std::string implementations (SGI) are necessarily unsafe
to use with multithreading.
5. Limited by STL's std::iostream which in turn is limited by ifstream which
can only take input from files. (Compare to CBStream's API which can take
abstracted input.)
6. Extremely uneven performance across implementations.
Comparison with ISO C TR 24731 proposal
---------------------------------------
Following the ISO C99 standard, Microsoft has proposed a group of C library
extensions which are supposedly "safer and more secure". This proposal is
expected to be adopted by the ISO C standard which follows C99.
The proposal reveals itself to be very similar to Microsoft's "StrSafe"
library. The functions are basically the same as other standard C library
string functions except that destination parameters are paired with an
additional length parameter of type rsize_t. rsize_t is the same as size_t,
however, the range is checked to make sure its between 1 and RSIZE_MAX. Like
Bstrlib, the functions perform a "parameter check". Unlike Bstrlib, when a
parameter check fails, rather than simply outputing accumulatable error
statuses, they call a user settable global error function handler, and upon
return of control performs no (additional) detrimental action. The proposal
covers basic string functions as well as a few non-reenterable functions
(asctime, ctime, and strtok).
1. Still based solely on char * buffers (and therefore strlen() and strcat()
is still O(n), and there are no faster streq() comparison functions.)
2. No growable string semantics.
3. Requires manual buffer length synchronization in the source code.
4. No attempt to enhance functionality of the C library.
5. Introduces a new error scenario (strings exceeding RSIZE_MAX length).
The hope is that by exposing the buffer length requirements there will be
fewer buffer overrun errors. However, the error modes are really just
transformed, rather than removed. The real problem of buffer overflows is
that they all happen as a result of erroneous programming. So forcing
programmers to manually deal with buffer limits, will make them more aware of
the problem but doesn't remove the possibility of erroneous programming. So
a programmer that erroneously mixes up the rsize_t parameters is no better off
from a programmer that introduces potential buffer overflows through other
more typical lapses. So at best this may reduce the rate of erroneous
programming, rather than making any attempt at removing failure modes.
The error handler can discriminate between types of failures, but does not
take into account any callsite context. So the problem is that the error is
going to be manifest in a piece of code, but there is no pointer to that
code. It would seem that passing in the call site __FILE__, __LINE__ as
parameters would be very useful, but the API clearly doesn't support such a
thing (it would increase code bloat even more than the extra length
parameter does, and would require macro tricks to implement).
The Bstrlib C API takes the position that error handling needs to be done at
the callsite, and just tries to make it as painless as possible. Furthermore,
error modes are removed by supporting auto-growing strings and aliasing. For
capturing errors in more central code fragments, Bstrlib's C++ API uses
exception handling extensively, which is superior to the leaf-only error
handler approach.
Comparison with Managed String Library CERT proposal
----------------------------------------------------
The main webpage for the managed string library:
http://www.cert.org/secure-coding/managedstring.html
Robert Seacord at CERT has proposed a C string library that he calls the
"Managed String Library" for C. Like Bstrlib, it introduces a new type
which is called a managed string. The structure of a managed string
(string_m) is like a struct tagbstring but missing the length field. This
internal structure is considered opaque. The length is, like the C standard
library, always computed on the fly by searching for a terminating NUL on
every operation that requires it. So it suffers from every performance
problem that the C standard library suffers from. Interoperating with C
string APIs (like printf, fopen, or anything else that takes a string
parameter) requires copying to additionally allocating buffers that have to
be manually freed -- this makes this library probably slower and more
cumbersome than any other string library in existence.
The library gives a fully populated error status as the return value of every
string function. The hope is to be able to diagnose all problems
specifically from the return code alone. Comparing this to Bstrlib, which
aways returns one consistent error message, might make it seem that Bstrlib
would be harder to debug; but this is not true. With Bstrlib, if an error
occurs there is always enough information from just knowing there was an error
and examining the parameters to deduce exactly what kind of error has
happened. The managed string library thus gives up nested function calls
while achieving little benefit, while Bstrlib does not.
One interesting feature that "managed strings" has is the idea of data
sanitization via character set whitelisting. That is to say, a globally
definable filter that makes any attempt to put invalid characters into strings
lead to an error and not modify the string. The author gives the following
example:
// create valid char set
if (retValue = strcreate_m(&str1, "abc") ) {
fprintf(
stderr,
"Error %d from strcreate_m.\n",
retValue
);
}
if (retValue = setcharset(str1)) {
fprintf(
stderr,
"Error %d from setcharset().\n",
retValue
);
}
if (retValue = strcreate_m(&str1, "aabbccabc")) {
fprintf(
stderr,
retValue
);
}
// create string with invalid char set
if (retValue = strcreate_m(&str1, "abbccdabc")) {
fprintf(
stderr,
retValue
);
}
Which we can compare with a more Bstrlib way of doing things:
bstring bCreateWithFilter (const char * cstr, const_bstring filter) {
bstring b = bfromcstr (cstr);
if (BSTR_ERR != bninchr (b, filter) && NULL != b) {
fprintf (stderr, "Filter violation.\n");
bdestroy (b);
b = NULL;
}
return b;
}
struct tagbstring charFilter = bsStatic ("abc");
bstring str1 = bCreateWithFilter ("aabbccabc", &charFilter);
bstring str2 = bCreateWithFilter ("aabbccdabc", &charFilter);
The first thing we should notice is that with the Bstrlib approach you can
have different filters for different strings if necessary. Furthermore,
selecting a charset filter in the Managed String Library is uni-contextual.
That is to say, there can only be one such filter active for the entire
program, which means its usage is not well defined for intermediate library
usage (a library that uses it will interfere with user code that uses it, and
vice versa.) It is also likely to be poorly defined in multi-threading
environments.
There is also a question as to whether the data sanitization filter is checked
on every operation, or just on creation operations. Since the charset can be
set arbitrarily at run time, it might be set *after* some managed strings have
been created. This would seem to imply that all functions should run this
additional check every time if there is an attempt to enforce this. This
would make things tremendously slow. On the other hand, if it is assumed that
only creates and other operations that take char *'s as input need be checked
because the charset was only supposed to be called once at and before any
other managed string was created, then one can see that its easy to cover
Bstrlib with equivalent functionality via a few wrapper calls such as the
example given above.
And finally we have to question the value of sanitation in the first place.
For example, for httpd servers, there is generally a requirement that the
URLs parsed have some form that avoids undesirable translation to local file
system filenames or resources. The problem is that the way URLs can be
encoded, it must be completely parsed and translated to know if it is using
certain invalid character combinations. That is to say, merely filtering
each character one at a time is not necessarily the right way to ensure that
a string has safe contents.
In the article that describes this proposal, it is claimed that it fairly
closely approximates the existing C API semantics. On this point we should
compare this "closeness" with Bstrlib:
Bstrlib Managed String Library
------- ----------------------
Pointer arithmetic Segment arithmetic N/A
Use in C Std lib ->data, or bdata{e} getstr_m(x,*) ... free(x)
String literals bsStatic, bsStaticBlk strcreate_m()
Transparency Complete None
Its pretty clear that the semantic mapping from C strings to Bstrlib is fairly
straightforward, and that in general semantic capabilities are the same or
superior in Bstrlib. On the other hand the Managed String Library is either
missing semantics or changes things fairly significantly.
Comparison with Annexia's c2lib library
---------------------------------------
This library is available at:
http://www.annexia.org/freeware/c2lib
1. Still based solely on char * buffers (and therefore strlen() and strcat()
is still O(n), and there are no faster streq() comparison functions.)
Their suggestion that alternatives which wrap the string data type (such as
bstring does) imposes a difficulty in interoperating with the C langauge's
ordinary C string library is not founded.
2. Introduction of memory (and vector?) abstractions imposes a learning
curve, and some kind of memory usage policy that is outside of the strings
themselves (and therefore must be maintained by the developer.)
3. The API is massive, and filled with all sorts of trivial (pjoin) and
controvertial (pmatch -- regular expression are not sufficiently
standardized, and there is a very large difference in performance between
compiled and non-compiled, REs) functions. Bstrlib takes a decidely
minimal approach -- none of the functionality in c2lib is difficult or
challenging to implement on top of Bstrlib (except the regex stuff, which
is going to be difficult, and controvertial no matter what.)
4. Understanding why c2lib is the way it is pretty much requires a working
knowledge of Perl. bstrlib requires only knowledge of the C string library
while providing just a very select few worthwhile extras.
5. It is attached to a lot of cruft like a matrix math library (that doesn't
include any functions for getting the determinant, eigenvectors,
eigenvalues, the matrix inverse, test for singularity, test for
orthogonality, a grahm schmit orthogonlization, LU decomposition ... I
mean why bother?)
Convincing a development house to use c2lib is likely quite difficult. It
introduces too much, while not being part of any kind of standards body. The
code must therefore be trusted, or maintained by those that use it. While
bstring offers nothing more on this front, since its so much smaller, covers
far less in terms of scope, and will typically improve string performance,
the barrier to usage should be much smaller.
Comparison with stralloc/qmail
------------------------------
More information about this library can be found here:
http://www.canonical.org/~kragen/stralloc.html or here:
http://cr.yp.to/lib/stralloc.html
1. Library is very very minimal. A little too minimal.
2. Untargetted source parameters are not declared const.
3. Slightly different expected emphasis (like _cats function which takes an
ordinary C string char buffer as a parameter.) Its clear that the
remainder of the C string library is still required to perform more
useful string operations.
The struct declaration for their string header is essentially the same as that
for bstring. But its clear that this was a quickly written hack whose goals
are clearly a subset of what Bstrlib supplies. For anyone who is served by
stralloc, Bstrlib is complete substitute that just adds more functionality.
stralloc actually uses the interesting policy that a NULL data pointer
indicates an empty string. In this way, non-static empty strings can be
declared without construction. This advantage is minimal, since static empty
bstrings can be declared inline without construction, and if the string needs
to be written to it should be constructed from an empty string (or its first
initializer) in any event.
wxString class
--------------
This is the string class used in the wxWindows project. A description of
wxString can be found here:
http://www.wxwindows.org/manuals/2.4.2/wx368.htm#wxstring
This C++ library is similar to CBString. However, it is littered with
trivial functions (IsAscii, UpperCase, RemoveLast etc.)
1. There is no C implementation.
2. The memory management strategy is to allocate a bounded fixed amount of
additional space on each resize, meaning that it does not have the
log_2(n) property that Bstrlib has (it will thrash very easily, cause
massive fragmentation in common heap implementations, and can easily be a
common source of performance problems).
3. The library uses a "copy on write" strategy, meaning that it has to deal
with multithreading problems.
Vstr
----
This is a highly orthogonal C string library with an emphasis on
networking/realtime programming. It can be found here:
http://www.and.org/vstr/
1. The convoluted internal structure does not contain a '\0' char * compatible
buffer, so interoperability with the C library a non-starter.
2. The API and implementation is very large (owing to its orthogonality) and
can lead to difficulty in understanding its exact functionality.
3. An obvious dependency on gnu tools (confusing make configure step)
4. Uses a reference counting system, meaning that it is not likely to be
thread safe.
The implementation has an extreme emphasis on performance for nontrivial
actions (adds, inserts and deletes are all constant or roughly O(#operations)
time) following the "zero copy" principle. This trades off performance of
trivial functions (character access, char buffer access/coersion, alias
detection) which becomes significantly slower, as well as incremental
accumulative costs for its searching/parsing functions. Whether or not Vstr
wins any particular performance benchmark will depend a lot on the benchmark,
but it should handily win on some, while losing dreadfully on others.
The learning curve for Vstr is very steep, and it doesn't come with any
obvious way to build for Windows or other platforms without gnu tools. At
least one mechanism (the iterator) introduces a new undefined scenario
(writing to a Vstr while iterating through it.) Vstr has a very large
footprint, and is very ambitious in its total functionality. Vstr has no C++
API.
Vstr usage requires context initialization via vstr_init() which must be run
in a thread-local context. Given the totally reference based architecture
this means that sharing Vstrings across threads is not well defined, or at
least not safe from race conditions. This API is clearly geared to the older
standard of fork() style multitasking in UNIX, and is not safely transportable
to modern shared memory multithreading available in Linux and Windows. There
is no portable external solution making the library thread safe (since it
requires a mutex around each Vstr context -- not each string.)
In the documentation for this library, a big deal is made of its self hosted
s(n)printf-like function. This is an issue for older compilers that don't
include vsnprintf(), but also an issue because Vstr has a slow conversion to
'\0' terminated char * mechanism. That is to say, using "%s" to format data
that originates from Vstr would be slow without some sort of native function
to do so. Bstrlib sidesteps the issue by relying on what snprintf-like
functionality does exist and having a high performance conversion to a char *
compatible string so that "%s" can be used directly.
Str Library
-----------
This is a fairly extensive string library, that includes full unicode support
and targetted at the goal of out performing MFC and STL. The architecture,
similarly to MFC's CStrings, is a copy on write reference counting mechanism.
http://www.utilitycode.com/str/default.aspx
1. Commercial.
2. C++ only.
This library, like Vstr, uses a ref counting system. There is only so deeply
I can analyze it, since I don't have a license for it. However, performance
improvements over MFC's and STL, doesn't seem like a sufficient reason to
move your source base to it. For example, in the future, Microsoft may
improve the performance CString.
It should be pointed out that performance testing of Bstrlib has indicated
that its relative performance advantage versus MFC's CString and STL's
std::string is at least as high as that for the Str library.
libmib astrings
---------------
A handful of functional extensions to the C library that add dynamic string
functionality.
http://www.mibsoftware.com/libmib/astring/
This package basically references strings through char ** pointers and assumes
they are pointing to the top of an allocated heap entry (or NULL, in which
case memory will be newly allocated from the heap.) So its still up to user
to mix and match the older C string functions with these functions whenever
pointer arithmetic is used (i.e., there is no leveraging of the type system
to assert semantic differences between references and base strings as Bstrlib
does since no new types are introduced.) Unlike Bstrlib, exact string length
meta data is not stored, thus requiring a strlen() call on *every* string
writing operation. The library is very small, covering only a handful of C's
functions.
While this is better than nothing, it is clearly slower than even the
standard C library, less safe and less functional than Bstrlib.
To explain the advantage of using libmib, their website shows an example of
how dangerous C code:
char buf[256];
char *pszExtraPath = ";/usr/local/bin";
strcpy(buf,getenv("PATH")); /* oops! could overrun! */
strcat(buf,pszExtraPath); /* Could overrun as well! */
printf("Checking...%s\n",buf); /* Some printfs overrun too! */
is avoided using libmib:
char *pasz = 0; /* Must initialize to 0 */
char *paszOut = 0;
char *pszExtraPath = ";/usr/local/bin";
if (!astrcpy(&pasz,getenv("PATH"))) /* malloc error */ exit(-1);
if (!astrcat(&pasz,pszExtraPath)) /* malloc error */ exit(-1);
/* Finally, a "limitless" printf! we can use */
asprintf(&paszOut,"Checking...%s\n",pasz);fputs(paszOut,stdout);
astrfree(&pasz); /* Can use free(pasz) also. */
astrfree(&paszOut);
However, compare this to Bstrlib:
bstring b, out;
bcatcstr (b = bfromcstr (getenv ("PATH")), ";/usr/local/bin");
out = bformat ("Checking...%s\n", bdatae (b, "<Out of memory>"));
/* if (out && b) */ fputs (bdatae (out, "<Out of memory>"), stdout);
bdestroy (b);
bdestroy (out);
Besides being shorter, we can see that error handling can be deferred right
to the very end. Also, unlike the above two versions, if getenv() returns
with NULL, the Bstrlib version will not exhibit undefined behavior.
Initialization starts with the relevant content rather than an extra
autoinitialization step.
libclc
------
An attempt to add to the standard C library with a number of common useful
functions, including additional string functions.
http://libclc.sourceforge.net/
1. Uses standard char * buffer, and adopts C 99's usage of "restrict" to pass
the responsibility to guard against aliasing to the programmer.
2. Adds no safety or memory management whatsoever.
3. Most of the supplied string functions are completely trivial.
The goals of libclc and Bstrlib are clearly quite different.
fireString
----------
http://firestuff.org/
1. Uses standard char * buffer, and adopts C 99's usage of "restrict" to pass
the responsibility to guard against aliasing to the programmer.
2. Mixes char * and length wrapped buffers (estr) functions, doubling the API
size, with safety limited to only half of the functions.
Firestring was originally just a wrapper of char * functionality with extra
length parameters. However, it has been augmented with the inclusion of the
estr type which has similar functionality to stralloc. But firestring does
not nearly cover the functional scope of Bstrlib.
Safe C String Library
---------------------
A library written for the purpose of increasing safety and power to C's string
handling capabilities.
http://www.zork.org/safestr/safestr.html
1. While the safestr_* functions are safe in of themselves, interoperating
with char * string has dangerous unsafe modes of operation.
2. The architecture of safestr's causes the base pointer to change. Thus,
its not practical/safe to store a safestr in multiple locations if any
single instance can be manipulated.
3. Dependent on an additional error handling library.
4. Uses reference counting, meaning that it is either not thread safe or
slow and not portable.
I think the idea of reallocating (and hence potentially changing) the base
pointer is a serious design flaw that is fatal to this architecture. True
safety is obtained by having automatic handling of all common scenarios
without creating implicit constraints on the user.
Because of its automatic temporary clean up system, it cannot use "const"
semantics on input arguments. Interesting anomolies such as:
safestr_t s, t;
s = safestr_replace (t = SAFESTR_TEMP ("This is a test"),
SAFESTR_TEMP (" "), SAFESTR_TEMP ("."));
/* t is now undefined. */
are possible. If one defines a function which takes a safestr_t as a
parameter, then the function would not know whether or not the safestr_t is
defined after it passes it to a safestr library function. The author
recommended method for working around this problem is to examine the
attributes of the safestr_t within the function which is to modify any of
its parameters and play games with its reference count. I think, therefore,
that the whole SAFESTR_TEMP idea is also fatally broken.
The library implements immutability, optional non-resizability, and a "trust"
flag. This trust flag is interesting, and suggests that applying any
arbitrary sequence of safestr_* function calls on any set of trusted strings
will result in a trusted string. It seems to me, however, that if one wanted
to implement a trusted string semantic, one might do so by actually creating
a different *type* and only implement the subset of string functions that are
deemed safe (i.e., user input would be excluded, for example.) This, in
essence, would allow the compiler to enforce trust propogation at compile
time rather than run time. Non-resizability is also interesting, however,
it seems marginal (i.e., to want a string that cannot be resized, yet can be
modified and yet where a fixed sized buffer is undesirable.)
===============================================================================
Examples
--------
Dumping a line numbered file:
FILE * fp;
int i, ret;
struct bstrList * lines;
struct tagbstring prefix = bsStatic ("-> ");
if (NULL != (fp = fopen ("bstrlib.txt", "rb"))) {
bstring b = bread ((bNread) fread, fp);
fclose (fp);
if (NULL != (lines = bsplit (b, '\n'))) {
for (i=0; i < lines->qty; i++) {
binsert (lines->entry[i], 0, &prefix, '?');
printf ("%04d: %s\n", i, bdatae (lines->entry[i], "NULL"));
}
bstrListDestroy (lines);
}
bdestroy (b);
}
For numerous other examples, see bstraux.c, bstraux.h and the example archive.
===============================================================================
License
-------
The Better String Library is available under either the 3 clause BSD license
(see the accompanying license.txt) or the Gnu Public License version 2 (see
the accompanying gpl.txt) at the option of the user.
===============================================================================
Acknowledgements
----------------
The following individuals have made significant contributions to the design
and testing of the Better String Library:
Bjorn Augestad
Clint Olsen
Darryl Bleau
Fabian Cenedese
Graham Wideman
Ignacio Burgueno
International Business Machines Corporation
Ira Mica
John Kortink
Manuel Woelker
Marcel van Kervinck
Michael Hsieh
Richard A. Smith
Simon Ekstrom
Wayne Scott
===============================================================================

Bstrlib

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bstrlib

Transféré par

Droits d'auteur :

Formats disponibles

Better String library

Vous aimerez peut-être aussi