We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 4526

Summary: [Feature request] replace SDL_RW* macros with functions for using in bindings
Product: SDL Reporter: ace <spam4ace>
Component: fileAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: normal    
Priority: P2 CC: icculus, sezeroz, sylvain.becker
Version: don't knowKeywords: target-2.0.10
Hardware: All   
OS: All   

Description ace 2019-03-01 06:45:11 UTC 
I got this bug in SDL_ttf:
https://bugzilla.libsdl.org/show_bug.cgi?id=4524
Sylvain proposed solution:
SDL_RWseek(RWops, 0, RW_SEEK_SET);

And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there not export for macroses:
#define SDL_RWsize(ctx)         (ctx)->size(ctx)
#define SDL_RWseek(ctx, offset, whence) (ctx)->seek(ctx, offset, whence)
#define SDL_RWtell(ctx)         (ctx)->seek(ctx, 0, RW_SEEK_CUR)
#define SDL_RWread(ctx, ptr, size, n)   (ctx)->read(ctx, ptr, size, n)
#define SDL_RWwrite(ctx, ptr, size, n)  (ctx)->write(ctx, ptr, size, n)
#define SDL_RWclose(ctx)        (ctx)->close(ctx)

Therefore, I suggest replacing this macros with functions so that they can be exported and used in bindings
Comment 1 ace 2019-03-01 09:02:07 UTC 
Seems i'm not able to edit description:

There misprint in description:
"And it works, but i can use it my project, because it written in C# with SDL2-CS wrapper and there"
Must be 
"And it works, but i CANNOT use it my project, because it written in C# with SDL2-CS wrapper and there"
Comment 2 Sylvain 2019-03-01 20:47:57 UTC 
This could be added ...
but maybe:

1/ you can report that to one who does the wrapper so that it provides also the macros

2/ There is not SDL_RWseek but maybe it exposes things to call: (ctx)->seek(ctx, offset, whence)
Comment 3 ace 2019-03-02 15:19:31 UTC 
I asked author of the wrapper about this, could you please read his answer here:
https://github.com/flibitijibibo/SDL2-CS/issues/156
Comment 4 Ryan C. Gordon 2019-05-18 18:48:55 UTC 
Tagging a bunch of bugs with "target-2.0.10" so we have a clear list of things to address before a 2.0.10 release.

Please note that "addressing" one of these bugs might mean deciding to defer on it until after 2.0.10, or resolving it as WONTFIX, etc. This is just here to tell us we should look at it carefully, and soon.

If you have new information or feedback on this issue, this is a good time to add it to the conversation, as we're likely to be paying attention to this specific report in the next few days/weeks.

Thanks!

--ryan.
Comment 5 Sam Lantinga 2019-06-09 00:43:45 UTC 
Done!
https://hg.libsdl.org/SDL/rev/302904fa669a
Comment 6 Ozkan Sezer 2019-06-26 12:20:35 UTC 
(In reply to Sam Lantinga from comment #5)
> Done!
> https://hg.libsdl.org/SDL/rev/302904fa669a

This makes programs using these calls and built against 2.0.10
not to work with SDL2 <= 2.0.9. (Examples include SDL libsaries.)
Is this really OK?
Comment 7 Ryan C. Gordon 2019-06-26 13:09:05 UTC 
Fwiw, we did this with all the stdlib functions (SDL_strcmp and such) and no one reported problems.
Comment 8 Ozkan Sezer 2019-06-26 13:32:57 UTC 
(In reply to Ryan C. Gordon from comment #7)
> Fwiw, we did this with all the stdlib functions (SDL_strcmp and such) and no
> one reported problems.

Did such a thing happen after 2.0.0 release? When?
Comment 9 Ryan C. Gordon 2019-06-26 14:35:42 UTC 
(In reply to Ozkan Sezer from comment #8)
> Did such a thing happen after 2.0.0 release? When?

Whoops, this happened before 2.0.0 shipped, my mistake.

Sam, it's your call. I'm reopening the bug just so we can see it in the TODO list, but if you think it's okay, I'm fine with it just being closed again.

--ryan.
Comment 10 Sam Lantinga 2019-07-01 05:50:47 UTC 
Yes, SDL guarantees that binaries built with an older library will work with newer binaries, but not the reverse. If you build with newer headers you need to ship the newer library.
Comment 11 Ozkan Sezer 2019-07-01 09:12:19 UTC 
(In reply to Sam Lantinga from comment #10)
> Yes, SDL guarantees that binaries built with an older library will work with
> newer binaries, but not the reverse. If you build with newer headers you
> need to ship the newer library.

Even if when using old apis which (silently) changed in new versions?

If you will keep this change, please document it.
Comment 12 Sam Lantinga 2019-07-01 16:02:28 UTC 
Done!
https://hg.libsdl.org/SDL/rev/7b0d6ddaec9d