On Wed, Apr 11, 2001 at 06:42:26AM -, [EMAIL PROTECTED] wrote:
...
RCS file: /home/cvs/apr-util/Makefile.in,v
retrieving revision 1.28
retrieving revision 1.29
diff -u -r1.28 -r1.29
--- Makefile.in 2001/04/09 04:56:20 1.28
+++ Makefile.in 2001/04/11 06:42:22
This seems like a dangerous assumption to me.
William A. Rowe, Jr. wrote:
Before I dig into this any further...
we make a number of assumptions in APR that sizeof(void(*)(void)) ==
sizeof(void*).
By KR C: A Reference Manual 2nd ed 6.1.4 Pointer Sizes...
Although function pointers
On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
Oh buckets macro designer, is this is what we expected?
apr-util\buckets\apr_buckets_socket.c(142) : warning C4702: unreachable code
...
Not exactly. I've never seen a compiler complain about this macro before.
To save the others a little
- Original Message -
From: [EMAIL PROTECTED]
To: William A. Rowe, Jr. [EMAIL PROTECTED]
Cc: dev@apr.apache.org
Sent: Wednesday, April 11, 2001 9:32 AM
Subject: Re: Buckets code question
On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
Have finished win32 vc5's equivilant of -wall
On Wed, Apr 11, 2001 at 07:32:10AM -0700, [EMAIL PROTECTED] wrote:
That looks like a bug in the compiler. That code is definately reachable.
I'd bet that the warning is related to the macro expansion.
#define apr_bucket_do_create(do_make) \
do { \
apr_bucket *b,
On Wed, 11 Apr 2001, William A. Rowe, Jr. wrote:
} while (0);
return ap__b;
} while(0);
}
So the final While(0); is definately unreachable. No compiler error.
My only question, why do {} while(0); rather than {} ?
It's not do {} while(0); rather than {} , it's that
At 10:51 AM 04/11/2001, William A. Rowe, Jr. wrote:
APU_DECLARE(apr_bucket *) apr_bucket_socket_create(apr_socket_t *p)
{
do {
[...]
return ap__b;
} while(0);
}
So the final While(0); is definately unreachable. No compiler error.
My only question, why do {} while(0); rather than
At 11:50 AM 04/11/2001, Cliff Woolley wrote:
While this causes some very minor redundancy in the
apr_bucket_foo_create() functions, it has several benefits:
(1) both warnings and errors eliminated
(2) the magical return is made explicit, which makes
apr_bucket_foo_create() easier to understand
On Wed, 11 Apr 2001, Greg Marr wrote:
I agree. Having macros that look like functions, but have return
statements in them, is bad. It also prevents those macros from being
made into inline functions without changing all the places that call
them.
I'll consider that three +1's on concept...
On Wed, 11 Apr 2001 [EMAIL PROTECTED] wrote:
#define apr_bucket_do_create(ap__b,do_make) \
do {\
apr_bucket *b; \
b = calloc(1, sizeof(*b)); \
ap__b = do_make;
On 11 Apr 2001 [EMAIL PROTECTED] wrote:
jwoolley01/04/11 12:07:11
Modified:server error_bucket.c
.CHANGES
buckets apr_buckets_eos.c apr_buckets_file.c
apr_buckets_flush.c apr_buckets_heap.c
11 matches
Mail list logo
