You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If we care about support for old readline versions, then option 2 as the commit likely broke it.
If we don't then I'd say option 1 for just a bit of code cleanup.
It looks like readline library has always defined _RL_FUNCTION_TYPEDEF since at least version 4.2 (circa 2001)
./Modules/readline.c:1023:16: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
on_startup_hook()
^
void
./Modules/readline.c:1038:18: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
on_pre_input_hook()
^
void
./Modules/readline.c:1023:16: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
on_startup_hook()
^
void
./Modules/readline.c:1038:18: warning: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
on_pre_input_hook()
^
void
Right, so we should try and find out the real fix, then.
This issue is not related to whether we have to declare the params as void or not, it's just difference between explict declaration or not.
@corona10: suggesting to close #105323 as superseded, since we've got more information in this discussion.
I am not sure, so it looks like, the right solution is detecting different signatures between different readline versions and compiling with conditional compilation as we discussed from #105323? no?
I am not sure, so it looks like, the right solution is detecting different signatures between different readline versions and compiling with conditional compilation as we discussed from #105323? no?
Your issue is solved for me if I revert Irit's commit, so I do think they are related.
Your issue is solved for me if I revert Irit's commit, so I do think they are related.
If you are arguing that the issue is just about ignoring the compiler warning, you are right.
But if we are focusing on the on_pre_input_hook and on_startup_hook are not declared as the proper params for each readline versions, the issue is not yet solved.
All right, I leave it to you to consider if this issue, #105323, and #105240 are related :) I don't have the bandwidth for this. FTR, here's some info from my machine:
Yeah, when I reviewed the #105241, I didn't deeply investigate the issue.
It was not a proper patch at that moment, but we discovered the root cause from #105323 :(
I don't have a lot of insight into this and I likely won't have time to look at it further for the next two weeks. But, AFAIK, there are at least three cases of interest that need to be covered: 1. linking the Python readline module with GNU readline; 2. linking with the latest BSD editline (libedit) module; and 3. linking with the version of BSD editline (libedit) that Apple ships with macOS. Note that editline provides an old GNU readline compatibility shim and that is what we link to when using any version of libedit, i.e. we do not support the native editline/libedit API. All three of those cases are being used today on macOS by various distributors so we should be sure they all work. The first two are used on other platforms and should also be tested. There may be other configurations of interest.
Activity
CorvinM commentedon Aug 28, 2023
If we care about support for old readline versions, then option 2 as the commit likely broke it.
If we don't then I'd say option 1 for just a bit of code cleanup.
It looks like readline library has always defined
_RL_FUNCTION_TYPEDEFsince at least version 4.2 (circa 2001)sobolevn commentedon Aug 29, 2023
cc @iritkatriel
iritkatriel commentedon Aug 29, 2023
I made that commit to silence some warning. I don't have an opinion on this.
erlend-aasland commentedon Aug 29, 2023
I currently get a compiler warning for
readline.con my Mac. The warning disappears if I revert a9305b5.erlend-aasland commentedon Aug 29, 2023
See #105323, which appeared a few days after a9305b5
erlend-aasland commentedon Aug 29, 2023
@iritkatriel, do you get a compiler warning if you revert a9305b5?
iritkatriel commentedon Aug 29, 2023
Go ahead and revert it. I don't remember the details of why I put it in.
iritkatriel commentedon Aug 29, 2023
I do get a warning actually when I revert it:
erlend-aasland commentedon Aug 29, 2023
erlend-aasland commentedon Aug 29, 2023
Right, so we should try and find out the real fix, then.
erlend-aasland commentedon Aug 29, 2023
What's the output of
grep READLINE Makefile config.log, @iritkatriel?sobolevn commentedon Aug 29, 2023
@erlend-aasland no, I don't work on this issue, I don't have any knowledge about
readline:)erlend-aasland commentedon Aug 29, 2023
@corona10: suggesting to close #105323 as superseded, since we've got more information in this discussion.
iritkatriel commentedon Aug 29, 2023
corona10 commentedon Aug 29, 2023
This issue is not related to whether we have to declare the params as void or not, it's just difference between explict declaration or not.
I am not sure, so it looks like, the right solution is detecting different signatures between different readline versions and compiling with conditional compilation as we discussed from #105323? no?
erlend-aasland commentedon Aug 29, 2023
Your issue is solved for me if I revert Irit's commit, so I do think they are related.
erlend-aasland commentedon Aug 29, 2023
@corona10, see #108588 (comment).
corona10 commentedon Aug 29, 2023
If you are arguing that the issue is just about ignoring the compiler warning, you are right.
But if we are focusing on the
on_pre_input_hookandon_startup_hookare not declared as the proper params for each readline versions, the issue is not yet solved.erlend-aasland commentedon Aug 29, 2023
All right, I leave it to you to consider if this issue, #105323, and #105240 are related :) I don't have the bandwidth for this. FTR, here's some info from my machine:
corona10 commentedon Aug 29, 2023
Yeah, when I reviewed the #105241, I didn't deeply investigate the issue.
It was not a proper patch at that moment, but we discovered the root cause from #105323 :(
I think that it's still worth to solve the issue.
corona10 commentedon Aug 29, 2023
Patch is submitted for macOS: #108633
ned-deily commentedon Aug 29, 2023
I don't have a lot of insight into this and I likely won't have time to look at it further for the next two weeks. But, AFAIK, there are at least three cases of interest that need to be covered: 1. linking the Python readline module with GNU readline; 2. linking with the latest BSD editline (libedit) module; and 3. linking with the version of BSD editline (libedit) that Apple ships with macOS. Note that editline provides an old GNU readline compatibility shim and that is what we link to when using any version of libedit, i.e. we do not support the native editline/libedit API. All three of those cases are being used today on macOS by various distributors so we should be sure they all work. The first two are used on other platforms and should also be tested. There may be other configurations of interest.
erlend-aasland commentedon Apr 17, 2024
I think we can close this now that #117870 has landed.