fvogt added a comment.
In D20096#440919 <https://phabricator.kde.org/D20096#440919>, @meven wrote: > In D20096#440868 <https://phabricator.kde.org/D20096#440868>, @fvogt wrote: > > > In D20096#440842 <https://phabricator.kde.org/D20096#440842>, @meven wrote: > > > > > In D20096#440830 <https://phabricator.kde.org/D20096#440830>, @pino wrote: > > > > > > > Note that, even if the system supports statx() (so with glibc >= 2.28), you must support systems without it at runtime anyway: for example, if you boot with a kernel older than 4.11 (which IIRC is the version where the syscall was added) then the glibc function will return ENOSYS (IIRC, better check). This can happen for example in containers: you boot a Debian testing container (so with glibc 2.28) on a Debian stable system (with Linux 4.9). > > > > > > > > > This case is covered by glibc https://github.com/lattera/glibc/blob/895ef79e04a953cac1493863bcae29ad85657ee1/sysdeps/unix/sysv/linux/statx.c > > > In case the syscall does not exist, glibc provides a generic implementation based on stat. > > > > > > 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. 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
