diff options
author | Evgeny Grin (Karlson2k) <k2k@narod.ru> | 2024-04-30 01:09:07 +0200 |
---|---|---|
committer | Evgeny Grin (Karlson2k) <k2k@narod.ru> | 2024-04-30 01:09:07 +0200 |
commit | d079bc5649a6de5b306a1b73c1f17187782f88fc (patch) | |
tree | 10f9ef349d86c11a1610bd4852c383d18c4ffd3b | |
parent | 6646ce83fecafedd8a264ec95e8eb064b5258957 (diff) | |
download | libmicrohttpd-m1g.tar.gz libmicrohttpd-m1g.zip |
This API is TERRIBLE.m1g
The header requires fixes.
The testing of other parts is not possible without fixes.
-rw-r--r-- | src/include/this_API_is_TERRIBLE.txt | 86 |
1 files changed, 86 insertions, 0 deletions
diff --git a/src/include/this_API_is_TERRIBLE.txt b/src/include/this_API_is_TERRIBLE.txt new file mode 100644 index 00000000..07a6280a --- /dev/null +++ b/src/include/this_API_is_TERRIBLE.txt | |||
@@ -0,0 +1,86 @@ | |||
1 | - The header is NOT readable: | ||
2 | -- Having the **third** version of the every type of options ("documenting...") | ||
3 | makes reading even worse. Absolutely unclear *why* the reader should treat | ||
4 | the excluded code as an actual code. Not clear how it is supposed to work. | ||
5 | I hardly believe that many readers will just blindly follow disabled part | ||
6 | of the header. In practice it would be the opposite: many readers just | ||
7 | ignore disabled parts of the headers (as IDEs gray-out or even hide them). | ||
8 | -- IDEs will be cryptic as well when decoding hierarchical macros (the options | ||
9 | itself, then macros that set the options). | ||
10 | -- IDEs will not point to "generated ... documenting", when one would try | ||
11 | to follow the definition/declaration | ||
12 | -- Trying to "grep" for the keyword (as previously suggested way to find the | ||
13 | declaration) is giving too many false results. This makes understanding | ||
14 | even more complicated and even less straightforward. | ||
15 | -- '#include "microhttpd2_generated_daemon_options.h"' is far from "generated | ||
16 | code documenting..." | ||
17 | -- All macros that switching from "static inline" to macros with compound | ||
18 | literals are not clear for the user. Even right now it is not clear how | ||
19 | they are supposed to work. Not clear that one form is used for C compilers, | ||
20 | while another form is used for C++ compilers (and, actually, the third | ||
21 | possible version, for not compatible compilers, for C89, and before C++11 | ||
22 | however it is not the largest concern). It is not clear that app code is | ||
23 | supposed to look the same in both C and C++. Actually, even with modern | ||
24 | compilers (and language version) there are three possible combinations: | ||
25 | - macros for option with macro to make an array (C), | ||
26 | - static functions for options with macro to make an array (C++ with clang), | ||
27 | - static functions with vector (C++ in general). | ||
28 | And this is repeated for every section with the options. | ||
29 | -- Functions with ALL CAPS are hard to read. ALL CAPS are usually macros. | ||
30 | |||
31 | It is supposed to make the header maintainable so someone may take care about | ||
32 | it later. BUT | ||
33 | - The header is hardly maintainable: | ||
34 | -- The structure of generated parts, static parts, databases and the build | ||
35 | system is not obvious at all. You need to dig very deep just to understand | ||
36 | now to start modifying it. It is NOT a good design. | ||
37 | The worst thing that actually the current version is not good enough for | ||
38 | the production. The production version has to be even more complicated, | ||
39 | which makes it even less maintainable. | ||
40 | -- Simple question: what if it will be needed to change the formatting of | ||
41 | header? Which file should I edit? Is it obvious? For example, change | ||
42 | the indent. | ||
43 | -- Adding new type of settings (for example, for the stream) is complicated | ||
44 | and multiply already large number of input files. | ||
45 | -- It is always not nice that relatively often modifiable file (the main | ||
46 | header) cannot be modified directly. Every time when I change something | ||
47 | in the main header, I have to run the build system before starting using | ||
48 | the new header. This may require update of the generated makefiles or re-run | ||
49 | the configure. Currently re-run of configure takes 6 minutes on W32. | ||
50 | With the additional checks for build host compilers (and other new checks) | ||
51 | it will be even longer. So, more then 6 minutes after edit of some part | ||
52 | of the header before getting the result. No efficient at all! | ||
53 | |||
54 | - The build system for the header is broken currently. | ||
55 | -- Need to add the section to the configure for the build compilers, document | ||
56 | additional parameters, pass them correctly to makefiles, make custom build | ||
57 | rules for binaries for build host (libtool cannot be used), make everything | ||
58 | similar to rules for target host | ||
59 | -- Need to fix makefiles for out-of-tree builds | ||
60 | -- Need to fix makefiles for parallel builds (this is not easy! check the "po" | ||
61 | part) | ||
62 | -- Need to fix the generator itself. Currently it is not POSIX, using | ||
63 | unportable extensions. Need to make it with proper memory handling and | ||
64 | correct checking for all errors. "It works fast" will not be an excuse for | ||
65 | security audits. It sounds like "I'll commit a crime, but I'll do it very | ||
66 | quickly, so it will not be a crime". Memory leaks are not acceptable for | ||
67 | proper design, even on developers machines. | ||
68 | I expect also many reports from users that use any kind of "sanitizers" or | ||
69 | analysers that immaculately report tons of problems. | ||
70 | In short: we cannot afford this code in our repo. | ||
71 | -- More inputs requires more checks to keep them in sync. More test, more | ||
72 | makefile rules, more problems with "make distcheck". | ||
73 | -- All these fixes makes build system even more complicated, even less obvious, | ||
74 | even less readable, even harder maintainable. Problems will be multiplied | ||
75 | with additional types of the settings. | ||
76 | |||
77 | ! Errors: struct MHD_responseOptionAndValue vs struct MHD_ResponseOptionAndValue | ||
78 | ! Errors: struct MHD_daemonOptionAndValue vs struct MHD_DaemonOptionAndValue | ||
79 | ! Errors: Doxy lines are too long. | ||
80 | ! Errors: Some doxy lines are broken (do not start with " *") | ||
81 | ! Errors: Several "@param"s are in single doxy line | ||
82 | ! Wrong: The body of some static functions with single parameter are formed as macros | ||
83 | |||
84 | Positive: | ||
85 | + The excluded "portability" macros is fine (actually, the excluded part is | ||
86 | not about the portability only) | ||