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