Re: Memory Renaming (try 2)

> > Oh, here is in an incredibly useful suggestion that I'd love to see > > added into the sms stuff while you are at it - add a calloc function that > > tries to use calloc if available, or use malloc/memset. There are interesting to note that people are considering actually using this _outside

CTR vs RTC (was: Re: Memory Renaming (try 2))

On Sat, May 12, 2001 at 02:37:35PM +0100, David Reid wrote: >... > > > 8) Someone with karma should probably rename the files to match the > > >appropriate names (apr_sms.h, etc.). > > > > Ack. Could someone with the karma please rise :-) > > There are a lot of people with "karma" but as I sai

APR Memory Renaming

The general consensus seems to be to do the following... apr_sms_t apr_sms_create apr_sms_reset apr_sms_destroy apr_sms_threadsafe_lock apr_sms_threadsafe_unlock apr_sms_is_ancestor apr_sms_cleanup_register apr_sms_cleanup_unregister apr_sms_cleanup_run apr_sms_std_create apr_sms_tracking_create

Re: Memory Renaming (try 2)

Ah yes, I like... > Oh, here is in an incredibly useful suggestion that I'd love to see > added into the sms stuff while you are at it - add a calloc function that > tries to use calloc if available, or use malloc/memset. There are > a lots of places in the apr/apr-util/httpd code (SDBM comes to

Re: Memory Renaming (try 2)

Justin Erenkrantz wrote: > > Doesn't ANSI C define this? Hmm, I just looked at FreeBSD's kernel malloc > code, no. My understanding is that you guys are going to be adding > kernel memory allocation support, right? So you won't necessarily be > talking to ANSI compliant malloc()s. Maybe this

Re: Memory Renaming (try 2)

On Sat, May 12, 2001 at 01:41:37PM +0200, Sander Striker wrote: > > 2) From the performance standpoint, we need to make this malloc stuff as > >fast as the plain malloc call or this isn't going to be worth much. > >Checks such as "if !size return 0" probably isn't needed in > >apr_sms_m

Re: Memory Renaming (try 2)

Do we need to vote or are we happy with apr_sms_t? If we are then the new names will be... apr_sms_t apr_sms_create apr_sms_reset apr_sms_destroy apr_sms_threadsafe_lock apr_sms_threadsafe_unlock apr_sms_is_ancestor apr_sms_cleanup_register apr_sms_cleanup_unregister apr_sms_cleanup_run apr_sms

filepath test program

Can someone look at this as it breaks the "make test" due to it's looping... If I wasn't been driven mad by my sunburn itching so badly as it all flakes off I'd probably have a look myself... david

Re: Memory Renaming (try 2)

You know it's not a race guys... The reason that no-one has changed the code yet is that we haven't really had enough time to talk about it. The changes will get made, but it requires patience at the moment. > > 1) Said before, but asserts are yucky. Once we have it compiling and > >working

RE: Memory Renaming (try 2)

[...] > Since the build doesn't generate the makefiles for memory (and am > too tired to dig around myself and get it to do it right now), I can't > tell you whether the original code or my renamed code compiles. Just add 'memory' to 'apr_modules' in configure.in and rerun buildconf, configure and

Re: cvs commit: apr-util/build rules.mk.in

[EMAIL PROTECTED] writes: > Also, fix a bug that was preventing recursive extraclean from > working. Is a fix to extraclean Apache's rules.mk on your list of things to do? Let me know if not. For the moment I hesitate to risk screwing it up while you're making such good progress. This logic

Re: Memory Renaming (try 2)

Ah heck, since I looked at the code and couldn't make heads or tails of it in its current format, I applied the name changes discussed in this thread locally. That made it easier to review. If that patch (see below) can save someone else time, all the better. =) If I misunderstood the intentio

RE: Memory Renaming (try 2)

[...] >> To back this up I'm going to share my view on the naming of apr >> functions. I think it is done like this: >> >> apr__ >> >> So, for me apr_sms_std_create would read as: do a 'standard create' >> of 'sms', opposed to apr_std_sms_create reading: do a 'create' of >> 'standard sms'. > > I se

RE: Memory Renaming (try 2)

On Sat, 12 May 2001, Sander Striker wrote: > Ok, I can for both options see the arguments, however, I tend to > go for: > > apr_std_sms_create > apr_tracking_sms_create > > To back this up I'm going to share my view on the naming of apr > functions. I think it is done like this: > > apr__ > > So,

RE: Memory Renaming (try 2)

> On Fri, May 11, 2001 at 11:35:24AM +0100, David Reid wrote: >> OK, in an effort at moving things along these names are much shorter. >> >> apr_sms_t >> >> apr_sms_create >> apr_sms_reset >> apr_sms_destroy >> apr_sms_threadsafe_lock >> apr_sms_threadsafe_unlock >> apr_sms_is_ancestor >> apr_sms

Re: cvs commit: apr/build mkdep.sh

On Fri, May 11, 2001 at 06:08:19PM -0400, Victor J. Orlikowski wrote: > > But Victor's patch to use regular "cc" was probably wrong. As Jeff points > > out, only gcc responds to -MM and "does the right thing" > > Is the correct thing to do, then, mucking with the flags, based on > whether or not