UPSTREAM PR #29150: DOC: improve X509_VERIFY_PARAM_set_flags.pod

[DajanaV]

Mirrored from openssl/openssl#29150

Three doc-only commits carved out from #27357.

• Add recommendation that TLS clients should use SSL_set_tlsext_host_name() for SNI
  and that this should be done jointly with using {SSL,X509_VERIFY_PARAM}_{set1,add1}_host().
• fix doc of NULL param to X509_VERIFY_PARAM_set1_email() and X509_VERIFY_PARAM_set1{,_ip}()
• remove heavily outdated texts on X509_V_FLAG_NO_ALT_CHAINS; other small fixes

[loci-agentic-ai]

Access the complete analysis in the LOCI Dashboard

OpenSSL Performance Analysis Summary

Analysis Mismatch Identified

The performance analysis reveals a critical disconnect between the reported metrics and the actual code changes in PR #95. The performance data shows _vpaes_schedule_mangle (ARM AES assembly function) with the highest Response Time change (+0.076%, +0.28 ns), while the GitHub PR contains only documentation changes to X509_VERIFY_PARAM_set_flags.pod.

Performance Metrics Assessment

Highest Changes Detected:

• Response Time: _vpaes_schedule_mangle +0.076% (+0.28 ns)
• Throughput Time: BIO_ctrl_pending -0.108% (-0.019 ns)
• Power Consumption: 0.0% change across all binaries (libcrypto.so, libssl.so, openssl)

Technical Analysis:

• Flame Graph: Shows _vpaes_schedule_mangle as a simple leaf function with 367 ns execution time and no child calls
• CFG Comparison: Reveals functionally identical assembly code between versions with only timing variance (+0.28 ns in one basic block)
• Root Cause: Changes represent normal compiler optimization differences rather than functional modifications

Code Review Findings

PR #95 Content:

• Scope: Documentation-only changes (55 additions, 53 deletions)
• Changes: Parameter formatting standardization (B<> to I<>), RFC reference updates, NULL parameter clarification
• Impact: Zero functional or performance implications

Critical Issue: The performance metrics analyzed (version_id vs version_id_base) represent different commits than PR #95, indicating a tool configuration or versioning mismatch.

Conclusion

All detected performance changes are within measurement noise (<1 ns absolute change) and unrelated to the documentation-only PR. The +0.076% change in _vpaes_schedule_mangle represents normal compiler variance in ARM AES assembly optimization. No actionable performance recommendations are warranted as the changes are negligible in absolute terms and the PR contains no functional code modifications.

Recommendation: Investigate the version mapping between performance analysis tools and GitHub PR tracking to ensure accurate correlation of metrics with actual code changes.