Notice that whereas JString had a const char* operator for automatic or forced conversion, Firebird::string doesn't have one. Worse, the layout of FBString has a static buffer of size 32 but can allocate a dynamic buffer for larger requirements and therefore, casting FBString to char* or const char* will most likely produce wrong behavior or crash. Thereforer, I removed the places with such explicit cast. Alex, please watch if there are more problems of this type in IntlManager.cpp, the "config" dir or the "vulcan" dir.
2.- Cleanup.
3.- Put enumerations and plain structures in their due classes, checked constness, commented or deleted unused crap (watch stupid macros in header files that pollute all the files where such headers are included), etc.
There's a lot of pending work to do. Still trying to convert to decent C++ this barbarian code probably written by Genghis Khan or Attila the Hun.
2.- Cleanup.
3.- Put a compilation warning on DirectoryList::matchFileName because the function's purpose only can be guessed: it returns true unconditionally. Maybe it was expected to tell us if a file name matched a directory name or querying the operating system to know whether the file existed inside the given directory name. Anyway, since it does nothing useful, DirectoryList::validateFilename is suspicious, too, since it uses the former in a loop.
2.- Cleanup.
3.- Mark a disastrous condition in Stream::allocSegment in DEBUG mode at least so it can be detected: potentially negative argument to
new char[<number>] if the caller of the function doesn't do what's expected by this function.
4.- Now that the weed JString was eradicated, rename Stream::getJString to getFBString and put an assertion to verify the initial assumption (in the worst case, it could be a buffer overrun).
5.- Fix a deallocation bug (probable heap corruption) in Stream::truncate because delete[] should be used instead of plain delete.
Generally speaking, the code inherited from Vulcan is so weak that expects the caller to know the internal logic of the callee to do the right thing to avoid crashing the callee. This is a general problem with the files in the "config" dir.
2.- Cleanup.
3.- Fix an invalid memory access when returning data member belonging to an object from the stack in
ConfObject::getConcatenatedValues. I didn't see a runtime error because I don't use the feature, but reading the code is enough.
2.- Cleanup.
3.- Fix what I assume may cause astray behavior. Only an inept could create an enumeration in Lex.h like this
enum TokenType {
END_OF_STREAM,
PUNCT,
NAME,
to be used in the data member tokenType but at the same time, create preprocessor macros like this
#define WHITE 1
#define PUNCT 2
to be stored and retrieved by
char charTableArray [256]
to calculate the character class (punctuation, spaces, etc) in the Lexer,
where the macro PUNCT (value 2) overrides the enum member PUNCT (value 1) and that inconsistent value is used in both tasks, causing PUNCT to be interpreted as tokenType being NAME (value 2 in the enum). Since this module has several bugs, maybe all the bugs cancel among themselves and all works as expected, but it would be pure luck.
