New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add all renamed symbols to unixsupport.h #11336
Conversation
Remainining functions for the Unix implementation of the library.
de4a88a
to
dbf1aa4
Compare
#define win_alloc_handle caml_win32_alloc_handle | ||
#define win_alloc_socket caml_win32_alloc_socket | ||
#define win_CRT_fd_of_filedescr caml_win32_CRT_fd_of_filedescr | ||
#define win32_maperr caml_win32_maperr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The win32_maperr
macri is also defined at line 78.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch - in fact, that macro not being guarded on L78 in the same way as the others means that there was a renaming missing in socket_win32.c
(presumably a rebase artefact during the original PR)
dbf1aa4
to
5585050
Compare
5585050
to
e5871d1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All compatibility macros are here. It does make sense to not break user code when possible.
However, reviewing this PR, I was left wondering if we should offer a mechanism for hiding those compatibility macros outside of defining CAML_BUILDING_UNIX
variable (which sounds like a very internal setting).
Add all renamed symbols to unixsupport.h (cherry picked from commit 1916810)
I'd been thinking about this, too. My rationale at the moment is that the present changes are about changing the linking symbols in the library (i.e. we've fixed the .a files) and then removing from the headers is a separate fix. I was thinking of putting something together for 5.1 to deprecate those symbols but we should also learn the "lessons" of
Yes, definitely - there's no expectation on user code to do this, it's just to prevent our code from inadvertently using the old symbols. |
Small follow-on from #10926, spotted in ocsigen/lwt#953. Most of the functions declared in
unixsupport.h
which were renamed had compatibility macros added as part of the original PR, but a few got missed.This PR tidies
unixsupport.h
slightly to put them in one place and adds#define
for all of the symbols which were renamed.The only other public header from the unix library is
socketaddr.h
which already has all of these handled.