Including <cerrno> instead of <errno.h>, does it upset POSIX?

Albert Astals Cid aacid at kde.org
Wed Apr 14 21:20:29 BST 2021


El dimecres, 14 d’abril de 2021, a les 15:13:09 (CEST), Ahmad Samir va escriure:
> 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).

I honestly didn't think this would be a problem, but you say the build of some of them failed, so i guess it is :D

Could you link to the particular MR's that failed?

Cheers,
  Albert

> 
> 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








More information about the Kde-frameworks-devel mailing list