You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Dirk-Willem van Gulik <di...@webweaving.org> on 2017/01/19 13:25:38 UTC
apr-util error code
It seems that various error codes of what used to be apr-util do not resolve in strings.
Is there a larger master plan for this (where modules such as apr_crypto_FOO can ‘register’ strings) — or would something as brutal as below
be the path for now ?
or am I missing something.
Dw.
Index: misc/unix/errorcodes.c
===================================================================
--- misc/unix/errorcodes.c (revision 1779018)
+++ misc/unix/errorcodes.c (working copy)
@@ -19,6 +19,8 @@
#include "apr_lib.h"
#include "apr_dso.h"
+#include "apu_errno.h"
+
#if APR_HAVE_NETDB_H
#include <netdb.h>
#endif
@@ -139,6 +141,14 @@
return "The process is not recognized.";
case APR_EGENERAL:
return "Internal error (specific information not available)";
+/* APR Util error codes */
+ case APR_ECRYPT:
+ return "Internal error in the crypto subsystem (specific information not available)";
+ case APR_ENOENGINE:
+ return "No such engine known to the crypto subsystem";
+ case APR_EINITENGINE:
+ return "Failed to init (or dlload) engine for crypto subsystem";
+
default:
return "Error string not specified yet";
}
Re: apr-util error code
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 19 Jan 2017, at 18:44, Dirk-Willem van Gulik <di...@webweaving.org> wrote:
>
> On 19 Jan 2017, at 18:40, Branko Čibej <brane@apache.org <ma...@apache.org>> wrote:
>> On 19.01.2017 18:30, Dirk-Willem van Gulik wrote:
>>> On 19 Jan 2017, at 17:46, William A Rowe Jr <wrowe@rowe-clan.net <ma...@rowe-clan.net>> wrote:
>>>
>>>> In 2.0 I'd like to see include/apu_error.h simply a stub to #include
>>>> <apr_errno.h>
>>>> and track it all in one place. Will try to hold onto that though for
>>>> my next round tuit.
>>>>
>>>> It makes the back porting of new apu_errno.h constants a bit trickier but hardly
>>>> impossible.
>>>>
>>>> ITMT, your proposal looks fine Dirk.
>>> Ok - what is the best way to get things like this in - shall I simply send them as unified diff into http://issues.apache.org/bugzilla/ <http://issues.apache.org/bugzilla/>.
>>>
>>> Or better to post them here for a more coherent picture.
>>>
>>> As I suspect I have a few more — the world of crypto and hash-ing seems to have a few small loose ends like this.
>>
>> You're an APR committer. Just commit it.
>
> Am I ? Ok - will try !
Blush - you were totally correct. I simply did not spot an http(s) error - and assumed I had no access.
Thanks all (and Daniel Gruno for spotting it in 1 second!)
Dw.
Re: apr-util error code
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 19 Jan 2017, at 18:40, Branko Čibej <br...@apache.org> wrote:
> On 19.01.2017 18:30, Dirk-Willem van Gulik wrote:
>> On 19 Jan 2017, at 17:46, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>>> In 2.0 I'd like to see include/apu_error.h simply a stub to #include
>>> <apr_errno.h>
>>> and track it all in one place. Will try to hold onto that though for
>>> my next round tuit.
>>>
>>> It makes the back porting of new apu_errno.h constants a bit trickier but hardly
>>> impossible.
>>>
>>> ITMT, your proposal looks fine Dirk.
>> Ok - what is the best way to get things like this in - shall I simply send them as unified diff into http://issues.apache.org/bugzilla/.
>>
>> Or better to post them here for a more coherent picture.
>>
>> As I suspect I have a few more — the world of crypto and hash-ing seems to have a few small loose ends like this.
>
> You're an APR committer. Just commit it.
Am I ? Ok - will try !
Dw
Re: apr-util error code
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Thu, Jan 19, 2017 at 11:40 AM, Branko Čibej <br...@apache.org> wrote:
> On 19.01.2017 18:30, Dirk-Willem van Gulik wrote:
>> On 19 Jan 2017, at 17:46, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>>> In 2.0 I'd like to see include/apu_error.h simply a stub to #include
>>> <apr_errno.h>
>>> and track it all in one place. Will try to hold onto that though for
>>> my next round tuit.
>>>
>>> It makes the back porting of new apu_errno.h constants a bit trickier but hardly
>>> impossible.
>>>
>>> ITMT, your proposal looks fine Dirk.
>> Ok - what is the best way to get things like this in - shall I simply send them as unified diff into http://issues.apache.org/bugzilla/.
>>
>> Or better to post them here for a more coherent picture.
>>
>> As I suspect I have a few more — the world of crypto and hash-ing seems to have a few small loose ends like this.
>
> You're an APR committer. Just commit it.
+1
I got stuck at apu_err_t... if I remember correctly, Subversion solved extended
error info in an altogether more useful way. Would rather bring the svn error
type into apr 2.0 in apu_err_t's place, once I have a chance to look at that.
Would really rather have an SVN/APR committer introduce this to apr_error.h
and we can unify it all.
Re: apr-util error code
Posted by Branko Čibej <br...@apache.org>.
On 19.01.2017 18:30, Dirk-Willem van Gulik wrote:
> On 19 Jan 2017, at 17:46, William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
>> In 2.0 I'd like to see include/apu_error.h simply a stub to #include
>> <apr_errno.h>
>> and track it all in one place. Will try to hold onto that though for
>> my next round tuit.
>>
>> It makes the back porting of new apu_errno.h constants a bit trickier but hardly
>> impossible.
>>
>> ITMT, your proposal looks fine Dirk.
> Ok - what is the best way to get things like this in - shall I simply send them as unified diff into http://issues.apache.org/bugzilla/.
>
> Or better to post them here for a more coherent picture.
>
> As I suspect I have a few more \u2014 the world of crypto and hash-ing seems to have a few small loose ends like this.
You're an APR committer. Just commit it.
-- Brane
Re: apr-util error code
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 19 Jan 2017, at 17:46, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> In 2.0 I'd like to see include/apu_error.h simply a stub to #include
> <apr_errno.h>
> and track it all in one place. Will try to hold onto that though for
> my next round tuit.
>
> It makes the back porting of new apu_errno.h constants a bit trickier but hardly
> impossible.
>
> ITMT, your proposal looks fine Dirk.
Ok - what is the best way to get things like this in - shall I simply send them as unified diff into http://issues.apache.org/bugzilla/.
Or better to post them here for a more coherent picture.
As I suspect I have a few more — the world of crypto and hash-ing seems to have a few small loose ends like this.
Dw.
>
>
> On Thu, Jan 19, 2017 at 7:25 AM, Dirk-Willem van Gulik
> <di...@webweaving.org> wrote:
>> It seems that various error codes of what used to be apr-util do not resolve in strings.
>>
>> Is there a larger master plan for this (where modules such as apr_crypto_FOO can ‘register’ strings) — or would something as brutal as below
>> be the path for now ?
>>
>> or am I missing something.
>>
>> Dw.
>>
>> Index: misc/unix/errorcodes.c
>> ===================================================================
>> --- misc/unix/errorcodes.c (revision 1779018)
>> +++ misc/unix/errorcodes.c (working copy)
>> @@ -19,6 +19,8 @@
>> #include "apr_lib.h"
>> #include "apr_dso.h"
>>
>> +#include "apu_errno.h"
>> +
>> #if APR_HAVE_NETDB_H
>> #include <netdb.h>
>> #endif
>> @@ -139,6 +141,14 @@
>> return "The process is not recognized.";
>> case APR_EGENERAL:
>> return "Internal error (specific information not available)";
>> +/* APR Util error codes */
>> + case APR_ECRYPT:
>> + return "Internal error in the crypto subsystem (specific information not available)";
>> + case APR_ENOENGINE:
>> + return "No such engine known to the crypto subsystem";
>> + case APR_EINITENGINE:
>> + return "Failed to init (or dlload) engine for crypto subsystem";
>> +
>> default:
>> return "Error string not specified yet";
>> }
>>
>>
>
Re: apr-util error code
Posted by William A Rowe Jr <wr...@rowe-clan.net>.
In 2.0 I'd like to see include/apu_error.h simply a stub to #include
<apr_errno.h>
and track it all in one place. Will try to hold onto that though for
my next round tuit.
It makes the back porting of new apu_errno.h constants a bit trickier but hardly
impossible.
ITMT, your proposal looks fine Dirk.
On Thu, Jan 19, 2017 at 7:25 AM, Dirk-Willem van Gulik
<di...@webweaving.org> wrote:
> It seems that various error codes of what used to be apr-util do not resolve in strings.
>
> Is there a larger master plan for this (where modules such as apr_crypto_FOO can ‘register’ strings) — or would something as brutal as below
> be the path for now ?
>
> or am I missing something.
>
> Dw.
>
> Index: misc/unix/errorcodes.c
> ===================================================================
> --- misc/unix/errorcodes.c (revision 1779018)
> +++ misc/unix/errorcodes.c (working copy)
> @@ -19,6 +19,8 @@
> #include "apr_lib.h"
> #include "apr_dso.h"
>
> +#include "apu_errno.h"
> +
> #if APR_HAVE_NETDB_H
> #include <netdb.h>
> #endif
> @@ -139,6 +141,14 @@
> return "The process is not recognized.";
> case APR_EGENERAL:
> return "Internal error (specific information not available)";
> +/* APR Util error codes */
> + case APR_ECRYPT:
> + return "Internal error in the crypto subsystem (specific information not available)";
> + case APR_ENOENGINE:
> + return "No such engine known to the crypto subsystem";
> + case APR_EINITENGINE:
> + return "Failed to init (or dlload) engine for crypto subsystem";
> +
> default:
> return "Error string not specified yet";
> }
>
>