1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/security/sandbox/chromium/base/strings/string16.h Wed Dec 31 06:09:35 2014 +0100
1.3 @@ -0,0 +1,189 @@
1.4 +// Copyright 2013 The Chromium Authors. All rights reserved.
1.5 +// Use of this source code is governed by a BSD-style license that can be
1.6 +// found in the LICENSE file.
1.7 +
1.8 +#ifndef BASE_STRINGS_STRING16_H_
1.9 +#define BASE_STRINGS_STRING16_H_
1.10 +
1.11 +// WHAT:
1.12 +// A version of std::basic_string that provides 2-byte characters even when
1.13 +// wchar_t is not implemented as a 2-byte type. You can access this class as
1.14 +// string16. We also define char16, which string16 is based upon.
1.15 +//
1.16 +// WHY:
1.17 +// On Windows, wchar_t is 2 bytes, and it can conveniently handle UTF-16/UCS-2
1.18 +// data. Plenty of existing code operates on strings encoded as UTF-16.
1.19 +//
1.20 +// On many other platforms, sizeof(wchar_t) is 4 bytes by default. We can make
1.21 +// it 2 bytes by using the GCC flag -fshort-wchar. But then std::wstring fails
1.22 +// at run time, because it calls some functions (like wcslen) that come from
1.23 +// the system's native C library -- which was built with a 4-byte wchar_t!
1.24 +// It's wasteful to use 4-byte wchar_t strings to carry UTF-16 data, and it's
1.25 +// entirely improper on those systems where the encoding of wchar_t is defined
1.26 +// as UTF-32.
1.27 +//
1.28 +// Here, we define string16, which is similar to std::wstring but replaces all
1.29 +// libc functions with custom, 2-byte-char compatible routines. It is capable
1.30 +// of carrying UTF-16-encoded data.
1.31 +
1.32 +#include <stdio.h>
1.33 +#include <string>
1.34 +
1.35 +#include "base/base_export.h"
1.36 +#include "base/basictypes.h"
1.37 +
1.38 +#if defined(WCHAR_T_IS_UTF16)
1.39 +
1.40 +namespace base {
1.41 +
1.42 +typedef wchar_t char16;
1.43 +typedef std::wstring string16;
1.44 +typedef std::char_traits<wchar_t> string16_char_traits;
1.45 +
1.46 +} // namespace base
1.47 +
1.48 +#elif defined(WCHAR_T_IS_UTF32)
1.49 +
1.50 +namespace base {
1.51 +
1.52 +typedef uint16 char16;
1.53 +
1.54 +// char16 versions of the functions required by string16_char_traits; these
1.55 +// are based on the wide character functions of similar names ("w" or "wcs"
1.56 +// instead of "c16").
1.57 +BASE_EXPORT int c16memcmp(const char16* s1, const char16* s2, size_t n);
1.58 +BASE_EXPORT size_t c16len(const char16* s);
1.59 +BASE_EXPORT const char16* c16memchr(const char16* s, char16 c, size_t n);
1.60 +BASE_EXPORT char16* c16memmove(char16* s1, const char16* s2, size_t n);
1.61 +BASE_EXPORT char16* c16memcpy(char16* s1, const char16* s2, size_t n);
1.62 +BASE_EXPORT char16* c16memset(char16* s, char16 c, size_t n);
1.63 +
1.64 +struct string16_char_traits {
1.65 + typedef char16 char_type;
1.66 + typedef int int_type;
1.67 +
1.68 + // int_type needs to be able to hold each possible value of char_type, and in
1.69 + // addition, the distinct value of eof().
1.70 + COMPILE_ASSERT(sizeof(int_type) > sizeof(char_type), unexpected_type_width);
1.71 +
1.72 + typedef std::streamoff off_type;
1.73 + typedef mbstate_t state_type;
1.74 + typedef std::fpos<state_type> pos_type;
1.75 +
1.76 + static void assign(char_type& c1, const char_type& c2) {
1.77 + c1 = c2;
1.78 + }
1.79 +
1.80 + static bool eq(const char_type& c1, const char_type& c2) {
1.81 + return c1 == c2;
1.82 + }
1.83 + static bool lt(const char_type& c1, const char_type& c2) {
1.84 + return c1 < c2;
1.85 + }
1.86 +
1.87 + static int compare(const char_type* s1, const char_type* s2, size_t n) {
1.88 + return c16memcmp(s1, s2, n);
1.89 + }
1.90 +
1.91 + static size_t length(const char_type* s) {
1.92 + return c16len(s);
1.93 + }
1.94 +
1.95 + static const char_type* find(const char_type* s, size_t n,
1.96 + const char_type& a) {
1.97 + return c16memchr(s, a, n);
1.98 + }
1.99 +
1.100 + static char_type* move(char_type* s1, const char_type* s2, int_type n) {
1.101 + return c16memmove(s1, s2, n);
1.102 + }
1.103 +
1.104 + static char_type* copy(char_type* s1, const char_type* s2, size_t n) {
1.105 + return c16memcpy(s1, s2, n);
1.106 + }
1.107 +
1.108 + static char_type* assign(char_type* s, size_t n, char_type a) {
1.109 + return c16memset(s, a, n);
1.110 + }
1.111 +
1.112 + static int_type not_eof(const int_type& c) {
1.113 + return eq_int_type(c, eof()) ? 0 : c;
1.114 + }
1.115 +
1.116 + static char_type to_char_type(const int_type& c) {
1.117 + return char_type(c);
1.118 + }
1.119 +
1.120 + static int_type to_int_type(const char_type& c) {
1.121 + return int_type(c);
1.122 + }
1.123 +
1.124 + static bool eq_int_type(const int_type& c1, const int_type& c2) {
1.125 + return c1 == c2;
1.126 + }
1.127 +
1.128 + static int_type eof() {
1.129 + return static_cast<int_type>(EOF);
1.130 + }
1.131 +};
1.132 +
1.133 +typedef std::basic_string<char16, base::string16_char_traits> string16;
1.134 +
1.135 +BASE_EXPORT extern std::ostream& operator<<(std::ostream& out,
1.136 + const string16& str);
1.137 +
1.138 +// This is required by googletest to print a readable output on test failures.
1.139 +BASE_EXPORT extern void PrintTo(const string16& str, std::ostream* out);
1.140 +
1.141 +} // namespace base
1.142 +
1.143 +// The string class will be explicitly instantiated only once, in string16.cc.
1.144 +//
1.145 +// std::basic_string<> in GNU libstdc++ contains a static data member,
1.146 +// _S_empty_rep_storage, to represent empty strings. When an operation such
1.147 +// as assignment or destruction is performed on a string, causing its existing
1.148 +// data member to be invalidated, it must not be freed if this static data
1.149 +// member is being used. Otherwise, it counts as an attempt to free static
1.150 +// (and not allocated) data, which is a memory error.
1.151 +//
1.152 +// Generally, due to C++ template magic, _S_empty_rep_storage will be marked
1.153 +// as a coalesced symbol, meaning that the linker will combine multiple
1.154 +// instances into a single one when generating output.
1.155 +//
1.156 +// If a string class is used by multiple shared libraries, a problem occurs.
1.157 +// Each library will get its own copy of _S_empty_rep_storage. When strings
1.158 +// are passed across a library boundary for alteration or destruction, memory
1.159 +// errors will result. GNU libstdc++ contains a configuration option,
1.160 +// --enable-fully-dynamic-string (_GLIBCXX_FULLY_DYNAMIC_STRING), which
1.161 +// disables the static data member optimization, but it's a good optimization
1.162 +// and non-STL code is generally at the mercy of the system's STL
1.163 +// configuration. Fully-dynamic strings are not the default for GNU libstdc++
1.164 +// libstdc++ itself or for the libstdc++ installations on the systems we care
1.165 +// about, such as Mac OS X and relevant flavors of Linux.
1.166 +//
1.167 +// See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24196 .
1.168 +//
1.169 +// To avoid problems, string classes need to be explicitly instantiated only
1.170 +// once, in exactly one library. All other string users see it via an "extern"
1.171 +// declaration. This is precisely how GNU libstdc++ handles
1.172 +// std::basic_string<char> (string) and std::basic_string<wchar_t> (wstring).
1.173 +//
1.174 +// This also works around a Mac OS X linker bug in ld64-85.2.1 (Xcode 3.1.2),
1.175 +// in which the linker does not fully coalesce symbols when dead code
1.176 +// stripping is enabled. This bug causes the memory errors described above
1.177 +// to occur even when a std::basic_string<> does not cross shared library
1.178 +// boundaries, such as in statically-linked executables.
1.179 +//
1.180 +// TODO(mark): File this bug with Apple and update this note with a bug number.
1.181 +
1.182 +extern template
1.183 +class BASE_EXPORT std::basic_string<base::char16, base::string16_char_traits>;
1.184 +
1.185 +#endif // WCHAR_T_IS_UTF32
1.186 +
1.187 +// TODO(brettw) update users of string16 to use the namespace and remove
1.188 +// this "using".
1.189 +using base::char16;
1.190 +using base::string16;
1.191 +
1.192 +#endif // BASE_STRINGS_STRING16_H_
