Your mailer has wrapped this patch, making it un-applyable.
Also, you don't include a ChangeLog message or state the purpose of
the patch anywhere (at least not in this email). Why does
apr_hash_first() need a new implementation?
-Karl
Gunter Coelle [EMAIL PROTECTED] writes:
Index:
Branko ibej [EMAIL PROTECTED] writes:
Or gstein has suggested that apr_generate_random_bytes() can grow a
new flag, indicating urandom is preferred.
That would look weird to APR users on systems that have never heard of
/dev/random and /dev/urandom (several come to mind, all of which use \
Michael, in case you're not reading every thread, note that Mike
Pilato said:
[EMAIL PROTECTED] writes:
Oh, Release Manager -- can you put the 5202 change back into the
release, pretty please?
It's safe again :-).
Greg Stein [EMAIL PROTECTED] writes:
I've updated apr-util/include/apr_md5.h and crypto/apr_md5.c. The prototype
now takes a const void * for apr_md5_update() and apr_md5().
Yay!
The Problem:
Need a way to resume checksumming when appending to stored data.
Otherwise, we'd have to recompute the md5 context for all the data
already present, then continue with the same context as the new data
comes in.
If an MD5 digest could be reverted back to an unfinalized
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
All that said... You've been a major contributor to the successes of this
project, and I for one am sorry to see you step away, especially on this
note. I can only speak for myself, but your future participation and
contributions will be
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
Apparently this mental exercise didn't have the effects I had hoped.
Jeff's patch is correct; it isn't APR's job to determine if one can 'open'
a directory as a file. Opening a directory as a file isn't portable, no,
but we can't help the
Greg Stein [EMAIL PROTECTED] writes:
I'm with OtherBill: well said.
Do we have some code for this? Can we just get it checked in already? We've
got enough +1 votes for the new feature, and I haven't seen any vetoes on
the implementation of the feature, so let's just do the code...
It's just
Karl Fogel [EMAIL PROTECTED] writes:
It's just been waiting on Mike Pilato (or someone) having enough time
to implement it now, that's all. No procedural holdups remain,
agreed.
-Karl, speaking for Mike, who is perfectly capable of speaking for
himself, but it's me checking email
I think this patch is correct, but can someone more familiar with this
area (Bill Rowe?) please review? Thanks.
2002-12-12[EMAIL PROTECTED]
* file_io/unix/filestat.c: Check the `mode' variable to
determine the return type (follow up to revision 1.58).
Index:
Dirk-Willem van Gulik [EMAIL PROTECTED] writes:
Anything which does more than abstracting the pure OS but touches on an
instance of it I see as bad. And yes - if you draw the parallel to an
almost ridiclious extend; I do think exactly the same when I see
./Configure picking things up such as
Bill Stoddard [EMAIL PROTECTED] writes:
This is just a design difference. Most shells don't make a difference
between unset and NULL-value. This problem hasn't come up before, and
you haven't provided a concrete reason why it is broken now.
I agree with Aaron here.
Same. Hash
If there is disagreement among developers about what the APR
project(s) should do, then it has to be worked out like any other
disagreement. But using the charter as a *justification* for one's
position about APR's scope is circular, or at least semi-circular :-).
It's only appropriate to treat
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
Outch. This will hurt Win32 which has non-kernel errors going out to
wazoo (the high-bit set is a flag in and of itself.)
However, Win32 has several ranges reserved for app errors. If I can
change the offsets to insert our 'apr'/'app' errors
This patch expands the error ranges to hold 50,000 errors instead of
500, except for the USERERR range, which gets 500,000 to give apps a
lot of breathing room.
In Subversion, it was already clear that we were going to bump up
against the 500 limit eventually. And if we're expanding, heck, we
Jeff Trawick [EMAIL PROTECTED] writes:
Is anybody working on any of this? Am I confused about something?
1) APRUTIL_EXPORT_LIBS not used in Apache, so httpd won't load on some
platforms
2) apr_iconv_inbuf_const hints from apr_hints.m4 not migrated (to
where?)
3)
[EMAIL PROTECTED] writes:
Glancing through apr-util/xlate/xlate.c, I see tests and uses of both
APU_HAVE_APR_ICONV and APU_HAS_APR_ICONV. I'm not aware of the
conventions in place for choosing HAVE vs. HAS -- can someone fill me
in here? Or, if no such conventions exist, are just there bugs
Branko ibej [EMAIL PROTECTED] writes:
Anyway, the intent here is to tell the user what the APR
_implementation_ knows about the path encoding. On most platforms, APR
doesn't do anything with the paths, so we know that information can be
pulled from the locale. On Windows, we know when we'll
Branko ibej [EMAIL PROTECTED] writes:
Ho hum. Just noticed this wasn't Cc:'d to [EMAIL PROTECTED] ... Feel free to
add
that in the reply.
Sigh. Sorry, I made the obvious mistaken when replying the first
time. Here's my same mail again -- reply to *this* one, folks :-).
Translating that to
Bill,
- What's the status of the new apr-iconv library?
- What's status on the move of apr_xlate* to apr-util?
I'm asking for the Subversion Alpha release -- we'll need to know if
we can base the release on HEAD of apr and friends, or if we should
use last Monday's APR and ship the GNU
Is there any reason to prefer EINVAL to APR_EINVAL, or vice versa, in
apr_xlate_open()? I was just about to go document this case in
apr-util/include/apr_xlate.h, when the question occurred to me...
apr-util/xlate/xlate.c
revision 1.4
date: 2002/07/18 00:12:13; author: gstein; state:
Justin Erenkrantz [EMAIL PROTECTED] writes:
In APR calls, if EINVAL is produced, it should use APR_EINVAL.
And, for checking for error, the caller should use
APR_STATUS_IS_EINVAL(s). -- justin
Well, this is *us* generating the EINVAL by fiat, not getting it from
some lower-down system call.
Blair Zajac [EMAIL PROTECTED] writes:
Karl, can you help out here and check in a fix for this?
Hey, Blair, just an `ACK'. Thanks for the work; I'm following this
thread as a background process, will take a closer look as soon as I'm
done with issue #797, which is top priority right now (as it
Branko ibej [EMAIL PROTECTED] writes:
Karl, about the file name conversions in Subversion: remember what I
said about APR using UTF-8 file names directly on some platforms?
Well, the conversions in SVN should probably be coded like this:
Yeah, remember that. But does the platform-specific
When compiling Subversion, GCC now gives this warning whenever
apr_network_io.h is included:
/usr/local/apache2/include/apr_network_io.h:718: warning: \
declaration of `socket' shadows global declaration
The warnings result from these macros:
APR_DECLARE_INHERIT_SET(socket);
Cliff Woolley [EMAIL PROTECTED] writes:
This is not the kind of warning you would get at the preprocessor stage --
you'll only get this after macro expansion has already occurred. Sounds
like a legitimate bug in APR to me.
Oh, I see it now. The problem is that the expansions use the same
PROTECTED]
Reviewed by: Karl Fogel [EMAIL PROTECTED]
Index: i18n/unix/xlate.c
===
RCS file: /home/cvspublic/apr/i18n/unix/xlate.c,v
retrieving revision 1.26
diff -u -r1.26 xlate.c
--- i18n/unix/xlate.c 8 Jun 2002 18:53:13 -
Marcus Comstedt [EMAIL PROTECTED] writes:
These are policy questions, so they have to be discussed a bit more.
For the moment, only inexact translation is offered by apr_xlate
anyway, so there's no need to rush.
Agreed.
Sorry, folks, I accidentally CC'd a Subversion message to the APR list
a moment ago. Here is the message I *meant* to CC to [EMAIL PROTECTED]:
Marcus Comstedt [EMAIL PROTECTED] writes:
... avoid the call to iconv_open if both charsets are the same.
(That's not just an optimization, at least on
Ryan, I have nothing new to add, except: BRAVO, go for it. Test
suites have such a low sexiness-to-usefulness ratio, which probably
explains why no one wants to spend time on them :-). So when someone
does take it on, he should be fêted like a hero and given his choice
of prime beachfront
Ryan Bloom [EMAIL PROTECTED] writes:
Well, I still dislike having the APR_E*, but this would be fine with me.
I agree it's a tiny bit odd, but semantically I think it's the
cleanest thing to do.
I will commit this in Subversion first, then move it over to APR.
Currently, apr_check_dir_empty() is living in the Subversion source
tree. The implementation looks portable, though; is there any reason
not to move this into APR?
apr_status_t
apr_check_dir_empty (const char *path,
apr_pool_t *pool)
{
apr_status_t apr_err,
Ryan Bloom [EMAIL PROTECTED] writes:
This isn't portable. POSIX specifically states that you don't need to
return . or .., and APR doesn't make any comments about them.
Actually, APR does promise that . and .. will be returned, and
will be returned first, on all platforms.
See
Ryan Bloom [EMAIL PROTECTED] writes:
The docs may say that, but the code doesn't do anything about . and
... I just double-checked unix/dir.c. :-( I actually remember
looking at this years ago when I wrote the original code, and thinking
through the . and .. problem, which is why I said
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
One, the name sucks... perhaps apr_dir_is_empty()? Keep it named with the
other apr_dir_ family members and our general schema. We have to work hard
on consistency so we avoid symbol renames of newly created functions.
I've changed it to
Ryan Bloom [EMAIL PROTECTED] writes:
I am strongly against using APR_EEXISTS for this. APR_E* error codes
imply that something went wrong. In this case, it is a status code, not
an error code, and the APR convention is that ERROR codes start with
APR_E and STATUS codes start with APR_
Ryan,
Ryan Bloom [EMAIL PROTECTED] writes:
APR_DIR_EMPTY
Ryan
P.S. I am getting a say in the child's name, just not as big a say as
Kelly. :-)
You're naming your kid APR_DIR_EMPTY ??? You're crazy, man...
Ryan Bloom [EMAIL PROTECTED] writes:
Just use
APR_DIR_EMPTY
Btw, we needed the reverse sense. That is, if APR_EEXIST would have
indicated that the dir is not empty, then if we're not going to use
it, we should use APR_DIR_NOT_EMPTY instead.
The question is, should APR_SUCCESS indicate that
Why do pools even have a separate active block vs a list of old
inactive blocks? Especially now if we're going to start reusing
some of the inactive blocks anyway...
What about this:
- When palloc() requests some mem, see if there's any block with
enough unused room to handle it. If
Greg Stein [EMAIL PROTECTED] writes:
That algorithm won't work ... there is too much searching taking place.
The current pools code is way fast because it doesn't have to search for
blocks in the typical allocation case.
The pools code is quite sensitive. It is noticable if you add even one
Sander Striker [EMAIL PROTECTED] writes:
Also, consecutive blocks aren't joined together to form a bigger
block. In other words, you might have one big chunk of mem that could
satisfy your allocation, but the allocator won't see it and gets new
(unfragmented) mem.
For these issues patches
David Reid [EMAIL PROTECTED] writes:
What was the problem in subversion?
Might as well know before going too much further...
There was no technical problem -- just that the code was inconsistent.
Sometimes it used APR_STATUS_IS_SUCCESS(), sometimes it tested an
apr_status_t directly. New
Greg Stein [EMAIL PROTECTED] writes:
I've written up a document for how the APR projects' version numbering will
be handled (based on discussions from last year within the APR mailing
list), and I'm going to suggest that Subversion handles it exactly the same.
Please review the document at:
Greg Stein [EMAIL PROTECTED] writes:
You'll note down in the Other Notes area that I defined the versioning
document to live at a canonical URL for exactly this reason :-)
I did indeed :-).
Justin Erenkrantz [EMAIL PROTECTED] writes:
Due to some recent confusion with SVN and APR_STATUS_IS_SUCCESS,
I'd like to consider removing this macro and just forcing
everyone to do either a non-zero check or checking against the
APR_SUCCESS value (which isn't strictly needed because
Greg Stein [EMAIL PROTECTED] writes:
So my answer for this particular patch is:
* -1 for now(*), pending introduction of the versioning
* add a ref to the patch to the STATUS file for tracking
* when versioning is doc'd and implemented, then we add it
* httpd must specify *WHICH*
I'm planning to make the following functions return void instead of
apr_status_t:
apr_md5_init()
apr_md5_update()
apr_md5_final()
apr_md5_encode()
apr_md5() /* this one will get the obvious code tweak too */
They currently can only return success anyway, and it's hard to
[EMAIL PROTECTED] writes:
-We have md5's, md4's, sha1, et.al.
The all have this structure.
Just talking about the interfaces in apr_md5.h.
Anyway, unless someone is using a vtable to choose which checksum
function to use (?), it shouldn't matter that other interfaces do have
return
Bill Stoddard [EMAIL PROTECTED] writes:
Breaking API compatability is not something that should be taken
lightly. This is an issue with all users of APR, not just the http
server. I am not against the API changing if there is a compelling
reason for it. This change is light-years from
Jay,
I can partially answer your question.
Let's say there are three kinds of memory allocation in the world:
1. raw -- you know, like C malloc() and free()
2. pools
3. fully garbage-collected
For the programmer, full GC is ideal. Unfortunately, it takes time
for the GC code to
Is there maybe a bug in apr_palloc()? I'm not 100% sure of it yet;
been trying to find the source of this bug in Subversion itself, so
far unsuccessfully. Apologies that this reproduction recipe requires
building a patched Subversion; tried to come up with a smaller recipe,
but the bug didn't
William A. Rowe, Jr. [EMAIL PROTECTED] writes:
APR has nothing to solve.
Oh, of course -- I'm sorry, I wasn't thinking clearly.
The problem is that we rolled a tarball that has the Unix
line-ending style everywhere. If someone checks out apr/ on Windows
using CVS (say), they would get the
Blair Zajac [EMAIL PROTECTED] writes:
What about having a function that recursively walks the directory
structure and just calls a supplied callback function with the file
name. This looks like a simple way to implement this and it could
easily belong in APR.
That would be great! And then
Justin Erenkrantz [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2001 at 11:12:31AM -0800, Doug MacEachern wrote:
there needs to be a way to turn off db, gdbm, etc. for example:
--enable-dbm-only=sdbm (turn off everything except sdbm)
--disable-dbm=gdbm (turn off just gdbm)
doesn't
.
maybe a --disable-berkeley-db and a --disable-gdbm as well as a
--with-berkeley-db-inc/lib and --with-gdbm is required?
-Original Message-
From: Karl Fogel [mailto:[EMAIL PROTECTED]
Sent: Monday, December 10, 2001 12:03 PM
To: Justin Erenkrantz
Cc: Doug MacEachern; dev
Sander Striker [EMAIL PROTECTED] writes:
+* Add a string class that combines a char* with a length
+ and a reference count. This will help reduce the number
+ of strlen and strdup operations during request processing.
This doesn't belong in Apache, if anything it
Roy T. Fielding [EMAIL PROTECTED] writes:
Humm, I don't seem to be having much luck getting this autoconf
and libtool upgrade patch accepted. Is there a specific reason
this patch was not added? It does not require anything new
Yes, the patch makes a whole bunch of changes to the MM
(I'm posting this to both the APR and Subversion dev lists because
it's relevant to both.)
Summary reaction to Mo DeJong's recent autoconf work on both APR and
Subversion: +1.
Longer reaction:
If it's possible, for a time, to make APR work with both autoconf 2.13
and 2.50, that would really
Greg Stein [EMAIL PROTECTED] writes:
Not entirely true. It worked splendidly on my Linux box (otherwise, I
wouldn't have committed :-).
I should have said the build was broken on at least some BSD and some
Linux systems. :-)
-K
Ben Collins-Sussman [EMAIL PROTECTED] writes:
I think the the rule is: every fourth year is a leap year, BUT, every
century is not; BUT; every fourth century *is* a leap year. We've
got two levels of override here.
Yep, that's the rule as I've been taught it too.
David Reid [EMAIL PROTECTED] writes:
This was suggested by Carlos Hasan mailto:[EMAIL PROTECTED] but as I'm not
overly familiar with the hashing code I'm putting it forward rather than
committing it :)
Did he offer any particular justification for the change? :-)
I'm not saying it's bad or
[EMAIL PROTECTED] writes:
We are asking for data that is const char * const *, but passing in
char * const * data. This causes incompatible pointer type warnings when
compiling Apache.
In that case, it seems appropriate to cast the data being passed in --
adding more const is always okay.
Greg Hudson [EMAIL PROTECTED] writes:
Oh, right. Same standards as subversion, I take it? It's at the end
of this message.
Not what I meant to imply -- actually, I don't know exactly what the
APR standards are in that regard. I was just asking for the log
message for my own sake, so it would
Yes, I am getting this problem too. :-( And my client is CVS version
1.10.8.1 (the server at apache.org is 1.11).
I'll look into it when get a chance; APR setup folks, any ideas?
-K
Branko =?ISO-8859-2?Q?=C8ibej?= [EMAIL PROTECTED] writes:
Is anybody else seeing the follwing with cvs update
[EMAIL PROTECTED] writes:
Here is exactly what I will be doing. If anybody sees a problem with
this, TELL ME NOW, PLEASE! If nobody sees a problem, I do this at
12:00. :-)
The plan looks good.
I created a many-subdir-level test project under CVS here, and tested
your recursive removal
Currently, one must path *both* a short-options string and an array of
apr_getopt_long_t structures to apr_getopt_long().
This seems redundant. If one's program supports long options, then
the long opts will need to be initialized anyway. In that case, any
given equivalent short opt ought to be
Greg Hudson [EMAIL PROTECTED] writes:
/* An array of single-letter options, any of which is equivalent to
this long option, terminated by '\0'. */
const char *short_equivs;
How do you then specify short options with no long equivalent, or long
options with no short
I don't have `sudo' on locus. Can someone please do:
locus$ cd /home/cvs/apr/i18n
locus$ sudo chgrp -R apr .
locus$ sudo chmod ug+rwx `find . -type d`
This is due to:
cvs server: Updating i18n/unix/iconv
cvs server: failed to create lock directory in repository
68 matches
Mail list logo
