On 22 August 2015 1:56:04 am AEST, Stefan Fritsch s...@sfritsch.de wrote:
gpg: key 4DAA1988: public key Bojan Smojver bo...@rexursive.com
imported
Feel free to remove mine.
--
Bojan
On Thu, 2013-05-30 at 00:06 +0200, Graf László wrote:
bufp = apr_palloc(r-pool, len);
bufp = buf;
What is the point of the above code? First some memory is allocated for
bufp, then it is ignored, as bufp actually becomes a pointer to the buf
array...
As for the
On Sat, 2012-07-14 at 11:27 +1000, Danny wrote:
Patch to more clearly describes how the apr_dbd_p[v]bquery/select
functions work.
I looked at the code of the drivers now and as far as I can tell, they
actually work the way they are described already. They indeed take
apr_size_t pointer when
On Wed, 2012-04-25 at 21:38 +0200, John Spencer wrote:
a) it does the check twice if the first test succeeds, wasting
precious time
b) it uses sizeof(( $2 )) in the second ac_fn_c_try_compile invocation
which is invalid C
From what I can tell, both of these things are the consequence of the
On Sun, 2012-03-25 at 22:36 +0200, Graham Leggett wrote:
[+1] Release apr-util 1.4.2 as GA
All tests pass on F-16, x86_64, with and without --disable-util-dso.
Good signature and checksums.
--
Bojan
On Wed, 2012-02-08 at 10:33 +1100, Bojan Smojver wrote:
[+1] Release apr 1.4.6 as GA
All tests pass on F-16 x86_64.
--
Bojan
Apache Portable Runtime 1.4.6 Released
The Apache Software Foundation and the Apache Portable Runtime
Project are proud to announce the General Availability of version
1.4.6 of the APR Apache Portable Runtime library.
APR 1.4.6 addressed hash collisions DoS problem.
(See
On Mon, 2012-02-13 at 16:43 +1100, Bojan Smojver wrote:
so I'll move this to release
I'll update the site once the mirrors pick up the release.
--
Bojan
On Wed, 2012-02-08 at 10:33 +1100, Bojan Smojver wrote:
[ ] Release apr 1.4.6 as GA
I see this pickled in dev for a while now and got sufficient number of
+1s (thank you all!), so I'll move this to release when I find a few
moments to spare.
--
Bojan
--- Original message ---
From: Jeff Trawick
Please use clean builds of the the autoconf and libtool versions that
Graham used. I hate seeing the autotools versions jumping around as
different people handle TR.
These clean tools don't look so clean on my box, so I think I'll hold
On Tue, 2012-02-07 at 16:42 +0200, Graham Leggett wrote:
Has anyone gone through the warnings to determine if the warnings
should cause concern?
AFAICT, they are all benign warnings like this
AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body:
On Tue, 2012-02-07 at 07:18 -0500, Jeff Trawick wrote:
Please use clean builds of the the autoconf and libtool versions that
Graham used. I hate seeing the autotools versions jumping around as
different people handle TR.
Just for the record, autoconf in F-16 is the same version as vanilla
On Tue, 2012-02-07 at 22:09 +0100, Rainer Jung wrote:
There is no analogous change for apr-util, but as far as I remember
those warnings did not exist for apr-util. Bojan please correct me if
your experience is different.
I haven't tried apr-util spin yet, to be honest. We'll cross that
On Wed, 2012-02-08 at 08:02 +1100, Bojan Smojver wrote:
Libtool is slightly ahead: 2.4 v 2.2.4, but this is not where the
warnings are coming from (mostly).
Actually, that is not correct. If I use 2.2.4 instead of built-in 2.4, I
do get warnings and they do come from the files contributed
On Tue, 2012-02-07 at 17:00 -0500, Jeff Trawick wrote:
Using the slightly patched tool(s) from Fedora seems like a pain for
others to reproduce exactly, whereas anyone can install autotools of
arbitrary versions on arbitrary non-Windows machines in just a few
minutes
So, you want me to keep
Tarballs/zipballs are at http://apr.apache.org/dev/dist/.
Various fixes in there, including hash randomisation, so give it a good
bashing.
Please give your +1/-1:
[ ] Release apr 1.4.6 as GA
PS. Please don't shoot to RM. First timer here... :-)
--
Bojan
What version of autoconf should I have for rolling releases of APR? I'm
getting quite a few warnings and errors with the default on F-16, so I'm
guessing I have to go a bit back, but what to exactly escapes me now...
--
Bojan
On Mon, 2012-02-06 at 18:47 -0500, Ronen Mizrahi wrote:
For the time being we resolved it by adding an if not NULL statement
before invoking the cleanup function however I am not sure that a NULL
cleanup function is allowed or by itself represents some kind of an
issue.
Have you tried
On Mon, 2012-02-06 at 19:00 -0500, Ronen Mizrahi wrote:
Only in the child process we run into this issue and we cannot change
the registrations of cleanup functions in the child process since the
crash occurs somewhere between the invocation of fork() and the
invocation of exec().
Best thing
On Mon, 2012-02-06 at 19:06 -0500, Jeff Trawick wrote:
Use whatever was used for apr-util 1.4.1 in order to avoid surprises.
OK.
I think that is autoconf 2.68 (says configure)
Yeah, that's what I have on F-16, which gives me plenty of warnings.
and libtool 2.2.4 (says
On Mon, 2012-02-06 at 19:14 -0500, Jeff Trawick wrote:
Can you post?
This is what I get when I run the release.sh script against 1.4.5 tag:
--
buildconf: checking installation...
buildconf: python version 2.7.2 (ok)
buildconf: autoconf version 2.68 (ok)
buildconf: libtool version
On Tue, 2012-02-07 at 00:43 +, Graham Leggett wrote:
The versions I used to roll apr-util v1.4.1 were vanilla builds, built
from pristine source, as opposed to the packages shipped with FC-17 or
MacOSX.
Tried with that on my F-16 machine and got similar warnings. Also got a
tarball that
On Tue, 2012-02-07 at 11:31 +1100, Bojan Smojver wrote:
This is what I get when I run the release.sh script against 1.4.5 tag
Interestingly, if I rework release.sh to use branches instead of tags
and give it 1.4.x as an argument, everything turns out clean with F-16
defaults
Time permitting, I'll attempt a tag/release of 1.4.6 soonish. So, if you
have stuff you'd like to see there, please commit, backport etc.
Not sure whether folks would like to see APR-Util 1.4.2 as well. Version
numbers are cheap, so we may as well do it.
--
Bojan
On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
It looks like this was fixed in APR in December 10, 2010 for unix
platforms:
http://svn.apache.org/viewvc?view=revisionrevision=r100
If Mladen (the author of the patch) doesn't pick this up and backport,
I'll do it tonight.
On Mon, 2012-01-30 at 10:22 +, Philip Martin wrote:
It was reverted because it means the hash table data is not available
in pool cleanup handlers
I guess it should then be reverted on the 1.5.x branch as well.
--
Bojan
--- Original message ---
From: Jim Jagielski
Any intent to TR apr 1.4.6 to address this issue?
Wasn't really thinking of it, but if it would help, sure. A bit short on
time today due to work stuff though.
--
Bojan
0.9.21
+ *) Security: oCERT-2011-003
+ Randomise hashes by providing a seed.
+ [Bojan Smojver, Branko Čibej, Ruediger Pluem et al.]
Changes with APR 0.9.20
Index: tables/apr_hash.c
===
--- tables/apr_hash.c (revision
--- Original message ---
From: Ruediger Pluem
Don't we have the same issue here as with the XOR version of the patch?
If two different keys (key1, key2) result in the same hash value (so
ht-hash_func(key1, klen1) == ht-hash_func(key2,
klen2);) doesn't hashfunc_default result in the
--- Original message ---
From: Branko Čibej
A good, seeded cryptographic hash function would scatter the values much
better than this does.
Just to make the hash more resistant to having the same content in upper bits
(because we start from a common random seed), we could run the
On Mon, 2012-01-30 at 02:22 +1100, Bojan Smojver wrote:
we could run the hash value produced by hashing the strings through
the hash function twice
Like this.
--
Bojan
Index: tables/apr_hash.c
===
--- tables/apr_hash.c (revision
On Sun, 2012-01-29 at 20:23 +0100, Branko Čibej wrote:
This is overkill.
Possibly. I'm going to run some tests to see whether I get final hashes
that have similar upper bits.
--
Bojan
On Mon, 2012-01-30 at 09:37 +1100, Bojan Smojver wrote:
I'm going to run some tests to see whether I get final hashes
that have similar upper bits.
The test reveals that many upper bits are the same without the latest
patch. With my latest patch, I get that fixed (i.e. the final hash
On Mon, 2012-01-30 at 09:59 +1100, Bojan Smojver wrote:
With my latest patch, I get that fixed (i.e. the final hash is
perturbed a lot better).
Hmm, different problems emerge. The hash then has a tendency to produce
either all odd or even indexes (i.e. lower bits used to address
buckets).
I
On Mon, 2012-01-30 at 10:15 +1100, Bojan Smojver wrote:
I think I'll need to work on a different approach.
Reverting r1237078 is the answer. We should not be hashing the hash,
only the original strings, using the random seed.
Obviously, folks using custom hash functions will have to come up
On Tue, 2009-09-22 at 20:06 +, minf...@apache.org wrote:
URL: http://svn.apache.org/viewvc?rev=817809view=rev
Log:
The implementation of expand_array() in tables/apr_hash.c allocates
a new bucket array, without making any attempt to release the memory
allocated for the previous
On Sat, 2012-01-28 at 11:37 +0100, Branko Čibej wrote:
Seeding the hash function is effectively the same as using the hash
function's output to seed the randomizer, right?
Yeah, randomiser function would have to be something other than simple
xor or similar. The modulo that is used for
--- Original message ---
From: Bojan Smojver
If you can think of a nice function that does that,
Actually, I can think of one - the internal hash function I introduced in
the latest commit. We can simply pass the hash done by the regular hash
function into it and treat
On Sat, 2012-01-28 at 11:37 +0100, Branko Čibej wrote:
rerun the result + seed through the built-in hash function
Hopefully r1237078 should do something like that now. I completely
missed this part of your reply, to be honest, so I had to do a bit of
NIH of my own. Reading things on a tiny
--- Original message ---
From: Branko Čibej
But the original code is already wrong in assuming that res-hash_func
and overlay-hash_func are the same, so in fact you're silently fixing a
bug with the current change. :)
Surprisingly enough, I actually thought about this bit. Surely
--- Original message ---
+hash = ht-seed ^ ht-hash_func(key, klen);
Actually, when I think about this, it will probably be inefective. If two
keys produce the same hash, the xor-ed value against the seed will most
certainly be the same as well. So, this won't actually do anything
--- Original message ---
From: Branko Čibej
- hash = ht-hash_func(key, klen);
+ hash = randomize_hash(ht, ht-hash_func(key, klen);
Completely private change that leaves hash_func_t unchanged.
Interesting approach. So, randomize_hash() would then perturb (xor or
something) what the
--- Original message ---
From: Branko Čibej
Correct. I intentionally left out the implementation, since i don't
really have an opinion about how it should be done. I just wanted to
point out that there's a simple way to add per-table randomization
without changing any of the existing
On Fri, 2012-01-27 at 00:36 +1100, Bojan Smojver wrote:
Thanks, will implement.
Attached. If nobody comes up with regressions or other problems with
this approach, I'll commit it to trunk.
Thanks everyone for their input.
--
Bojan
Index: tables/apr_hash.c
--- Original message ---
From: Ruediger Pluem
Shouldn't you store the result of res-hash_func /
apr_hashfunc_default_internal in a local temporary
variable and use it later on? Otherwise you change the overlay hash and
may make it unusable by setting a new hash
value. IMHO all
On Thu, 2012-01-26 at 09:05 +1100, Bojan Smojver wrote:
Will fix.
Better?
--
Bojan
Index: tables/apr_hash.c
===
--- tables/apr_hash.c (revision 1235978)
+++ tables/apr_hash.c (working copy)
@@ -18,6 +18,7 @@
#include
On Mon, 2012-01-16 at 14:11 +0100, Ruediger Pluem wrote:
r1231605 and r1231858 cause massive regressions and test case failures
in httpd. Not sure why right now.
Could you please run your tests with this patch. Let me know how it
goes. Thanks.
--
Bojan
Index: tables/apr_hash.c
--- Original message ---
From: Joe Orton
(hash(key) * ht-pure_random_number) % ht-max
where ht-max is 15 by default. So you merely have to increase the
size of the input by 15 to produce at least the same overhead; the
attacker must generate 15n keys to ensure they hit all the
On Sun, 2012-01-15 at 18:06 +0100, Bert Huijben wrote:
If the timer has enough detail we could just use the time, ptr
combination as the seed here.
See whether you like r1231858.
--
Bojan
--- Original message ---
From: Ruediger Pluem
r1231605 and r1231858 cause massive regressions and test case failures in
httpd.
I won't be able to commit for a while. Please feel free to revert both.
Sorry about the breakage. :-(
--
Bojan
--- Original message ---
From: Bojan Smojver
Sent: 17.1.'12, 5:18
--- Original message ---
From: Ruediger Pluem
r1231605 and r1231858 cause massive regressions and test case failures
in httpd.
I won't be able to commit for a while. Please feel free to revert both.
Sorry
--- Original message ---
From: Bojan Smojver
Sent: 17.1.'12, 5:18
--- Original message ---
From: Ruediger Pluem
r1231605 and r1231858 cause massive regressions and test case failures
in httpd.
I won't be able to commit for a while. Please feel free to revert both.
Sorry
On Sun, 2012-01-15 at 18:06 +0100, Bert Huijben wrote:
If you call srand() before every call to rand() the result is no longer
random.
Yes, I'm aware of that.
And in this case we do this inside a shared library, so this might introduce
other attack vectors in applications that use apr.
On Mon, 2012-01-16 at 08:38 +1100, Bojan Smojver wrote:
That is true. In fact, my first code to the list just used ht. We
could use ht and time to get random values. Same attack vectors as
noted by you above apply, of course.
Maybe like this?
--
Bojan
Index: tables/apr_hash.c
On Sat, 2012-01-14 at 14:50 +1100, Bojan Smojver wrote:
Yeah, that's probably what we'll have to do.
Gone bold and committed that in r1231605. Feel free to improve,
criticise, rip out etc.
--
Bojan
On Thu, 2012-01-12 at 19:58 -0800, Chris Darroch wrote:
+if (strcmp(DEV_RANDOM, /dev/random) != 0
+apr_generate_random_bytes((unsigned char *)ht-seed,
+ sizeof(ht-seed)) != APR_SUCCESS)
This probably wouldn't work as expected. If you had
On Fri, 2012-01-13 at 19:57 +1100, Bojan Smojver wrote:
This probably wouldn't work as expected. If you had /dev/random
selected for DEV_RANDOM, the if would fail and srand()/rand() bit
would never get called. No?
Like attached maybe?
--
Bojan
Index: tables/apr_hash.c
--- Original message ---
From: Chris Darroch
I'd personally rather see the use of it dropped entirely in all cases
and the code Bojan worked on as the fallback case always used, since
it adds no significant complexity and appears in line with other
solutions,
such as the one in
--- Original message ---
From: Chris Darroch
Please test and improve!
Thanks Chris!
--
Bojan
On Tue, 2012-01-10 at 15:29 -0800, Chris Darroch wrote:
Without having tested explicitly, it looks like the default case for
modern Linux is APR_HAS_RANDOM=1 and DEV_RANDOM=/dev/random,
with /dev/random blocking when there's no entropy.
Don't think so (run on my F-16 machine, without passing
On Tue, 2012-01-10 at 15:29 -0800, Chris Darroch wrote:
The patch might also need to account for the !APR_HAS_RANDOM case,
now that I look again.
Yes, true.
So I'm less than certain what to suggest here ...
We can always use ANSI C rand()/srand() (racy) or even other APR random
On Tue, 2012-01-10 at 16:04 -0800, Chris Darroch wrote:
I guess the question is what happens if /dev/random
is chosen, though, either automagically or through an explicit choice
with --with-devrandom=/dev/random.
I can tell you from experience - your program stalls a lot. And I mean,
A LOT.
On Tue, 2012-01-10 at 15:29 -0800, Chris Darroch wrote:
I don't know if any of that is useful for APR, but there it is.
There is a function a bit like this in APR: get_random_info() in
crypto/getuuid.c. Essentially, if there is no
apr_generate_random_bytes(), then do the magic.
--
Bojan
On Wed, 2012-01-11 at 11:01 +1100, Bojan Smojver wrote:
We can always use ANSI C rand()/srand() (racy)
This is what I meant. Some code stolen from crypto/getuuid.c.
--
Bojan
Index: tables/apr_hash.c
===
--- tables/apr_hash.c
On Fri, 2012-01-06 at 10:52 +1100, Bojan Smojver wrote:
+if (apr_generate_random_bytes(
+(unsigned char *)ht-seed, sizeof(ht-seed)) != APR_SUCCESS)
+return NULL;
Chris,
What I mean is, instead of return NULL, we could have ht-seed =
(unsigned int) ht. Not as random
On Thu, 2012-01-05 at 11:45 -0600, William A. Rowe Jr. wrote:
Should we add some randomization to prevent abuse?
There are Ruby patches in RH bug database that may help as an example:
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2011-4815
--
Bojan
On Thu, 2012-01-05 at 11:45 -0600, William A. Rowe Jr. wrote:
Should we add some randomization to prevent abuse?
No idea whether this is something that may be useful, but here it is
nevertheless. At least it can be used as an example of what not to
do. :-)
--
Bojan
Index: tables/apr_hash.c
On Thu, 2012-01-05 at 16:39 -0600, William A. Rowe Jr. wrote:
Question; do we want each hash to have a unique randomization factor?
That would probably be more secure. As is, seed would be initialised
just once per process.
The apr_hashfunc_t function prototype would then most likely have to
On Fri, 2012-01-06 at 09:48 +1100, Bojan Smojver wrote:
The apr_hashfunc_t function prototype would then most likely have to
change. We'd probably need to pass the hash itself into it, which
would then hold the per-hash seed. Right?
Actually, that would not be a good plan. A custom hash
On Fri, 2012-01-06 at 10:05 +1100, Bojan Smojver wrote:
Any other ideas?
Maybe like this?
--
Bojan
Index: tables/apr_hash.c
===
--- tables/apr_hash.c (revision 1227896)
+++ tables/apr_hash.c (working copy)
@@ -75,7 +75,7
--- Original message ---
From: Ignaz Birnstingl ign...@gmail.com
Now if I use APR
(pseudo code)
char *foo = apr_env_get(foo);
char *bar = apr_env_get(bar);
if apr_env_get would pstrdup the string returned by getenv I could
compare foo with bar, like this if (strcmp(foo, bar) == 0) ...
--- Original message ---
From: Jeff Trawick trawick gmail.com
Is the end result that the test previously failed to find
ldap_set_rebind_proc() but now works with GCC 4.6? If so, that's what
CHANGES should say. (We quietly fix warnings all the time; my
semi-educated guess is that
On Mon, 2011-08-08 at 10:32 -0400, Jeff Trawick wrote:
Yes :)
Something like:
Fix a failure of configure to detect ldap_set_rebind_proc(),
encountered on Fedora Core 15 with gcc 4.6.
Done.
BTW, apr-util 1.4.x/CHANGES is only for fixes/features not in the
1.3.x series, since 1.4.x has
On Mon, 2011-06-06 at 17:53 -0500, William A. Rowe Jr. wrote:
I am still waiting for your answer to who the other consumers are of
apr_ldap.
I guess this will be hard to say. Do we track everyone that uses APR
APIs? Or did you mean just the open source projects out there?
--
Bojan
On Thu, 2011-05-19 at 11:08 -0400, Jeff Trawick wrote:
[+1] Release apr-util 1.3.12 as GA
All tests passed on F-14 x86_64, against APR 1.4.5.
--
Bojan
On Thu, 2011-05-19 at 20:20 -0400, Jeff Trawick wrote:
[+1] Release apr 1.4.5 as GA
All tests passed on F-14 x86_64.
--
Bojan
On Wed, 2011-05-18 at 07:23 +0200, Rainer Jung wrote:
If noone beats me to it, I will care about this one (and checking for
possible similar cases) over the weekend.
This has been fixed.
http://svn.apache.org/viewvc?view=revisionrevision=1101301
--
Bojan
On Tue, 2011-05-03 at 15:22 -0400, Jeff Trawick wrote:
[+1] Release apr 1.4.3 as GA
All tests passed on Fedora 14, x86_64. And apr-util 1.3.11 also passed
tests when linked to it (note: again, no DB tests).
--
Bojan
On Thu, 2011-04-14 at 19:55 -0400, Jeff Trawick wrote:
[+1] Release apr-util 1.3.11 as GA
Fedora 14, x86_64, all tests passed.
Note, didn't run DB tests, so maybe that should be like +0.1. Linked
against APR 1.4.2.
--
Bojan
Ok, so this is confusing me a little - how would it even run a test
being a mingw cross compiled program (host is linux)?
Honest answer is that I never even tried this (I only ever compile APR on
Unix/Linux). I just see in my configure script that under certain
circumstances these code
On Thu, 2010-11-25 at 15:16 +0900, Daniel Stonier wrote:
ac_cv_sizeof_off_t=4^M
ac_cv_sizeof_pid_t=4^M
Are you saying that these are \r (ASCII 13) characters? This could be
related to fprintf() from the test printing out \r\n instead of just \n
on your platform. Maybe the file should be opened
Also run into another problem with the mingw cross-compiler - it
simply refuses to build shared libs, despite setting --disable-static
and --enable-static when running ./configure. What might be disabling
it?
No idea about that one, to be honest.
--
Bojan
On Tue, 2010-11-02 at 09:48 -0400, Jeff Trawick wrote:
require a subscription before posting
+1
--
Bojan
On Wed, 2010-10-06 at 14:26 -0500, William A. Rowe Jr. wrote:
[ ] Rename 1.5.x to trunk
jorton, rjung, minfrin, trawick, jim
[ ] apr/ is 'apr-util/ trunk', stub apr-util/trunk with guidance
wrowe, niq, henryjen, poirier
Here is a stupid idea: why don't we have both? We can
On Thu, 2010-09-02 at 09:15 +0200, Guenter Knauf wrote:
hmm, I thought adding a function is not a problem - only
changing/removing - or?
Adding is a problem too. If someone links against newer minor version,
this program should work against older minor version too. However, older
minor
On Thu, 2010-09-02 at 10:57 +0200, Branko Čibej wrote:
However, you certainly cannot retroactively add a function to 1.4.x
that was not already present in 1.5.0. So I expect you meant micro
version above, rather than minor version.
I meant that 1.4.x and 1.4.y have to have the same set of
On Fri, 2010-05-21 at 00:29 -0400, Philip M. Gollucci wrote:
What happened to it ? Whats the new thing ?
No new thing. Just decided to drop it.
--
Bojan
On Thu, 2010-04-08 at 00:37 +0100, Nick Kew wrote:
Who do you have in mind, or are you suggesting a blanket commit?
For instance, Hyrum K. Wright submitted a patch for apr_hash and asked
about it a few times. My understanding is that he's a Subversion
committer. Instead of him waiting for some
On Sat, 2010-03-13 at 17:54 +0200, Graham Leggett wrote:
Based on what you've written above, the #else ENOTIMPL seems to be the
way to go. If it isn't supported, you get explicit confirmation of the
fact
Probably the safe thing to do. Probably won't get many hits, but
nevertheless.
--
Bojan
On Fri, 2010-03-12 at 13:30 +, Joe Orton wrote:
I'd expect to see some description of exactly what the new APR_FOPEN_*
flag changes w.r.t. method calls; does it affect just read/write, what
about flush, sync, etc? Can I presume POSIX semantics w.r.t.
O_NONBLOCK in open()? The questions
On Tue, 2010-03-09 at 12:48 -0500, Jeff Trawick wrote:
IMO these functions are a natural addition; any concerns from the
crowd?
Didn't SVN folks also have some hash sorting functions we could borrow
as well? May as well get those, while we're at it :-)
--
Bojan
On Tue, 2010-03-09 at 15:45 -0600, Hyrum K. Wright wrote:
We also have a couple of hash- and array-based iteration functions
which might be handy. I can post those if there is interest.
Yep, let's raid the SVN treasure chest :-)
--
Bojan
On Sat, 2010-02-06 at 20:47 -0500, Jeff Trawick wrote:
[+1] Release apr-1.3.12
Signatures look good. Checksums looks good.
All tests pass on Fedora 12, i686.
--
Bojan
On Thu, 2010-02-04 at 17:44 -0500, Bob Rossi wrote:
Is this a design decision or a flaw?
Design decision.
Just to be clear, you are getting segfaults when you are NOT passing
pointers in, correct? If you are doing that, you are misusing the API
and causing the segfaults.
--
Bojan
On Thu, 2010-02-04 at 18:06 -0500, Bob Rossi wrote:
If you are bent on preserving this interface, does a new interface
make sense, that allows the user to pass in the parameters,
without passing in addresses?
Nobody is bent on anything, although there were reasons to do it this
way (search
On Thu, 2010-02-04 at 18:14 -0500, Bob Rossi wrote:
OK, do you like what I'm suggesting? An interface that takes a
va_list, that behaves just like printf...
If you like it, what would you like the name of the function to be
called? Any pointers?
No opinion, to be honest, because I rarely
On Wed, 2010-01-27 at 13:40 +0800, liuxulin wrote:
Is there anything wrong?
Without going into details, compile the thing (your program and APU)
with -g and -O0, then run it with gdb and step all the way through to
see where the failure actually occurs. This will give you a better
indication as
On Thu, 2010-01-07 at 16:12 +0100, Bert Huijben wrote:
In r817810 a change to the hash table implementation was introduced
Graham,
Can we have this and r817809/r817806 reverted please?
--
Bojan
On Thu, 2010-01-07 at 16:26 +0100, Ruediger Pluem wrote:
This sounds like a valid point.
+1
I would propose to revert r817810 / r817809 (for 1.3.x / 1.4.x) and
only keep r817806 (trunk). Graham?
IMHO we can backport this again later if the problem is sorted out in
trunk.
I think we should
On Thu, 2010-01-07 at 11:00 -0800, Neil Conway wrote:
Well, the suggested fix of using a sibling pool to the hash table's
pool would work, I think -- I'd be happy to prepare patches to
implement that.
What would you hang the destruction of the array_pool against? The
parent pool? If so, we
1 - 100 of 930 matches
Mail list logo
