Hidden API functions

[JayFoxRox]

There appear to be non-static functions which are prefixed with XbSymbolDatabase, but aren't actually listed as part of the XbSymbolDatabase.h:

XbSymbolDatabase/XbSymbolDatabase.c

Line 1768 in 6820d3f

unsigned int XbSymbolDataBaseVerifyEntry(SymbolDatabaseVerifyContext *context, const OOVPATable *table, uint32_t index)

XbSymbolDatabase/XbSymbolDatabase.c

Line 1783 in 6820d3f

unsigned int XbSymbolDataBaseVerifyDatabase(SymbolDatabaseVerifyContext *context, SymbolDatabaseList *data)

...

---

Are they unit tests / utils? Shouldn't they be in a separate file and only compiled on demand?

Should these be removed, prefix-removed, or listed in the header?

Affects #77 as we have to decide wether they have to remain non-static.

[RadWolfie]

NOTICE: All export functions should start with XbSymbol. from #3

XbSymbolDataBase are only used internally.

[JayFoxRox]

But XbSymbolDataBase starts with XbSymbol.. this is a very very poor design choice (that should be fixed).

[ergo720]

The APIs could use the prefix XbSBD (which is already being used here in libXbSymbolDatabase.h + it's shorter to type), and the internal functions could use the prefix XbSBDi, where the "i" would stand for "internal".

[JayFoxRox]

That still (potentially) has the same problem? The prefix shouldn't be able to overlap; why do internal functions need a prefix anyway?

[RadWolfie]

Not really the same problem, but adding a letter i will separate the difference from a public prefix usage. It's common in Windows/Xbox development where they add i or p after the prefix of the type of library's intended purpose.
i.e. ObpObjectHandleTable is a private variable (yet somehow is exposed to kernel export?) vs ObOpenObjectByName is a public function. The difference is private variable has the letter p after Ob prefix.

Hopefully, the explanation will clarify the reasons we're doing this way.