Re: uuid generation on linux boxes
Ian Holsman <[EMAIL PROTECTED]> writes: > I have a issue with a linux box not having enough entropy and hanging > on a call to apr_uuid_get (as it calls /dev/random) > > I was wondering why we don't just use /proc/sys/kernel/random/uuid > and use that for our uuid? If you are building APR yourself, I believe you can pass --with-devrandom=/dev/urandom to its configure script to solve this problem.
uuid generation on linux boxes
I have a issue with a linux box not having enough entropy and hanging on a call to apr_uuid_get (as it calls /dev/random) I was wondering why we don't just use /proc/sys/kernel/random/uuid and use that for our uuid? also.. as a side topic to the linux gurus out there.. is there any way of generating/adding entropy to /dev/random so it can unblock? TIA Ian
Re: cvs commit: apr/random/unix apr_random.c
Ben Laurie wrote:
BTW, on the subject of bitfield gotchas, never make boolean fields
signed - why? Coz:
struct x { signed int onebitfield:1; } x;
signed int someint;
x.onebitfield=TRUE;
someint=TRUE;
assert(x.onebitfield == someint); /* SPLAT!!! */
:)
Re: cvs commit: apr/random/unix apr_random.c
[EMAIL PROTECTED] wrote:
> trawick 2003/11/06 08:26:09
>
> Modified:random/unix apr_random.c
> Log:
> fix an odd portability issue:
>
> Bit-field foo must be of type signed int, unsigned int or int.
Thanks.
BTW, on the subject of bitfield gotchas, never make boolean fields
signed - why? Coz:
struct x { signed int onebitfield:1; } x;
signed int someint;
x.onebitfield=TRUE;
someint=TRUE;
assert(x.onebitfield == someint); /* SPLAT!!! */
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
Re: cvs commit: apr configure.in
On Nov 6, 2003, at 8:55 AM, Joe Orton wrote: On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote: What is this and the APR_IS_BIGENDIAN macro used for? Do we have any code that is endian-dependent? $ grep -l -r --include \*.c APR_IS_BIGENDIAN . ./random/unix/sha2.c Ah, I didn't pick up the new directory in my last cvs update, so I didn't see it. Thanks. I don't understand the use of REVERSE32, why isn't htonl() and ntohl() used? And for REVERSE64, is there a longword version of h-to-n/n-to-h that we could use instead? -aaron
Re: cvs commit: apr configure.in
On Thu, Nov 06, 2003 at 08:27:57AM -0800, Aaron Bannert wrote: > What is this and the APR_IS_BIGENDIAN macro used for? Do we have > any code that is endian-dependent? $ grep -l -r --include \*.c APR_IS_BIGENDIAN . ./random/unix/sha2.c > On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED] wrote: > > jorton 2003/11/06 01:18:22 > > > > Modified:.configure.in > > Log: > > * configure.in: Fix endianness detection with autoconf 2.1x.
Re: cvs commit: apr configure.in
What is this and the APR_IS_BIGENDIAN macro used for? Do we have any code that is endian-dependent? -aaron On Thu, Nov 06, 2003 at 09:18:23AM -, [EMAIL PROTECTED] wrote: > jorton 2003/11/06 01:18:22 > > Modified:.configure.in > Log: > * configure.in: Fix endianness detection with autoconf 2.1x. > > Revision ChangesPath > 1.551 +7 -2 apr/configure.in > > Index: configure.in > === > RCS file: /home/cvs/apr/configure.in,v > retrieving revision 1.550 > retrieving revision 1.551 > diff -u -u -r1.550 -r1.551 > --- configure.in5 Nov 2003 15:32:28 - 1.550 > +++ configure.in6 Nov 2003 09:18:22 - 1.551 > @@ -1188,8 +1188,13 @@ >pid_t_fmt='#error Can not determine the proper size for pid_t' >fi > > -dnl Checks for endianness > -AC_C_BIGENDIAN([bigendian=1],[bigendian=0]) > +# Checks for endianness > +AC_C_BIGENDIAN > +if test $ac_cv_c_bigendian = yes; then > +bigendian=1 > +else > +bigendian=0 > +fi > ># Basically, we have tried to figure out the correct format strings ># for APR types which vary between platforms, but we don't always get > > > >
Re: cvs commit: apr/random/unix apr_random.c
On Wed, Nov 05, 2003 at 11:32:07PM +, Ben Laurie wrote: > Branko Äibej wrote: > > > Ben Laurie wrote: > > > > > >>Jeff Trawick wrote: > >> > >> > >> > >>>/* FIXME: this is not C99 or C++ or Java */ > >>> > >>> > >> > >>What's the matter? Did your editor break? :-) > >> > >>Besides, your revision is wrong... > >> > >> /* FIXME: this is not C99 or C++ or Java or gcc */ > >> > >> > > > > So now 'gcc' is a language. Sigh. > > > > Try 'gcc -std=c89', and I suggest you always use that for compiling APR. > > Jeepers. Lighten up guys! > > BTW, if that should be standard, why not make it automatic (at least in > maintainer mode)? I'd be a bit wary about doing that: httpd uses code which is not valid C89 if configured with GCC - designated initializers. joe
Re: cvs commit: apr configure.in
[EMAIL PROTECTED] wrote: > jorton 2003/11/06 01:18:22 > > Modified:.configure.in > Log: > * configure.in: Fix endianness detection with autoconf 2.1x. Speaking of autoconf, I get this every time: WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. do we care? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
[STATUS] (apr-util) Wed Nov 5 23:45:37 EST 2003
APRUTIL LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2003/03/31 05:32:43 $] Release: 0.9.3 : Tagged March 30, 2002 0.9.2 : Released March 22, 2002 (alpha) 0.9.1 : Released September 11, 2002 (alpha) 0.9.0 : Not released 2.0a9 : released December 12, 2000 RELEASE SHOWSTOPPERS: RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Solaris's Sun Freeware (sfw) package has a busted gcc/ld setup. This gcc passes -L/opt/sfw/lib to /usr/ccs/bin/ld, but does not pass -R. Therefore, when trying to run the code using a library from /opt/sfw/lib (say, libdb), the run-time linker will not look in /opt/sfw/lib and the program will die. Status: Workaround is to add "-R/opt/sfw/lib" to LDFLAGS. Should check latest sfw package set and see if Sun may have fixed this. * GDBM usage of errno is not-thread-safe. Fix. Other bugs that need fixing: Other features that need writing: * possibly move test/testdbm* to util/dbu Justin says: Do we still want to do this? testdate is now in test. Status: Greg +1 (volunteers) Documentation that needs writing: * API documentation Status: * doc the lifetimes of apr_dbm return values Available Patches: Open Issues:
[STATUS] (apr) Wed Nov 5 23:45:25 EST 2003
APACHE PORTABLE RUNTIME (APR) LIBRARY STATUS: -*-text-*- Last modified at [$Date: 2003/06/26 18:17:44 $] Release: 0.9.3 : tagged March 30, 2003 0.9.2 : released March 22, 2003 0.9.1 : released September 11, 2002 0.9.0 : released August 28, 2002 2.0a9 : released December 12, 2000 2.0a8 : released November 20, 2000 2.0a7 : released October 8, 2000 2.0a6 : released August 18, 2000 2.0a5 : released August 4, 2000 2.0a4 : released June 7, 2000 2.0a3 : released April 28, 2000 2.0a2 : released March 31, 2000 2.0a1 : released March 10, 2000 RELEASE 0.9 SHOWSTOPPERS: RELEASE 1.0 SHOWSTOPPERS: * Must namespace protect all include/apr_foo.h headers. Jon Travis has especially observed these including apr within Apache-1.3. Message-ID: <[EMAIL PROTECTED]> Deprecating the symbols in 0.9, eliminating them with 1.0. (Those problems have been fixed, but it is a good example of what to look for.) Some headers with issues: apr.hnw (READDIR_IS_THREAD_SAFE, ENUM_BITFIELD, _POSIX_THREAD_SAFE_FUNCTIONS (?)) apr.hw(NO_USE_SIGACTION) * Flush out the test suite and make sure it passes on all platforms. We currently have about 450 functions in APR and 147 tests. That means we have a large number of functions that we can't verify are actually portable. This TODO includes finishing the migration to the unified test suite, and adding more tests to make the suite comprehensive. * close out the XXX's already! (wrowe: this is "production release" quality code with that many unanswered questions?) If they aren't showstoppers, deprecate them to TODO:s. * complete the efforts started by DougM for cleaner fn naming conventions: see proposed name changes in renames_pending and offer up any additions/vetos/clarifications. DougM offered to complete the work with his nifty perl rename script at the hackathon. Thom says: I think this is close to done; does anyone want to add any further renames? CURRENT VOTES: CURRENT test/testall -v EXCEPTIONS: Please add any platform anomilies to the following exception list. * All platforms fail tests in time: test_localstr and test_ctime Imaginary... the tests can only succeed on machines configured for the Pacific (US) timezone. Test needs to be restructured. Ignore these errors. * BUG: Win32 fails test in File Info: test_stat_eq_finfo apr_stat and apr_getfileinfo differ in protection ... wrowe guesses that we are checking the handle objects' permissions rather than the filesystem objects' permissions. * Win32 Not Implemented tests Pipes: set_timeout/read_write; can't timeout blocking pipes Socket Creation: tcp6_socket and udp6_socket (at least by default) Socket Options: corkable: TCP isn't corkable Users: username: Groups from apr_uid_get not implemented RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP: * Someone needs to port testucs to Unix. Right now it only works on Windows. * The return type of a thread function (void *) is inconsistent with the type used in apr_thread_exit()/apr_thread_join() (apr_status_t). The thread function's return type should be changed to apr_status_t so that a return from the thread main function has the same effect as apr_thread_exit(). See Message-Id: <[EMAIL PROTECTED]> for thread discussing this. +1: BrianH, Aaron * Need some architecture/OS specific versions of the atomic operations. progress: generic, solaris Sparc, FreeBSD5, linux, and OS/390 done need: AIX, AS400, HPUX * The new lock API is a full replacement for the old API, but is not yet complete on all platforms. Components that are incomplete or missing include: Netware: apr_proc_mutex_*() (Is proc_mutex unnecessary on Netware?) * proc_mutex is not necessary on NetWare since the OS does not support processes. The proc_mutex APIs actually redirect to the thread_mutex APIs. (bnicholes) OS/2: apr_thread_cond_*(), apr_proc_mutex_*() Less critical components that we may wish to add at some point: Beos: apr_thread_rwlock_try*lock() apr_proc_mutex_trylock() Unix: apr_thread_rwlock_*() for platforms w/o rwlocks in pthread Win32: apr_thread_cond_timedwait(), apr_proc_mutex_*() (Is proc_mutex unnecessary on Win32?) * Need to contemplate apr_strftime... platforms vary. OtherBill suggested this solution (but has no time to implement): Document our list of 'supported' escapes. Run some autoconf/m4 magic against the complete list we support.
