D20096: Fill UDSEntry::UDS_CREATION_TIME under linux when glibc >= 2.28
Méven Car
noreply at phabricator.kde.org
Sun Mar 31 12:30:23 BST 2019
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190331/528267ca/attachment.html>
More information about the Kde-frameworks-devel
mailing list