xiaoxiang781216 commented on pull request #4193: URL: https://github.com/apache/incubator-nuttx/pull/4193#issuecomment-884291831
> Sent from my GalaxyPOSIX provides off64_t and a whole set of large file tile APIs for this. Off_t is traditionally 32 bits opengroup doesn't define off64_t and lseek64 related API. What's opengroup expect is: 1. typedef off_t to 32bit, the file size limit to 4GB 2. typedef off_t to 64bit, the file size has no limitation since opengroup only care about the source code compatibility, but not the binary compatibility. On the other hand, it's a hard requirement to keep the binary compatibility for all popular OS. So, these OS have to keep off_t as 32bit and add off64_t/lseek64. > > @patacongo I see https://www.opengroup.org/platform/lfs.html, but where is the API list you mention? > > I am not an LFS expert, but the Wikipedia article kind of explains things: https://en.wikipedia.org/wiki/Large-file_support . Basically, (1) a compiler option turned large file support on or off (selecting the 32-bit or 64-bit APIs) and (2) no one cares any more since 64-bit machines rule the desktop. > > Linux has O_LARGEFILE that can select when a file is opened. https://man7.org/linux/man-pages/man2/open.2.html Since NuttX never claim the binary compatibility as the goal, typedef off_t to int64_t is an clean and compliant implementation. The xxx64 macro just make libc more compatible with popular desktop OS: https://linux.die.net/man/3/lseek64 http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.lib_ref/topic/l/lseek.html > If off_t changes from anything but 32-bits, we also need to fix all file systems that expect off_t to be 32-bits in the binary meta-data of the file. These all need to be checked (and maybe others): > > ``` > fs/fat/ > fs/nxffs/ > fs/smartfs/ > fs/spiffs/ > fs/tmpfs/ > ``` > As I mention in the summary: 1. If the file system support 64bit file natively, we need review it's code to change all 32bit type to 64bit 2. If the file system doesn't support 64bit file, we don't need change anything here since it's impossible to generate a file > 4GB. > And possibly data structures in: > > ``` > include/nuttx/fs/dirent.h > include/nuttx/fs/loop.h > include/nuttx/fs/smart.h > include/nuttx/fs/userfs.h > ``` > > And this would need to be kept in sync: > > ``` > include/nuttx/fs/hostfs.h:typedef int32_t nuttx_off_t; > ``` I will review the general file sysem(e.g. hostfs and userfs) and update if needed. > > a compiler option turned large file support on or off (selecting the 32-bit or 64-bit APIs) > > You can see the old uClibc LFS support built in (or not) here: https://git.uclibc.org/uClibc/tree/libc/stdio/Makefile.in#n22 This design is to keep the binary compatibility, it isn't the goal of NuttX. But anyway, I add a new option FS_LARGEFILE which is similar to UCLIBC_HAS_LFS. > Another issue is that some of the older file system APIs do not use off_t but instead `long int` to represent file position. For example: > > ``` > stdio.h:long ftell(FAR FILE *stream); > stdio.h:off_t ftello(FAR FILE *stream); > ``` > > Also: > > ``` > stdio.h:int fseek(FAR FILE *stream, long int offset, int whence); > stdio.h:int fseeko(FAR FILE *stream, off_t offset, int whence); > ``` Yes, this is the design flaw and why the standard add ftello/fseeko, please see the below link: https://unix.org/version2/whatsnew/lfs20mar.html -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
