To conclude this our verdict is to always use the modern headers?
On Wed, Apr 14, 2021 at 3:13 PM Ahmad Samir <a.samir...@gmail.com> wrote: > > 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
