[FR] Large File Support #1725
Comments
|
(I can work on this.) |
This should fix google#1725
This should fix google#1725
|
have you seen this issue anywhere? |
|
LFS isn't just about reading the content of large files. inodes can be 64-bit which means any attempt to stat will fail too. and that can be tricky to reproduce as it's up to the underlying filesystem whether/when it returns an inode # that doesn't fit into 32-bits. enabling LFS costs basically nothing. i'll also note that in order to support 64-bit time_t, you'll need to enable LFS eventually anyways. |
This should fix google#1725
|
Thanks @vapier for clearer information and sorry for my initial vague arguments. IIUC, for 64-bit |
|
let's keep the two separate for now. LFS has been around for a long time and should be easy enough. 64-bit time_t is a newer project and still semi-influx. |
* Enable Large-file Support This should fix #1725 * Use whitespaces instead of tab in BUILD.bazel --------- Co-authored-by: dominic <510002+dmah42@users.noreply.github.com>
Follow up of google#1725. `defines` propagates to reverse dependencies, while `local_defines` don't. If we use `defines` then there's risk of ODR violation: Suppose a user have a cc_library foo that depends on bar and benchmark: cc_library(name = "foo", deps = [":bar", "@com_github_google_benchmark//:benchmark"]) And bar has a class that has LFS-dependant ABI: cc_library(name = "foo") class Bar { off_t member; }; Bar would be compiled without LFS, but linked to foo when assuming LFS is enabled. So we limit LFS to within the library only. benchmark does not have LFS dependant public ABIs so it should be fine.
Follow up of #1725. `defines` propagates to reverse dependencies, while `local_defines` don't. If we use `defines` then there's risk of ODR violation: Suppose a user have a cc_library foo that depends on bar and benchmark: cc_library(name = "foo", deps = [":bar", "@com_github_google_benchmark//:benchmark"]) And bar has a class that has LFS-dependant ABI: cc_library(name = "foo") class Bar { off_t member; }; Bar would be compiled without LFS, but linked to foo when assuming LFS is enabled. So we limit LFS to within the library only. benchmark does not have LFS dependant public ABIs so it should be fine.
Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Google benchmark looks to be using libc functions like
fseeko,ftello,fopen. (IIUC, std::ifstream may results in using these functions.)On some "small" platforms, it might result in EOVERFLOW when dealing with large files.
Describe the solution you'd like
A clear and concise description of what you want to happen.
Compiles with these three flags enabled:
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE.this is the portable/POSIX method for transparently using 64bit types everywhere. for details on each define, see:
# http://www.gnu.org/s/libc/manual/html_node/Feature-Test-Macros.html
# _LARGEFILE_SOURCE: enable support for new LFS funcs (ftello/etc...)
# _LARGEFILE64_SOURCE: enable support for 64bit variants (off64_t/fseeko64/etc...)
# _FILE_OFFSET_BITS: default to 64bit variants (off_t is defined as off64_t)
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
N/A
Additional context
Add any other context or screenshots about the feature request here.
https://issuetracker.google.com/issues/201531268
The text was updated successfully, but these errors were encountered: