Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
Rémy, On 5/15/24 09:12, Rémy Maucherat wrote: On Tue, May 14, 2024 at 11:15 PM Christopher Schultz wrote: All, I'd like to basically globally-search-and-replace ERR_error_string for ERR_error_string_n and use a #define constant for both the initialization of all char err[256]; and similar strings and use that same constant for all calls to ERR_error_string_n.. Any objections? There should really be no effective change, except: 1. We can raise that error message length constant and have it affect the whole library if we choose. 2. We will be using a length-aware string-manipulation call which is better than using one that assumes that the buffer is at least 256 bytes long. +1 This gives me something to do since I thought this was 128 (this probably came from the tomcat-native code somewhere initially), so I have a problem with the FFM code which I will fix at the same time. It seems 128 is already enough in practice. I already have a patch ready to go. I was just waiting on some feedback before pushing. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
On Tue, May 14, 2024 at 11:15 PM Christopher Schultz wrote: > > All, > > I'd like to basically globally-search-and-replace ERR_error_string for > ERR_error_string_n and use a #define constant for both the > initialization of all > > char err[256]; > > and similar strings and use that same constant for all calls to > ERR_error_string_n.. > > Any objections? > > There should really be no effective change, except: > > 1. We can raise that error message length constant and have it affect > the whole library if we choose. > > 2. We will be using a length-aware string-manipulation call which is > better than using one that assumes that the buffer is at least 256 bytes > long. +1 This gives me something to do since I thought this was 128 (this probably came from the tomcat-native code somewhere initially), so I have a problem with the FFM code which I will fix at the same time. It seems 128 is already enough in practice. Rémy > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
Michael,
On 5/15/24 05:14, Michael Osipov wrote:
On 2024/05/14 21:15:03 Christopher Schultz wrote:
All,
I'd like to basically globally-search-and-replace ERR_error_string for
ERR_error_string_n and use a #define constant for both the
initialization of all
char err[256];
and similar strings and use that same constant for all calls to
ERR_error_string_n..
Any objections?
There should really be no effective change, except:
1. We can raise that error message length constant and have it affect
the whole library if we choose.
2. We will be using a length-aware string-manipulation call which is
better than using one that assumes that the buffer is at least 256 bytes
long.
Sounds reasonable to have one unified spot. Though I wonder how to better
address this with BZ 67609
I think this is unrelated at this point. We still probably need to
improve the error-reporting situation overall; the buffer-size is just a
detail.
and if resizing/realloc would be required?!
In every case I changed in the code, nothing is on the heap. Every case
is something like this:
void foo(...) {
char err[256];
...
ERR_error_string(SSL_ERR_get(), err);
...
}
or
if(some_error_condition) {
char err[256];
ERR_error_string(SSL_ERR_get(), err);
tcn_throw(...);
}
So re-allocations aren't (currently) on the menu.
If we at some point decide to implement more "fully-featured" error
reporting/handling, perhaps that will become an issue.
-chris
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
On 2024/05/14 21:15:03 Christopher Schultz wrote: > All, > > I'd like to basically globally-search-and-replace ERR_error_string for > ERR_error_string_n and use a #define constant for both the > initialization of all > > char err[256]; > > and similar strings and use that same constant for all calls to > ERR_error_string_n.. > > Any objections? > > There should really be no effective change, except: > > 1. We can raise that error message length constant and have it affect > the whole library if we choose. > > 2. We will be using a length-aware string-manipulation call which is > better than using one that assumes that the buffer is at least 256 bytes > long. Sounds reasonable to have one unified spot. Though I wonder how to better address this with BZ 67609 and if resizing/realloc would be required?! M - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[tcnative] switch from using ERR_error_string to ERR_error_string_n
All, I'd like to basically globally-search-and-replace ERR_error_string for ERR_error_string_n and use a #define constant for both the initialization of all char err[256]; and similar strings and use that same constant for all calls to ERR_error_string_n.. Any objections? There should really be no effective change, except: 1. We can raise that error message length constant and have it affect the whole library if we choose. 2. We will be using a length-aware string-manipulation call which is better than using one that assumes that the buffer is at least 256 bytes long. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
