The library will work with the small size, but if your offset is so large that you exceed the 32 bit size limit for offset value you can't see the whole .g file.
If I remember correctly, off_t getting redefined allows for successful work with larger files. Given a sufficiently large .g file it should be possible to observe the behavior change, although I haven't tried it with VS2019. CY P.S. - it's probably worth updating rt^3 to the just-tagged 7.30.6, if it works - 7.30.4 has a significant bug in the NURBS raytracing. On Thu, Mar 19, 2020 at 9:01 AM Daniel Roßberg <[email protected]> wrote: > Okay, thanks Clifford. > What I don't understand is, how the redefinition of off_t helped in this > issue. The C library should still work with the small size. On the other > hand, _stati64 is used there, but this redefinition may lead to an infinite > recursion in fstat() (depending on the type/implementation details of the C > library used) ... > > At least, I know now where to look. > > Thank you, > Daniel > > > Am Do., 19. März 2020 um 13:02 Uhr schrieb Clifford Yapp < > [email protected]>: > >> If I remember correctly, at least some versions of Visual Studio have an >> off_t that is 32 bit even on a 64 bit machine: >> >> >> https://developercommunity.visualstudio.com/content/problem/308714/in-c-header-systypesh-off-t-is-defined-as-32-bit-s.html >> >> The acid test is to go with the default off_t and create a .g file that >> is too large to work with without a 64 bit off_t. (I don't recall offhand >> which operations fail - I would expect "ls" to since it's supposed to find >> everything.) >> >> >> On Thu, Mar 19, 2020 at 6:15 AM Daniel Roßberg <[email protected]> >> wrote: >> >>> Hi, >>> >>> What's the background behind the OFF_T_SIZE_MISMATCH stuff in common.h? >>> Is this relevant for MS Visual Studio only? >>> >>> I came across this while investigating a strange behavior in VS2019. >>> There I saw different sizes of off_t in BRL-CAD, because of the typedefs >>> there, and the C library, which doesn't know about common.h. >>> >>> For VS2019, it looks like these lines could simply be omitted. >>> >>> Regards, >>> Daniel >>> _______________________________________________ >>> BRL-CAD Developer mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >>> >> _______________________________________________ >> BRL-CAD Developer mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel >
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
