translated sdl.zig file is incorrectly big-endian

[rohlem]

trafficstars

Not sure why this is happening, but the src/binding/sdl.zig looks like it assumes big endian.

Symptoms (the ones I've found, I'm kind of new to SDL though, there might be more):

• Audio formats AUDIO_{U,S,F}{16,32}SYS should alias the native byte ordering, but they alias MSB instead of LSB constants.
• SDL_Swap{LE,BE}{16,32,64} and SDL_SwapFloat{LE,BE} should be no-op for native ordering and only swap for foreign ordering, again it's reversed.

These are observable in the current master branch, it's the same when locally regenerated on my x86_64 (little-endian) windows machine.

---

Not sure if it's the same issue, but notably, my file also contains some definitions that identify it as a windows instead of a linux build (SDL_SENSOR_WINDOWS, missing the SDL_HAPTIC_LINUX constant from master). This is despite the -target x86_64-linux-gnu flag given to the zig translate-c invocation in gen_sdl.sh. So is that being ignored, or overruled in some strange way?

[rohlem]

Looking into it, it seems like the empty stubs/endian.h file overriding the compiler-provided target-specific file is probably the cause of this.

An alternative would be to remove the stub files, and add -lc to translate-c. The downside is that the generated file grows to 22k lines, with all the standard C symbols. That seems the more sane default to me, but I assume you'll have your reasons to choose this manual patching method instead.

[ikskuh]

Thanks for info!

Yeah, i have very good reasons to do this, and i know of the shortcomings of this method. My goal is to ultimativley not depend on SDL headers anymore and just use the (hand-translated) file with the correct semantics instead.

This allows us to have nicer types, correct usage of enums, and only the SDL2 API in there. If you are using the -l method, you cannot cross-compile anymore and require the SDL file to be generated for each platform.