From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: yunqiang.su@cipunited.com, libc-alpha@sourceware.org
Cc: aurelien@aurel32.net, jiaxun.yang@flygoat.com, macro@orcam.me.uk
Subject: Re: 回复: 回复: [PATCH] MIPS: fix y2106 problem on N64 with statx
Date: Thu, 18 Mar 2021 09:17:12 -0300 [thread overview]
Message-ID: <189840a9-674a-f752-d222-e303ad1354f5@linaro.org> (raw)
In-Reply-To: <000401d71bbc$c30ba1c0$4922e540$@cipunited.com>
On 18/03/2021 03:05, yunqiang.su@cipunited.com wrote:
>
>
>> -----邮件原件-----
>> 发件人: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>> 发送时间: 2021年3月17日 19:27
>> 收件人: yunqiang.su@cipunited.com; libc-alpha@sourceware.org
>> 抄送: aurelien@aurel32.net; jiaxun.yang@flygoat.com; macro@orcam.me.uk
>> 主题: Re: 回复: [PATCH] MIPS: fix y2106 problem on N64 with statx
>>
>> Even though it is not the default, non LFS interface are legacy ones.
>> y2038 support, for instance, is only supported with LFS interfaces.
>>
>> So it is up to you if you want to fix on fstatat.c, it should also fix the s390 issue
>> with missing nanosecond support.
>>
>
> fstatat is not recommend used by any new write code?
> All new write code should use fstatat64?
It is an implementation detail in fact, glibc fstatat64 is the
interface with LFS support. On ABIs with default LFS support it does
matter whether you use fstatat or fstatat64 (fstatat is fact an alias
to fstatat64).
On ABIs with LFS support (most of legacy 32-bits and some of 64-bit)
fstatat is used as default and fstatat64 is used as an asm alias if
_FILE_OFFSET_BITS=64 is defined or provided in the namespace if
_LARGEFILE64_SOURCE is defined.
I think we should now make LFS as default [1], at least for legacy
32-bit ABIs even though they are still namespace issues [2] [3].
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=13047
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=14106
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=15766
next prev parent reply other threads:[~2021-03-18 12:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 3:49 YunQiang Su
2021-03-12 12:34 ` Adhemerval Zanella
2021-03-17 7:25 ` 回复: " yunqiang.su
2021-03-17 11:27 ` Adhemerval Zanella
2021-03-18 6:05 ` 回复: " yunqiang.su
2021-03-18 12:17 ` Adhemerval Zanella [this message]
2021-03-19 1:00 ` 回复: " yunqiang.su
2021-03-17 22:28 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=189840a9-674a-f752-d222-e303ad1354f5@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=aurelien@aurel32.net \
--cc=jiaxun.yang@flygoat.com \
--cc=libc-alpha@sourceware.org \
--cc=macro@orcam.me.uk \
--cc=yunqiang.su@cipunited.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).