With the new result API, source files only need to include
<isc/result.h> to have isc_result_(totext|toid) functions available and
able to handle different library results, isc, isccc, dst and so on...
To allow for that, a new structure for defining result codes per library
was employed, it is implemented as follow:
- Suppose a new library called "foo" is being added to BIND.
- Two source files must be added to <BIND_ROOT>/lib/foo/:
result_foo.h.in: The header file defines result codes that may be
returned by functions within the library.
result_foo.c.in: The source file define two string arrays, used for
conversion between library result codes and their string
representation, the array <libname>_result_descriptions define a
comphreensive description of a given result code, while
<libname>_result_ids is a 1:1 result code to string.
On top of this structure, during the build phase all
lib/*/result_<libname>.c.in files will be concatenated to a file named
lib/isc/result_ext.c, which will be included by lib/isc/result.c, so
all the symbols will be available during compile time, thus making the
use of locking to manage the table of result codes not necessary
anymore.
In the same fashion, during the build phase all
lib/*/result_<libname>.h.in files will be concatenated to a file named
lib/isc/include/isc/result_ext.h, which will be included by
lib/isc/include/isc/result.h, thus exporting all error codes of all
libraries in a unified way.
The code for automatically generating such files will be added in the
subsequent commit.
Note: result codes from lib/dns/include/dns/result.h were moved to a new
file: lib/dns/result_dns.h.in, the dns/result.h file was kept since it
defines an extra function 'dns_result_torcode' that is implemented in
lib/dns/result.c, similary, string tables with dns result codes were
moved from lib/dns/result.c to lib/dns/result_dns.c.in to follow the new
result code API structure.
Diego Fronza
a88bb45b0a