Hello :)
A week or so ago I created an MR to include <cerrno> instead of <errno.h> in
KIO[1].
From /usr/include/c++/10/cerrno:
/** @file cerrno
* This is a Standard C++ Library file. You should @c \#include this file
* in your programs, rather than any of the @a *.h implementation files.
*
* This is the C++ version of the Standard C Library header @c errno.h,
* and its contents are (mostly) the same as that header, but are all
* contained in the namespace @c std (except for names which are defined
* as macros in C).
*/
And then I made similar commits to a lot of the other Frameworks (not all, since the build failed
for some of them, so I left them alone).
Harald Sitter asked me to raise the point here, basically he's wondering whether this change might
cause issues, not being 100% POSIX compliant...etc; I'll quote him because he explained it much
better than I would:
<sitter> ahmadsamir:
https://invent.kde.org/frameworks/kcrash/-/commit/7a20755723dc1527edb7ed5c3fdcccdbcf7fa768 was this
ever discussed anywhere? cause there are others like this and my thinking up until now was that
using the C .h is more appropriate since we use them for POSIX APIs and from that POV the POSIX
specified header is errno.h
[...]
<sitter> might be worth raising for discussion on the mailing list. with c++>=14 there's a whole
mountain of "deprecated" headers OTOH I also recall reading that the c++ standard doesn't guarantee
compatibility
<sitter> which may or may not be a concern when we use stuff specifically with the expectation that
they will behave as documented from a POSIX or linux POV (such as signal safety in kcrash)
[1] https://invent.kde.org/frameworks/kio/-/merge_requests/397
--
Ahmad Samir
