On 22 Jan 2017, at 13:02, b...@qqmail.nl wrote:
>
> That encoded[len] reference should use the same apr_base64_encode_len result
> as the first allocation, or the bas64 data is truncated.
I think you are right - but the other way round in this case - I was allocating
one byte too many. Fixed in
On 20 Jan 2017, at 20:57, Ruediger Pluem wrote:
> On 01/20/2017 05:01 PM, Eric Covener wrote:
>> On Fri, Jan 20, 2017 at 10:52 AM, Yann Ylavic wrote:
>>> On Fri, Jan 20, 2017 at 4:19 PM, Dirk-Willem van Gulik
>>> wrote:
>>>>
>>>> Ok so
> On 20 Jan 2017, at 16:02, Ben Laurie wrote:
>
> On 20 January 2017 at 14:52, Dirk-Willem van Gulik
> wrote:
>>
>>> On 20 Jan 2017, at 15:46, Ben Laurie wrote:
>>>
>>> On 20 January 2017 at 14:36, Dirk-Willem van Gulik
>>> w
> On 20 Jan 2017, at 12:53, Yann Ylavic wrote:
>
> On Fri, Jan 20, 2017 at 9:22 AM, Dirk-Willem van Gulik
> wrote:
>>
>> As to the selection of the hash - I can see three strategies
>>
>> A) current approach (we do this I think only for sha256):
>
> On 20 Jan 2017, at 15:46, Ben Laurie wrote:
>
> On 20 January 2017 at 14:36, Dirk-Willem van Gulik
> wrote:
>> On 20 Jan 2017, at 13:00, Ben Laurie wrote:
>>
>>> Why do you need the obsolete hash functions?
>>
>> I am still in the middle
On 20 Jan 2017, at 13:00, Ben Laurie wrote:
> Why do you need the obsolete hash functions?
I am still in the middle of some inventory work with the help of a few friendly
enterprise & cloud folks.
But it is nog looking good -- so far its seems that:
- md4 is rarely used (i,e.a actually
On 20 Jan 2017, at 12:53, Yann Ylavic wrote:
>>
>>apr_hash(sha256_ctx, &buf, &len, plain, plainlen, pool);
>
> Probably apr_crypto_hash() since apr_hash() is non-crypto hashtable in APR.
> Would be nice to have init/update/finish versions too.
I think global rename to apr_dige
On 19 Jan 2017, at 21:04, William A Rowe Jr wrote:
> On Thu, Jan 19, 2017 at 1:50 PM, Dirk-Willem van Gulik
> wrote:
>>
>>> On 19 Jan 2017, at 19:50, Graham Leggett wrote:
>>> On 19 Jan 2017, at 18:29, Dirk-Willem van Gulik
>>> wrote:
>>>
>
> On 19 Jan 2017, at 15:10, Graham Leggett wrote:
>
> On 19 Jan 2017, at 3:22 PM, Dirk-Willem van Gulik
> wrote:
>
>> Any reason we do not have such in APR-2 (as a compagnion to
>> apr_pbase64_encode) ?
>>
>> Dw.
>>
>>
>>
>&
> On 19 Jan 2017, at 19:50, Graham Leggett wrote:
>
> On 19 Jan 2017, at 18:29, Dirk-Willem van Gulik wrote:
>
>> Am wondering now it if makes sense to create a new directory with:
>>
>> hash/*
>>
>> section (or something in crypto) w
On 19 Jan 2017, at 15:20, Dirk-Willem van Gulik wrote:
>
> Where can I find the proper version of below — to do things like
>
> apr_crypto_hash_t * sha256_ctx = apr_crypto_sha256_new(pool);
>
> apr_hash(sha256_ctx, …...
>
> ? Or was this abstracting i
> On 19 Jan 2017, at 15:23, Graham Leggett wrote:
>
> On 19 Jan 2017, at 4:17 PM, Dirk-Willem van Gulik
> wrote:
>
>> I must be getting old - I am pretty sure I used in the past a pool alloc
>> that would nicely scrub any keys from memory upon pool clear down; alo
> On 19 Jan 2017, at 18:44, Dirk-Willem van Gulik wrote:
>
> On 19 Jan 2017, at 18:40, Branko Čibej <mailto: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 >> <mailto:wr.
On 19 Jan 2017, at 18:40, Branko Čibej wrote:
> On 19.01.2017 18:30, Dirk-Willem van Gulik wrote:
>> On 19 Jan 2017, at 17:46, William A Rowe Jr wrote:
>>
>>> In 2.0 I'd like to see include/apu_error.h simply a stub to #include
>>>
>>> and track
e.
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
> wrote:
>> It seems that various error codes of what used to be apr-util do not resolve
&g
Where can I find the proper version of below — to do things like
apr_crypto_hash_t * sha256_ctx = apr_crypto_sha256_new(pool);
apr_hash(sha256_ctx, …...
? Or was this abstracting in apr_random of the hash something which was never
completed (nor had its MD2, MD5 and friends fol
I must be getting old - I am pretty sure I used in the past a pool alloc that
would nicely scrub any keys from memory upon pool clear down; along with some
locking of the page on unix & and some magic to make that stick across forks.
Have I lost it completely ? Or was that never submitted,
Dw.
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: mis
Any reason we do not have such in APR-2 (as a compagnion to apr_pbase64_encode)
?
Dw.
APR_DECLARE(char *) apr_pbase64_encode_binary(apr_pool_t *p, const unsigned
char *string, int len)
{
char *encoded;
encoded = (char *) apr_palloc(p, 1 + apr_base64_encode_len(len));
len = apr_ba
On 19 Jan 2017, at 11:41, Graham Leggett wrote:
> On 18 Jan 2017, at 22:14, Dirk-Willem van Gulik wrote:
>
>> What is the right/proper way to test the crypto modules (as they are not
>> copied into apr/.lib during a normal build) from 'test/testall' ?
>
> I&#
On 19 Jan 2017, at 00:20, William A Rowe Jr wrote:
> On Wed, Jan 18, 2017 at 4:14 PM, Dirk-Willem van Gulik
> wrote:
>> What is the right/proper way to test the crypto modules (as they are not
>> copied into apr/.lib during a normal build) from 'test/testall’ ?
>
What is the right/proper way to test the crypto modules (as they are not copied
into apr/.lib during a normal build) from 'test/testall' ?
Thanks,
Dw.
> On 17 Jan 2017, at 01:25, William A Rowe Jr wrote:
>
> It was called serf. It never entered ASF proper, but it is still out there
> (not sure if Justin moved it from Google code or not.)
>
> On Jan 16, 2017 06:08, "Dirk-Willem van Gulik" <mailto:di...@webwe
I’ve got a few modules that I am trying to merge that all do a bit of simple
HTTP get at the back (with a modicum of 30X resource has moved following & very
simple cookie accept).
Right now I am using various hacks that recycles a bit of mod_proxy & http its
bucked brigades (mostly by removing
That is a really rather odd bit of code. First strawman to improve things a bit
below.
Dw.
Index: misc/win32/misc.c
===
--- misc/win32/misc.c (revision 1765030)
+++ misc/win32/misc.c (working copy)
@@ -181,16 +181,34 @@
if
On 22 Sep 2012, at 15:33, Graham Leggett wrote:
> http://developer.apple.com/library/mac/#documentation/security/Conceptual/cryptoservices/SecureNetworkCommunicationAPIs/SecureNetworkCommunicationAPIs.html
>
> The following patch adds a CommonCrypto implementation to the apr_crypto
> abstractio
On May 14, 2008, at 7:33 PM, Jim Jagielski wrote:
I'll have to try that... in the meantime, does re-adding
the 'rv=0' line fix it?
For me - yes !
Dw.
On May 8, 2008, at 10:07 PM, Jim Jagielski wrote:
Can anyone else confirm that r654186 (for apr-trunk) and
r654186 (for apr-1.3) fixes sendfile to work under Darwin?
In particular, both the perl-test framework for httpd as well
as APR's test suite (and test/sendfile ) pass for me now.
I c
On May 7, 2008, at 11:58 PM, Geoff Greer wrote:
2. httpd on OS X sometimes hangs for a couple seconds. This could have
many causes, including a kernel bug. I don't know what version of
apr and
httpd Dirk was using, but anything outside the 1.3 branch or trunk
on 10.5
has sendfile disabled
On May 7, 2008, at 8:58 PM, Mads Toftum wrote:
On Wed, May 07, 2008 at 02:50:46PM -0400, Jim Jagielski wrote:
To clarify: I have no idea what you are referring to
as far as what issue you were discussing. This is
because it was on IRC. For myself and everyone else who
did not happen to be on I
On May 7, 2008, at 8:42 PM, Jim Jagielski wrote:
On May 7, 2008, at 2:31 PM, Dirk-Willem van Gulik wrote:
Hmm - Jim - that does not quite solve the issue I was discussing on
IRC;
On IRC? What happened to onlist discussions?? :)
Sorry - I was debugging something totally different (I
Hmm - Jim - that does not quite solve the issue I was discussing on
IRC; I think below is needed (which does solve the TimeOut issue).
--> diff with your version -- anticipate nbytes set to 0 (which has
whole file semantics on BSD and Darwin).
Does that make sense ?
Dw
Index: network_io/u
On Feb 6, 2008, at 9:03 AM, Paul Querna wrote:
To use libketama, you should just be able to use this callback
function in apr_memcache trunk, to do server selection:
...
If you need any other callbacks added, just let us know and we can
look into getting them into trunk. I would like to ma
Paul (pquerna),
Did I see a commit flash past from you working on that a while ago ?
Or is my memory way off ?
As I am about to do some work here* - and am wondering if this should
be done properly or as a one off hack. (libketama has some funny exit
codes, etc - so it takes a bit of wrap
On Mon, 12 Dec 2005, Joe Orton wrote:
> On Sat, Dec 10, 2005 at 03:07:11PM -0800, Dirk-Willem van Gulik wrote:
> > Would this be something to add to APR ? Ability to do lazy/deferred
> > loading as opposed to immediate bind.
>
> A more general version of that patch is ava
Would this be something to add to APR ? Ability to do lazy/deferred
loading as opposed to immediate bind.
I stumbled across this porting a small internal util which lets you load a
single apache module; and lets you print the Magic Cookie, name and then
the handle/command structure.
Dw.
I
On Fri, 17 Dec 2004, Paul Querna wrote:
> Any comments on the following API:
Works for me (went through some old loadbalancing module) and seems more
complete than a simple app would need.
Dw
On Feb 29, 2004, at 4:37 PM, [EMAIL PROTECTED] wrote:
like to stir up trouble again, so I am officially asking to have my
commit
access re-instated. I am in the middle of creating a new project that
uses APR,
+1
Dw
This is dragging on a bit - while it is important in my
opinion. To resolve this you - perhaps give your PMC
some input as what you would like them to do:
-> Ask the board; my guess is that our answer will be;
not a derived work if we are talking about #include <...
and strict API
This is dragging on a bit - while it is important in my
opinion. To resolve this you - perhaps give your PMC
some input as what you would like them to do:
-> Ask the board; my guess is that our answer will be;
not a derived work if we are talking about #include <...
and strict API
> In fact, I thought that was the original plan. I recall that some
> people weren't too comfortable with the pooling code in APR-util.
> But, I still think it makes sense... -- justin
One 'ultimate' way to proof how much sense it would make is by using it to
do simply/do some clever apache/tom
On Sun, 29 Dec 2002, Bob Gustafson wrote:
> In going to version 4.1, BerkeleyDB added an extra argument in the call
...cut...
.. if DB4
.. some init changes..
--> Work for me gov.
If I recall correctly DB4 also adds a lot more fine grained control on who
owns the memory associated with
> I would like to make it possible for a site to be accessible without
> password if originating from a specific IP address range, and for the
> site to require a password otherwise.
You propably want to post this on a @httpd.apache.org list; dev@ or
users@ :-).
> Is this possible in the present
On 9 Dec 2002 [EMAIL PROTECTED] wrote:
> sensible here, but I get this feeling that you're trying to push some
> sort of "programmer's best practices" policy agenda via crippling the
> portability layer.
Yes, absolutely, guilty as charged.
> This *is* a portability question.
Well this is the
On 9 Dec 2002 [EMAIL PROTECTED] wrote:
...
> its utilities, svnlook needs to create two temporary files to be used
> by an external 'diff' process. Given only handles, we have no paths
But the svnlook lives longer than the diff process ? Or do you -also-
postulate something like a 'crontab' wh
On 9 Dec 2002 [EMAIL PROTECTED] wrote:
> Wow... so our 'svnlook' utility needs to grow config file support or
> some unwieldy --with-tmp cmdline argument just because the portability
> layer doesn't want to answer a single portability question.
As you cannot use tmp file (handles) ?
DW
> > You are asking us to solve a problem but then saying that we can't solve
> > it completely. This is a bogus conversation and I am done with it.
>
> Yep, this whole thread started off real simple and has gotten totally out of
> hand.
That is because the problem/notion of a Temp directory as o
> Great job at ducking the question. It is really simple. The application
> needs to create a temporary file.
I think we agree on this. APR already does this; libc has done this for a
long time.
Solet it do that; preferably using the file descriptor; tmpfile() name
which has a very clear contr
On Mon, 9 Dec 2002, Aaron Bannert wrote:
..cut...
> Are they lock files, mmap/shared-mem files,
Now -these- I would dearly love to see 'disappear' inside APR.
Dw.
> Fine, then suggest another method for developers to find a system temp
> directory so that they can create a valid mask for use in
> apr_file_mktemp.
If they need more than a tmp file handle with a clear contract; i.e.
something like pseudo temporarly storage with semantics specific to their
ap
> No, that is a problem that YOU do not _need_ to solve. But, it is a
> problem that other developers have stated they do need.
Right - and I maintain that there are things best -not- done in a
'portability' layer. This is one of them.
..
> This is the first time that this support was requested
On Sun, 8 Dec 2002 [EMAIL PROTECTED] wrote:
> GR.
> Guys, please read all the messages. We HAVE that already! We have
GRRR...
> apr_file_mktemp, which returns an apr_file_t, but there are people saying
> that it isn't enough. They want to be given a filename instead of a
> handle.
On Sun, 8 Dec 2002, [ISO-8859-1] Wilfredo Sánchez wrote:
>Specifically, I think the API should return a filehandle, not a file
> name, to avoid the race condition I mentioned. I think that's
> worthwhile.
+1 to that.
Dw.
On Sat, 7 Dec 2002, Thom May wrote:
> How is the *portable* creation of temporary files a "function of dubious
> use"? Surely our mandate is portability. I'd argue that functionality like
> this should absolutely be in APR.
The portability layer is to facilitate porting; not to hide things whic
On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote:
> You are advocating that we use tempfile() to get a filename. At what
No; I am advocating to -NOT- (or at least grudgingly) give the naive app
develoepr the means to shoot the poor operations guy in the foot by
providing the developer a function of
pseudo name space
management along the lines of snprintf(..'%s/myapp.%d',tmpdir,getpid())
when an OS contract offers you better.
Dw
--
Dirk-Willem van Gulik
> Can a single temp directory be discovered by autoconf at build time and
> still apply for binary distributions? (Are there platforms where the
> same binary would work but the default temp dir might change?)
In any serious shop: Your run time system in production is generally !=
build system. A
On 6 Dec 2002 [EMAIL PROTECTED] wrote:
> Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
>
> > On Thu, 5 Dec 2002, Aaron Bannert wrote:
> >
> > > I don't like the idea of having environment variables drive things like
> > > this. Temp directories
> > Obviously, platforms that have a well-known temp directory could implement
> > their own apr_get_temp_dir to just return the correct string, but for
> > Unix platforms, there are three or four "correct" temp locations based on
> > platform and how the admin has things setup.
>
> True. That wou
On Wed, 4 Dec 2002, David Reid wrote:
> If we don't have such a declare maybe we should add one? I say this as
> htpasswd.c (in httpd) uses P_tmpdir that isn't portable and breaks the beos
> build. Also Thom found a note in his stdio.h file saying that it wasn't the
> right way to do things, and
On Thu, 5 Dec 2002, Aaron Bannert wrote:
> I don't like the idea of having environment variables drive things like
> this. Temp directories are a great way to get programs to write files
> wherever you want. I'd much rather have a function where the global
> tempdir can be set and then retrieved
Again - with corrected subject. My apologies.
On Mon, 14 Oct 2002, Dirk-Willem van Gulik wrote:
>
> In short: Cliff Woolley <[EMAIL PROTECTED]>
> has the largest number of votes.
>
> 21 voters casted votes.
> 3 duplicate submissions ignored.
>
In short: Cliff Woolley <[EMAIL PROTECTED]>
has the largest number of votes.
21 voters casted votes.
3 duplicate submissions ignored.
21 votes accepted as valid.
0 votes invalid/late/malformed/unreadable.
The full archive, including the MD5 tokens from the votin
t;[EMAIL PROTECTED]>
Cliff Woolley <[EMAIL PROTECTED]>
David Reid <[EMAIL PROTECTED]>
Dean Gaudet <[EMAIL PROTECTED]>
Dirk-Willem van Gulik <[EMAIL PROTECTED]>
Doug MacEachern <[EMAIL PROTECTED]>
Fred Sanchez <[EMAIL PROTECTED]>
Gr
Nominees for chair of the APR pmc:
Sander Striker <[EMAIL PROTECTED]>
It almost goes without saying, but it still has to be said:
Thanks Ryan! For all your efforts on APR, be it in code,
design, guidance, discussions and naming schemes ;). It's
kind of sad t
I apologize for the delay - and things will continue along the following
schedule, a week later than planned.
2002-9-30 Final candidate list send out.
Final voting roster send out.
If there are any issues - please
contact [EMAIL PROTECTED] as
On Mon, 16 Sep 2002, Greg Stein wrote:
> If for some godawful procedural non-purpose, you don't want to accept
> the contents of that file.
The reason for asking explitly for nominees now is that I could not find
anything like a 'deadline' or some other discriminatory element in the
past posting
D] Brian Pane
[EMAIL PROTECTED] Brian Pane
[EMAIL PROTECTED] Chuck Murcko
[EMAIL PROTECTED] Mike Pilato
[EMAIL PROTECTED] Ken Coar
[EMAIL PROTECTED] Dean Gaudet
[EMAIL PROTECTED] Dirk-Willem van Gulik
[EMAIL PROTECTED] Doug MacEachern
[E
Call for nominations for the Chair of the APR PMC.
The voting volunteers are ready to receive your nominations :-) Note that
the cutoff date is 2002-9-22.
You can either nominate yourself or you can nominate someone else.
What counts is that the confirmation from the nominee him/herself is
rece
xF88341D9)
Dirk-Willem van Gulik (0xEC140B81)
Seat: The machine daedalus.apache.org
is used as the mail relay, the time
reference and the mail folder with
all communication.
The procedure is as follows (cut off just before
read. Notice that qmail/ezmlm allows for using
<[EMAIL PROTECTED] to obtain historic messages.
Your volting volunteers,
Eric Cholet, Lars Eilebrecht and Dirk-Willem van Gulik <[EMAIL PROTECTED]>
On Thu, 29 Aug 2002, Jon Travis wrote:
> Any word on this?
These things take time... and it pays off to do them well. There is
absolutely no rush.
Dw
> I was thinking mostly along the lines that under the "web server project"
> there exists the HTTP specific entities, and a HTML parser would
Well - I am not sure where this APR (portability) or HTTP (hypertext
protocol) focus comes from; we have umpteen parsers and processers and
dommers and tr
> APR is whatever we want it to be. If we start building things on
> top of APR that are functionally distinct from other projects under
Actually; no - the Board gave the APR crowd a well defined charter (or
rather, the APR folks came with a very well defined set of things they
wanted to work on
Also - as long as the license is ASF like and/or the authros can be traced
- a project can live on the sourceforge, and, when for example a major
filter or somethign like mod_session or mod_jk/mod_webapp suddenly need
it- be merged in with code which needds such parsing.
Dw.
On Tue, 27 Aug 2002,
On Tue, 27 Aug 2002, Jim Jagielski wrote:
> Aaron Bannert wrote:
> >
> > On Tue, Aug 27, 2002 at 11:02:47AM -0400, Ryan Bloom wrote:
> > > I would prefer that this became it's own project either under the httpd
> > > project or the APR project. I don't believe that it should be a part of
> > >
Works 100% out of the box for me.
Dw.
On Fri, 23 Aug 2002, Jim Jagielski wrote:
> Am I totally on crack or are the versions in the 10.2 Dev tools
> actually functional? :)
>
Are the poll changes done (cvs update of 20.20 UTC):
/usr/bin/ld: Undefined symbols:
_apr_poll_revents_get
_apr_poll_setup
_apr_poll_socket_add
_apr_poll_socket_clear
_apr_poll_socket_mask
_apr_poll_socket_remove
_apr_socket_from_fil
We've got some of this in icconv/apr_xlate code. But it is far
from complete.
I've got some old code floating (google for C3 API for a rough idea)
around which does
-> utf 6|7|8 <-> unicode <-> specific_charset(languange)
based on approximation code tables from the unicode standard. I.e.
On 29 Oct 2001, Jeff Trawick wrote:
> Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes:
>
> > Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().
>
> since a couple of unices return EACCESS for the retriable
> somebody-else-has-the-l
Right now we are trapping EACCESS and moving it to 'EAGAIN' for a flock().
But on some platforms you can get things like EWOULDBLOCK and EINTR too.
In APR is there a convenient macro to figure out if the exit code is a
'hard' error (say EINVAL, EBADF, ENOTSUPP) or one to figure out if it is
a re
On Tue, 16 Oct 2001, Brian Pane wrote:
> * A "setn" variant that doesn't strdup the key (useful when,
> for example, the key is a compile-time constant)
Ha ! Thanks - I only now realize that that was what I needed the other
day. Great.
Dw
On Fri, 12 Oct 2001, Roy T. Fielding wrote:
> On Fri, Oct 12, 2001 at 05:22:04PM -0700, Dirk-Willem van Gulik wrote:
> > > > > Is there a way to ask APR what the granularity is ?
>
> Is it right to assume that the reason you need this is so that the httpd
> will mark
On Fri, 12 Oct 2001, Cliff Woolley wrote:
> > > Is there a way to ask APR what the granularity is ?
> >
> > All APR times are mSec.
>
> Yes, but if the OS stores only seconds for the mtime, the APR time is
> seconds*APR_USEC_PER_SEC, right? So while there are extra zeros at the
> end, that does
On Fri, 12 Oct 2001, Dirk-Willem van Gulik wrote:
> On some versions of Linux/Solaris fstat(2) gives you a second granularity
> of mtime/atime/ctime. On some other OS-es/versions you get mSec's.
>
> Is there a way to ask APR what the granularity is ?
Just to clarify - I wan
On some versions of Linux/Solaris fstat(2) gives you a second granularity
of mtime/atime/ctime. On some other OS-es/versions you get mSec's.
Is there a way to ask APR what the granularity is ?
Dw
> I will look at those, thank you! Notice one important bit. I am proposing
> we move
> our parser for rfc822 headers from httpd into apr-util. And I am proposing
> we add
> the parser to fracture a multipart/* mime type between parts (per rfc2046).
Yep :-) I noticed. Could you get me the Gr
Mime parsers are far from simple. See www.imc.org (The internet mail
consortsium is a good start) for various contenous interop effords. They
are horribly complex based.
C-Client from the IMAP consortsium is a good start; in the MIME faq you'll
find several others.
ftp://ftp.sunet.se/pub
> This _is_ a race condition. I reported this at the end of june on list.
> Subject: Possible race condition in pools WAS: RE: Thoughts on locks.
> At the end of the thread the conclusion was to fix it, most likely
> through documentation.
>
> Personally I think that locking on each allocation wi
It might be worthwhile to snarf some code from (Free)BSD to also deal
with ceases like 10.2 == 10.0.0.2 and similar 'abbreviations'.
Dw
On Mon, 23 Jul 2001, Doug MacEachern wrote:
> with a small number of vhosts configured, it takes ages for the server to
> start. the bottleneck is alloc_liste
You might have some use for moncontrol() and profil(). And then of course
you can do all sorts of gprof -X name to limit the depth of things. You
can also intentionally link against non profiled libraries to shut out
that part.
Dw
On Thu, 19 Jul 2001, David Reid wrote:
> OK, so strange question
Actually; I've just written this for an in-house experiment at covalent;
by just using function pointers. See attached hack to get an idea. It is
not ready for submittal - as it does not yet have sensible default choise.
Dw
On Fri, 22 Jun 2001, Jim Jagielski wrote:
> I've been toying with the i
Sander (Temme) and I have been working on this in the last two weeks;
basically it turns out that your best mutex stategy is not just a function
of the OS, but also of the (type of) load, the # of processors and the
speed of those processor's. In particuly - if your bottle neck is a high
mutex ra
You two guys might violently agree :-)
Asserts - when used properly - are very usefull tools to check for
conceptional bugs, But you should always assume that you compile for
production with the -NA, -DNDEBUG, -NOASSERT or your local relevant flags.
Production code which relies on assert()s are
On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
> On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
>
> > apr-util\buckets\apr_buckets_eos.c(84) : warning C4702: unreachable code
> >
> > Hopefully :-)
>
> That looks like a bug in the compiler. That code is definately reachable.
I struggled with th
> Dirk, no matter where you add the code, it is completely not portable, and
> the result is actually undefined. Some platforms zero out the timeout,
> others don't. Some leave the timeout alone, others subtract the elapsed
> time. Unless you include a bunch of autoconf macros to determine whic
On Sun, 1 Apr 2001 [EMAIL PROTECTED] wrote:
> There is no suitable function, and writing one is not possible. Many
> platforms zero out the timeout, so that we can't cleanly recalculate
> the new timeout.
>
No trouble - I'll add it to 'ab' then as a small inernal _send().
Dw
Am I right to understand that it is the designed intention of apr_send()
to do a best efford write to the network; it retries' on EINTR and under
certain conditions on EAGAIN/EWOULDBLOCK - but basically returns as soon
as something is writen (even if it is not all) - and waits once up till
Timeout
98 matches
Mail list logo
