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
