Wierd fseek problem

[rozpruwacz]

I’m using CoreELEC 20.1 on S903X3. While I was trying to troubleshoot why I cannot play games on amiga uae emulator in hdf format I discovered very wierd fseek behaviour when calling with SEEK_END .

When fseek is called with SEEK_END (to find the file size) it returns error value - but actually the call was successfull.
libretro-uae/hardfile_unix.c at master · libretro/libretro-uae · GitHub line 299:

			ret = fseeko (h, 0, SEEK_END);
			if (ret)
				goto end;
                        low = ftello (h);

if I just comment out the ret value check the program go further and call to ftello returns correct value.

I found this issue also in commodore c64 vice emulator. What may be the cause ? Is it limited only to those two emulator addons ?

[vpeter]

I checked fseeko call and is working fine. So it must be something with this emulator code which is causing the issue.

[rozpruwacz]

ok, very very wierd … I created simple test file:

#include <stdio.h>
#include <errno.h>

int main() {
    int ret;
    FILE *h2 = fopen("some file", "r+b");
    ret = fseeko(h2, 0, SEEK_END);
    printf("TEST %d - err=%d\n", ret, errno);
}

I compiled it with exactly the same compile options as the puae addon (the only difference is the resulting binary is executable instead of shared lib). This test program runs as expected.
Then I put exaclty the same code into the puae emulator shared library and ran the addon. The result is very wierd. ret variable value (result of fseeko) is the opened file size ! and the errno is 2 (may be not related to the fseeko call ?)

[vpeter]

Where can I see source code of this emulator?

[rozpruwacz]

GitHub - libretro/libretro-uae: PUAE libretro commit 9f0f10d92cc83afa66d35d398b7af959bd4b90c5 file sources/src/hardfile_unix.c somwhere around line 300

EDIT: I fixed the commit hash, now is correct

[vpeter]

Is macro USE_LIBRETRO_VFS set when compiling? Because I see fseeko define here libretro-uae/sysconfig.h at master · libretro/libretro-uae · GitHub

[rozpruwacz]

yes, it defined:

/home/marek/Projekty/KODI/CoreELEC/build.CoreELEC-Amlogic-ng.arm-20/toolchain/bin/armv8a-libreelec-linux-gnueabihf-gcc -fPIC -march=armv8-a+crc -mtune=cortex-a53 -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mfloat-abi=hard -mfpu=neon-fp-armv8 -Wall -pipe  -O2 -fomit-frame-pointer -DNDEBUG -fcommon -DARM -marm -Wstringop-overflow=0 -Wno-unused-result -O3 -Wno-format -Wno-format-security -DHAVE_ZLIB -DHAVE_7ZIP -D_7ZIP_ST -std=gnu99 -DINLINE="inline" -D__LIBRETRO__ -MMD -DUSE_LIBRETRO_VFS -DWITH_MPEG2 -DWITH_CHD -DGIT_VERSION=\"" 4de8780457"\"   -I./sources/src -I./sources/src/include -I. -I./retrodep -I./deps/7zip -I./deps/libmpeg2/include -I./libretro -I./libretro-common/include -I./libretro-common/include/compat/zlib -I./deps/libchdr/include -c -o sources/src/hardfile_unix.o sources/src/hardfile_unix.c

[rozpruwacz]

I did test when my test program uses this macro and includes same headers as sources/src/hardfile_unix.c. And the test program works as expected.

[vpeter]

Maybe it is not used fseeko directly but something else. And the functionality is not the same.