meven added a comment.
In D20096#440921 <https://phabricator.kde.org/D20096#440921>, @fvogt wrote: > In D20096#440919 <https://phabricator.kde.org/D20096#440919>, @meven wrote: > > > > There are platforms out there which don't use glibc. So I suggest either handling ENOSYS properly by falling back to stat or erroring out if statx is supported but __GLIBC__ not defined. > > > > If the platform does not use glibc, `STATX_BASIC_STATS` will be false and statx won't be called, the other existing code path will be used. > > `STATX_BASIC_STATS` implies GLIBC and statx availability at least until other C standard libraries support it. > > > The "until" is the issue here - code that will knowingly break in the future is simply not acceptable. > > > So unless I am mistaken, I feel this is not a great concern. > > I would perhaps need to restrict when statx is used even when `STATX_BASIC_STATS` is defined to when __GLIBC__ is defined as well. > > Yes, please do that. Will do. And thinking again about the issue, could we have kio compiled with glibc but running on a system with musl for instance ? If it is possible, then I need to treat this case as you suggested to handle the runtime dependency on glibc. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D20096 To: meven, #frameworks, dfaure, fvogt, bruns, broulik Cc: pino, bcooksley, ngraham, kde-frameworks-devel, michaelh, bruns
