UPSTREAM PR #17243: server: fixing naming conflict res_error

[DajanaV]

Mirrored from ggml-org/llama.cpp#17243

Fix ggml-org/llama.cpp#17236

Conflict naming with res_error from resolv.h (used by httplib)

This is temporary fix before ggml-org/llama.cpp#17216 is merged

[loci-review]

Access the complete analysis in the LOCI Dashboard

Performance Analysis Summary: PR #195 - Server Error Function Rename

Overview

This pull request implements a straightforward naming conflict resolution by renaming res_error() to res_err() in the server module. The change affects 43 lines across HTTP error handling endpoints but involves no functional modifications.

Performance Impact Assessment

Condition 1 Applied: No meaningful performance changes detected. The analysis reveals negligible variations within measurement precision limits, with no impact on core inference functions.

Metrics Analysis

• Highest Response Time Change: std::vector<llm_bigram_spm>::pop_back() showed +0.10% increase (67 ns), representing normal measurement variance
• Throughput Changes: std::__detail::_Executor::_M_match_multiline() showed -0.11% variation (39 ns), within statistical noise
• Core Function Impact: Zero impact on critical inference functions (llama_decode, llama_encode, llama_tokenize) - no changes to tokenization or inference performance
• Tokens Per Second: No impact expected as inference pipeline functions remain unchanged

Power Consumption Analysis

Negligible energy efficiency changes across all binaries:

• libllama.so: 0.0003% decrease (280,854 nJ vs 280,855 nJ baseline)
• llama-cvector-generator: 0.0001% decrease
• All other binaries show zero measurable change
• Changes fall within measurement precision limits

Assembly-Level Analysis

• Flame Graph: Simple linear execution pattern for affected functions with no complexity changes
• CFG Comparison: Identical control flow graphs and assembly code between versions
• Root Cause: Performance variations stem from system-level factors rather than code modifications

Code Review Assessment

The GitHub analysis confirms this is a well-executed maintenance fix resolving a legitimate resolv.h naming conflict. The systematic renaming across all call sites maintains complete API compatibility while improving build reliability.

Conclusion

This change represents routine maintenance with zero functional or performance impact. The observed metric variations are within normal measurement variance and unrelated to the actual code modifications. The rename successfully resolves the build system conflict without affecting the inference pipeline or user-facing functionality.