You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Christopher Schultz <ch...@christopherschultz.net> on 2024/05/14 21:15:03 UTC
[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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
Posted by Michael Osipov <mi...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Rémy,
On 5/15/24 09:12, Rémy Maucherat wrote:
> On Tue, May 14, 2024 at 11:15 PM Christopher Schultz
> <ch...@christopherschultz.net> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tcnative] switch from using ERR_error_string to ERR_error_string_n
Posted by Rémy Maucherat <re...@apache.org>.
On Tue, May 14, 2024 at 11:15 PM Christopher Schultz
<ch...@christopherschultz.net> 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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org