haiku/headers/cpp
Oliver Tappe 967294dbd8 * Turns out that the "upper" half of the old (gcc2) libio - the C++ classes -
keeps its own idea about what a wchar_t is and that was still a short.
  This of course made the data structure of a streambuf incompatible with the
  "lower" half - the glibc part - causing (potentially all sorts of) crashes
  when these classes were used.
  This should fix the crash of gensyscalls when building haiku natively
  on a gcc2-haiku.

git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@31462 a95241bf-73f2-0310-859d-f6bbb57e9c96
2009-07-08 16:31:01 +00:00
..
std
algo.h
algobase.h
algorithm
alloc.h
bitset
builtinbuf.h
bvector.h
cassert
cctype
cerrno
cfloat
ciso646
climits
clocale
cmath
complex
complex.h
csetjmp
csignal
cstdarg
cstddef
cstdio
cstdlib
cstring
ctime
cwchar
cwctype
defalloc.h
deque
deque.h
editbuf.h
floatio.h
fstream
fstream.h
function.h
functional
hash_map
hash_map.h
hash_set
hash_set.h
hashtable.h
heap.h
indstream.h
iomanip
iomanip.h
iosfwd
iostdio.h
iostream
iostream.h
istream.h
iterator
iterator.h
list
list.h
map
map.h
memory
multimap.h
multiset.h
numeric
ostream.h
pair.h
parsestream.h
pfstream.h
PlotFile.h
procbuf.h
pthread_alloc
pthread_alloc.h
queue
rope
rope.h
ropeimpl.h
set
set.h
SFile.h
slist
slist.h
sstream
stack
stack.h
stdexcept
stdiostream.h
stl_algo.h
stl_algobase.h
stl_alloc.h
stl_bvector.h
stl_config.h
stl_construct.h
stl_deque.h
stl_function.h
stl_hash_fun.h
stl_hash_map.h
stl_hash_set.h
stl_hashtable.h
stl_heap.h
stl_iterator.h
stl_list.h
stl_map.h
stl_multimap.h
stl_multiset.h
stl_numeric.h
stl_pair.h
stl_queue.h
stl_raw_storage_iter.h
stl_relops.h
stl_rope.h
stl_set.h
stl_slist.h
stl_stack.h
stl_tempbuf.h
stl_tree.h
stl_uninitialized.h
stl_vector.h
stl.h
stream.h
streambuf.h * Turns out that the "upper" half of the old (gcc2) libio - the C++ classes - 2009-07-08 16:31:01 +00:00
strfile.h
string
strstream
strstream.h
tempbuf.h
tree.h
type_traits.h
utility
valarray
vector
vector.h