libatalk: map logtype identifiers correctly with the enum#2898
libatalk: map logtype identifiers correctly with the enum#2898
Conversation
🤖 Augment PR SummarySummary: Fixes a long-standing off-by-two mismatch between the 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
ATalkDaemon and PAPDaemon were present in the enum but absent from the string identifier array, shifting every entry from UAMS onward by -2. As a result, f.e. "spotlight:debug" in afp.conf resolved to logtype_fce (index 8) rather than logtype_sl (index 10), so Spotlight debug logging could never be enabled via the config file. Add the two missing entries to restore correct alignment, while correcting man page documentation; this has probably been broken ever since we grafted AppleTalk onto v4.0.
The bound check in setuplog_internal() compared typenum against num_logtype_strings, which includes the sentinel "end_of_list_marker" entry. This allowed typenum == logtype_end_of_list_marker (11) to pass the guard and index type_configs[] out of bounds (sized for indices 0-10). Fix by comparing against logtype_end_of_list_marker directly, which is the actual size of type_configs[].
rdmark
force-pushed
the
rdmark-logging-enum
branch
from
5ea87cb to
a5c6c4d
Compare
|
🔥 Spectest (AFP 3.4) - Flamegraph (AFP_ASSERT active)Commit: 🔥 Open interactive Flamegraph (SVG) 🔝 Top 10 leaf functions
|
|
I noticed it when desperately trying and failing to enable spotlight debug logging 😅 |
2 participants
ATalkDaemon and PAPDaemon were present in the enum but absent from the string identifier array, shifting every entry from UAMS onward by -2. As a result, f.e. "spotlight:debug" in afp.conf resolved to logtype_fce (index 8) rather than logtype_sl (index 10), so Spotlight debug logging could never be enabled via the config file.
Add the two missing entries to restore correct alignment, while correcting man page documentation; this has
probably been broken ever since we grafted AppleTalk onto v4.0.
Also: fix OOB access when "end_of_list_marker" is passed as logtype
The bound check in setuplog_internal() compared typenum against num_logtype_strings, which includes the sentinel "end_of_list_marker" entry. This allowed typenum == logtype_end_of_list_marker (11) to pass the guard and index type_configs[] out of bounds (sized for indices 0-10).
Fix by comparing against logtype_end_of_list_marker directly, which is the actual size of type_configs[].