About: C string handling is a research topic. Over the lifetime, 16 publications have been published within this topic receiving 231 citations. The topic is also known as: C string.
TL;DR: The proposed replacement functions, strlcpy() and strlcat(), address these problems by presenting an API designed for safe string copies, and guarantee NUL-termination, take as a length parameter the size of the string in bytes, and provide an easy way to detect truncation.
Abstract: As the prevalence of buffer overflow attacks has increased, more and more programmers are using size or length-bounded string functions such as strncpy() and strncat(). While this is certainly an encouraging trend, the standard C string functions generally used were not really designed for the task. This paper describes an alternate, intuitive, and consistent API designed with safe string copies in mind.
There are several problems encountered when strncpy() and strncat() are used as safe versions of strcpy() and strcat(). Both functions deal with NUL-termination and the length parameter in different and non-intuitive ways that confuse even experienced programmers. They also provide no easy way to detect when truncation occurs. Finally, strncpy() zero-fills the remainder of the destination string, incurring a performance penalty. Of all these issues, the confusion caused by the length parameters and the related issue of NUL-termination are most important. When we audited the OpenBSD source tree for potential security holes we found rampant misuse of strncpy() and strncat(). While not all of these resulted in exploitable security holes, they made it clear that the rules for using strncpy() and strncat() in safe string operations are widely misunderstood. The proposed replacement functions, strlcpy() and strlcat(), address these problems by presenting an API designed for safe string copies (see Figure 1 for function prototypes). Both functions guarantee NUL-termination, take as a length parameter the size of the string in bytes, and provide an easy way to detect truncation. Neither function zero-fills unused bytes in the destination.
TL;DR: In this article, the redundancy of displayed character strings is exploited using a string cache and string caching method, which stores the strings in a rendered form which for particular character strings and attributes and characteristics of the strings.
Abstract: Various character strings are repeatedly displayed on a graphics display. For example, strings such as "file", "edit", "view" and "help" are commonly displayed on nearly every screen. This redundancy of displayed character strings is exploited using a string cache and string caching method. A string cache stores a database of strings along with the rendered forms of the strings. The string cache stores the strings in a rendered form which for particular character strings and attributes and characteristics of the strings. The string cache is stored and accessed local to a graphics accelerator so that a single string request across a system bus activates the display of the entire string, including a display of the selected attributes and characteristics.
TL;DR: In this article, the character strings are extracted from the string definition files in a source language into intermediate text files, and then converted to the destination language of each intermediate text file.
Abstract: These systems and methods provide text displays, such as basic input/output system (“BIOS”) text displays, that are represented by character strings in string definition files. In order to convert character strings into multiple languages, destination languages are either user selected or predetermined based on the display specifications. Next, the character strings are extracted from the string definition files in a source language into intermediate text files. Each intermediate text file represents a destination language. The source language character strings are then converted to the destination language of each intermediate text file. The converted character strings are then inserted from the intermediate text files into the string definition files from which the character strings in the source language were extracted. A file identifier of each string definition file from which the character strings were extracted is also stored in the intermediate text files. When the converted character strings are inserted into the string definition files, the file identifiers are utilized to locate the string definition files from which the character strings in the source language were extracted.
TL;DR: A C++ template metaprogram library that provides the common string operations, like creating sub-strings, concatenation, replace, and similar is created, and both the performance improvements and extended functionality achieved in the applications of the Metastring library are presented.
Abstract: C++ template metaprogramming is an emerging direction of generative programming: with proper template definitions we can enforce the C++ compiler to execute algorithms at compilation time. Template metaprograms have become essential part of today's C++ programs of industrial size; they provide code adoptions, various optimizations, DSL embedding, etc. Besides the compilation time algorithms, template metaprogram data-structures are particularly important. From simple typelists to more advanced STL-like data types there are a variety of such constructs. Interesting enough, until recently string, as one of the most widely used data type of programming, has not been supported. Although, boost::mpl::string is an advance in this area, it still lacks the most fundamental string operations. In this paper, we analysed the possibilities of handling string objects at compilation time with a metastring library. We created a C++ template metaprogram library that provides the common string operations, like creating sub-strings, concatenation, replace, and similar. To provide real-life use-cases we implemented two applications on top of our Metastring library. One use case utilizes compilation time inspection of input in the domain of pattern matching algorithms, thus we are able to select the more optimal search method at compilation time. The other use-case implements safePrint, a type-safe version of printf - a widely investigated problem. We present both the performance improvements and extended functionality we have achieved in the applications of our Metastring library.
TL;DR: Z3strBV as mentioned in this paper is a quantifier-free string solver for C/C++ programs with string equations, string length represented as bit-vectors, and bit-vector arithmetic.
Abstract: We present the Z3strBV solver for a many-sorted first-order quantifier-free theory Tw, bv of string equations, string length represented as bit-vectors, and bit-vector arithmetic aimed at formal verification, automated testing, and security analysis of C/C++ applications. Our key motivation for building such a solver is the observation that existing string solvers are not efficient at modeling the combined theory over strings and bit-vectors. We demonstrate experimentally that Z3strBV is significantly more efficient than a reduction of string/bit-vector constraints to strings/natural numbers followed by a solver for strings/natural numbers or modeling strings as bit-vectors. We also propose two optimizations. First, we explore the concept of library-aware SMT solving, which fixes summaries in the SMT solver for string library functions such as strlen in C/C++. Z3strBV is able to consume these functions directly instead of re-analyzing the functions from scratch each time. Second, we experiment with a binary search heuristic that accelerates convergence on a consistent assignment of string lengths. We also show that Z3strBV is able to detect nontrivial overflows in real-world system-level code, as confirmed against seven security vulnerabilities from the CVE and Mozilla databases.