On Tue, Jun 05, 2001 at 01:12:56AM +0200, Sander Striker wrote:
> Hi all,
>
> The assert() discussion seems to have taken place a few times
> now, but I still feel the need to vent my thoughts on the
> matter.
>
> To get one thing out of the way beforehand: asserts have no
> meaning in production
Hi,
This patch adds HMAC MD5 to apr-util.
Functions:
APU_DECLARE(apr_status_t) apr_hmac_md5_init(apr_hmac_md5_ctx_t *context,
const unsigned char *key,
apr_size_t keyLen);
APU_DECLARE(apr_status_t) apr_hmac_
On Tue, 5 Jun 2001, Sander Striker wrote:
> > -if (!mem_sys->parent_mem_sys)
> > -return;
> > -
> > -parent = mem_sys
> > +parent = mem_sys->parent_mem_sys;
>
> This line should read:
> parent = mem_sys;
>
> The condition is also satified if the memory system
On Tue, 5 Jun 2001, Sander Striker wrote:
> To wrap the assert subject up I'd like to say that I, personally,
> like asserts because they allow me to let the code bomb out
> in a (semi)controlled way in debug time. Whereas in production
> the code simply bombs out 'uncontrolled'. This seems a mino
Hi,
Thanks for bringing the code more into APR policy I guess.
> -#ifdef APR_MEMORY_ASSERT
> +#ifdef APR_ASSERT_MEMORY
>APR_DECLARE(void) apr_sms_assert(apr_sms_t *mem_sys)
>{
>apr_sms_t *parent;
> @@ -249,10 +221,7 @@
> * tracking ancestors, but in that specific cas
Hi all,
The assert() discussion seems to have taken place a few times
now, but I still feel the need to vent my thoughts on the
matter.
To get one thing out of the way beforehand: asserts have no
meaning in production builds. They are simply not compiled in
[well, they become noops].
The same goe
On Mon, 4 Jun 2001, Greg Stein wrote:
> On this topic... note that the new SMS stuff has a bunch of argument
> checking, too. All that needs to be yanked, too.
I just sent Jeff an email like five minutes ago asking what he thought
about all that. I agree, it needs to go.
--Cliff
--
On this topic... note that the new SMS stuff has a bunch of argument
checking, too. All that needs to be yanked, too.
Cheers,
-g
On Mon, Jun 04, 2001 at 11:35:30AM -0700, Justin Erenkrantz wrote:
> On Mon, Jun 04, 2001 at 02:25:18PM -0400, Jeff Trawick wrote:
> > [EMAIL PROTECTED] writes:
> >
>
"Sander Striker" <[EMAIL PROTECTED]> writes:
> Oops, sorry. I was thinking from the library point of view
> where all errors should be handled. If the policy is segfaulting
> when NULL pointers are passed that makes sense to me.
>
> However, I would suggest putting in something like:
>
> #ifdef
> And, having release code differ from debug code is
> really, really bad. Others might disagree with me
> on this (I think some do). -- justin
Well, I certainly do. What is the point in having a
debug and release build then? Only that release is
stripped from all its symbols and possibly that t
On Mon, Jun 04, 2001 at 08:55:37PM +0200, Sander Striker wrote:
> However, I would suggest putting in something like:
>
> #ifdef APR_MD4_DEBUG
> assert(context);
> #endif
-1 on asserts.
Walking out the door to lunch now. Sorry can't be more verbose, but my
policy on asserts is that they are
Oops, sorry. I was thinking from the library point of view
where all errors should be handled. If the policy is segfaulting
when NULL pointers are passed that makes sense to me.
However, I would suggest putting in something like:
#ifdef APR_MD4_DEBUG
assert(context);
#endif
This way if you d
On Mon, Jun 04, 2001 at 02:25:18PM -0400, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> Justin, I'm sorry I didn't see this before.
>
> yuck!
Okay, I'll back out the EINVAL stuff. Yeah, I thought it was hokey.
Sorry. I was more interested in the apr_md4/apr_md5 call and didn't
pay attent
++1 for all of Jeff's -1's. We have a strict habit of NOT putting in this
kind of bogus checking.
Ryan
On 4 Jun 2001, Jeff Trawick wrote:
> [EMAIL PROTECTED] writes:
>
> > jerenkrantz01/06/04 10:21:56
> >
> > Modified:crypto apr_md4.c
> >include apr_md4.h
> > Log
[EMAIL PROTECTED] writes:
> jerenkrantz01/06/04 10:21:56
>
> Modified:crypto apr_md4.c
>include apr_md4.h
> Log:
> Update error handling and add apr_md4 function.
> Submitted by: Sander Striker <[EMAIL PROTECTED]>
> Reviewed by:Justin Erenkrantz
Hi,
Analoge to the previous patch for md4, now the
same for md5.
- adds some trivial error checking. Maybe someone
wants to complete this by adding the less trivial
error checks?
- adds a direct md5 computation function:
apr_status_t apr_md4(unsigned char digest[APR_MD4_DIGESTSIZE],
Hi,
I've done a little bit of updating of the md4 code.
It adds some trivial error checking. Maybe someone
wants to complete this by adding the less trivial
error checks?
Second it adds a direct md4 computation function:
apr_status_t apr_md4(unsigned char digest[APR_MD4_DIGESTSIZE],
> this is glibc-specific, not Linux-specific, right?
Yes.
> Why are we turning on _BSD_SOURCE and _SVID_SOURCE here? What do they
> have to do with pthread_rwlock_t? Only _XOPEN_SOURCE=500 is needed
> for pthread_rwlock_t IIRC. _BSD_SOURCE is related to the combination
> of _XOPEN_SOURCE=
these days, if you are in the u.s.:
all you need to do is send off an email
and a copy of the code in question to the correct
authorities.
that automatically grants authorisation to distribute
said code, under an open source license.
luke
On Sun, Jun 03, 2001 at 08:02:20PM +0200, Sander Striker
[EMAIL PROTECTED] writes:
> jerenkrantz01/05/31 19:58:32
>
> Modified:.configure.in
> Log:
> Detect the wacky Linux-specific condition where pthread_rwlock_init is
> defined, but the declaration of pthread_rwlock_t requires extra
> #defines.
this is glibc-specific, not
Greg Stein <[EMAIL PROTECTED]> writes:
> On Fri, Jun 01, 2001 at 07:55:52PM -0400, Jeff Trawick wrote:
> > Greg Stein <[EMAIL PROTECTED]> writes:
> >
> > > No. apr_hints is a last resort. Actual tests like the AC_TRY_COMPILE()
> > > that
> > > Justin did are the right way to do it. We should alw
21 matches
Mail list logo
