You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/06/12 10:06:25 UTC
Re: cvs commit: apr/include apr_time.h
I'm trying to pre-simplify any future patch we might choose to apply for
time handling. Seems like we should clean house before trying any new
games with apr_time_t (including -renaming- apr_time_t and other symbols
that have confused porters.)
I notice especially that server->timeout seems to be converted far to
frequently to an apr_time_t. Why are we still using seconds for that field?
Barring feedback that it's a "Good Thing"(tm) then I will proceed to change
that field over to an apr_time_t.
Bill
>wrowe 2002/06/12 00:39:31
>
> Modified: include apr_time.h
> Log:
> To simplify future, experimental work with binary usec values, these
> are suggested wrappers for common uses of APR_USEC_PER_SEC.
>
> Comments welcome.
>
> Revision Changes Path
> 1.51 +7 -0 apr/include/apr_time.h
>
> Index: apr_time.h
> ===================================================================
> RCS file: /home/cvs/apr/include/apr_time.h,v
> retrieving revision 1.50
> retrieving revision 1.51
> diff -u -r1.50 -r1.51
> --- apr_time.h 8 Jun 2002 20:04:26 -0000 1.50
> +++ apr_time.h 12 Jun 2002 07:39:31 -0000 1.51
> @@ -95,6 +95,13 @@
> /** number of microseconds per second */
> #define APR_USEC_PER_SEC APR_TIME_C(1000000)
>
> +#define APR_TIME_USEC(time) ((apr_int32_t)(time) % APR_USEC_PER_SEC)
> +
> +#define APR_TIME_SEC(time) ((apr_int64_t)(time) / APR_USEC_PER_SEC)
> +
> +#define APR_TIME_FROM_SEC(sec) ((apr_time_t)(sec) * APR_USEC_PER_SEC)
> +
> +#define APR_TIME_MAKE(sec, usec) ((apr_time_t)(sec) * APR_USEC_PER_SEC
> + usec)
>
> /**
> * return the current time
>
>
>
Re: cvs commit: apr/include apr_time.h
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 12 Jun 2002, William A. Rowe, Jr. wrote:
> It seems that we've decided sometime back that all macro-fns should be
> declared in ucase. Now, we can debate that issue again, but if someone
> could pull up a reference to that thread in the archives it would be
> most cool.
Somewhere in dev@apr when we talked about APR_BUCKET_DELETE() vs
apr_bucket_delete() or one of its friends there was a brief discussion
about it.
Basically it came down to this: If the macro *could* be a function (by
virtue of no unintended side-effects as you mentioned), then give it a
lowercase name. If side-effects might occur, give it an uppercase name.
(This is all basically what you said.) In practice, if any one of a group
of macro-fn's gets an uppercase name, typically all of its related ones
do, too, for ease-of-remembering.
In this case, I'd say lowercase is fine by majority. For the one
exception you mentioned, we can wrap the macro body with {} and declare a
temporary variable inside that scope in which to store the value passed
to the macro, thereby regaining function-like semantics. There's
precedent in the code for this already...
--Cliff
Re: cvs commit: apr/include apr_time.h
Posted by Cliff Woolley <jw...@virginia.edu>.
On Wed, 12 Jun 2002, William A. Rowe, Jr. wrote:
> It seems that we've decided sometime back that all macro-fns should be
> declared in ucase. Now, we can debate that issue again, but if someone
> could pull up a reference to that thread in the archives it would be
> most cool.
Somewhere in dev@apr when we talked about APR_BUCKET_DELETE() vs
apr_bucket_delete() or one of its friends there was a brief discussion
about it.
Basically it came down to this: If the macro *could* be a function (by
virtue of no unintended side-effects as you mentioned), then give it a
lowercase name. If side-effects might occur, give it an uppercase name.
(This is all basically what you said.) In practice, if any one of a group
of macro-fn's gets an uppercase name, typically all of its related ones
do, too, for ease-of-remembering.
In this case, I'd say lowercase is fine by majority. For the one
exception you mentioned, we can wrap the macro body with {} and declare a
temporary variable inside that scope in which to store the value passed
to the macro, thereby regaining function-like semantics. There's
precedent in the code for this already...
--Cliff
Re: cvs commit: apr/include apr_time.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:29 PM 6/12/2002, Roy T. Fielding wrote:
>There is no reason for them to be all-uppercase. I hate it when people
>use uppercase for functions, including macro functions. All-uppercase
>is a convention for symbolic constants, not functions.
It seems that we've decided sometime back that all macro-fns should be
declared in ucase. Now, we can debate that issue again, but if someone
could pull up a reference to that thread in the archives it would be most cool.
I'm pro-ucase only in one situation, in general I'm agnostic. The macro arg
that is used twice or more within the macro body becomes some serious
buggy garbage. MACRO_FN(foo++) is a much easier bug to notice than
macro_fn(foo++). Only one of these macros in my experimental binary usec
implementation will actually trigger this;
+#define APR_TIME_FROM_USEC(usec) ((((apr_time_t)(usec) /
APR_TIME_C(1000000)) \
+ *
APR_BUSEC_PER_SEC) \
+ + (((apr_time_t)(usec) %
APR_TIME_C(1000000)) \
+ *
APR_BUSEC_PER_SEC) \
+ /
APR_TIME_C(1000000))
Where we must split the math to avoid serious underflow conditions, with a
loss of precision down to 2^21 for seconds (less than 25 days!!!) Although
I don't see where we will convert usec time to binary usec time very often
(most inputs will be in seconds + usec, on Win32 it's sec + 100ns units)
this is just a good example of how a macro arg can break coders assumptions.
Re: cvs commit: apr/include apr_time.h
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 03:29 PM 6/12/2002, Roy T. Fielding wrote:
>There is no reason for them to be all-uppercase. I hate it when people
>use uppercase for functions, including macro functions. All-uppercase
>is a convention for symbolic constants, not functions.
It seems that we've decided sometime back that all macro-fns should be
declared in ucase. Now, we can debate that issue again, but if someone
could pull up a reference to that thread in the archives it would be most cool.
I'm pro-ucase only in one situation, in general I'm agnostic. The macro arg
that is used twice or more within the macro body becomes some serious
buggy garbage. MACRO_FN(foo++) is a much easier bug to notice than
macro_fn(foo++). Only one of these macros in my experimental binary usec
implementation will actually trigger this;
+#define APR_TIME_FROM_USEC(usec) ((((apr_time_t)(usec) /
APR_TIME_C(1000000)) \
+ *
APR_BUSEC_PER_SEC) \
+ + (((apr_time_t)(usec) %
APR_TIME_C(1000000)) \
+ *
APR_BUSEC_PER_SEC) \
+ /
APR_TIME_C(1000000))
Where we must split the math to avoid serious underflow conditions, with a
loss of precision down to 2^21 for seconds (less than 25 days!!!) Although
I don't see where we will convert usec time to binary usec time very often
(most inputs will be in seconds + usec, on Win32 it's sec + 100ns units)
this is just a good example of how a macro arg can break coders assumptions.
Re: cvs commit: apr/include apr_time.h
Posted by "Roy T. Fielding" <fi...@apache.org>.
There is no reason for them to be all-uppercase. I hate it when people
use uppercase for functions, including macro functions. All-uppercase
is a convention for symbolic constants, not functions.
....Roy
Re: cvs commit: apr/include apr_time.h
Posted by "Roy T. Fielding" <fi...@apache.org>.
There is no reason for them to be all-uppercase. I hate it when people
use uppercase for functions, including macro functions. All-uppercase
is a convention for symbolic constants, not functions.
....Roy