apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: cvs commit: apr/include apr_time.h
Date Wed, 12 Jun 2002 21:33:42 GMT
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.


Mime
View raw message