Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: Re: Re: RE: ACE/TAO under Cygwin (was: ORB)
From: "Timothy C Prince" <tprince AT myrealbox DOT com>
To: mgainty AT hotmail DOT com
CC: david DOT w DOT dawson AT lmco DOT com, cygwin AT cygwin DOT com
Date: Mon, 07 Apr 2003 21:47:26 +0000
X-Sender: tprince
MIME-Version: 1.0
Message-ID: <1049752046.b9c20ac0tprince@myrealbox.com>
Content-Type: text/plain; charset="KOI8-U"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id h37Llaw24330



-----Original Message-----
From: "Martin" <mgainty AT hotmail DOT com>
To: "Timothy C Prince" <tprince AT myrealbox DOT com>, <david DOT w DOT dawson AT lmco DOT com>
Date: Mon, 7 Apr 2003 13:48:16 -0700
Subject: Re: RE: ACE/TAO under Cygwin (was: ORB)

Gentlemen:

I found this function in hash_log2.c: from cygwin-1.3.22-1-src.tar.bz2
tarball

__uint32_t
__log2(num)
__uint32_t num;
{
__uint32_t i, limit;
limit = 1;
for (i = 0; limit < num; limit = limit << 1, i++);
return (i);
}

Is this the function you are speaking of??

-Martin

----- Original Message -----
From: "Timothy C Prince" <tprince AT myrealbox DOT com>
To: <david DOT w DOT dawson AT lmco DOT com>
Cc: <cygwin AT cygwin DOT com>
Sent: Monday, April 07, 2003 12:36 PM
Subject: Re: RE: ACE/TAO under Cygwin (was: ORB)




-----Original Message-----
From: "Dawson, David W" <david DOT w DOT dawson AT lmco DOT com>
To: "'cygwin AT cygwin DOT com'" <cygwin AT cygwin DOT com>
Date: Mon, 07 Apr 2003 11:19:19 -0400
Subject: RE: ACE/TAO under Cygwin (was: ORB)

I am sorry that I was not clear:
in limits.h, I changed the definition of IOV_MAX to 1024
in math.h, I *commented-out* the macro definition of log2

So, there's not much to test.....

I poked around in the cygwin-1.3.22-1-src.tar.bz2 tarball for the definition
and implementation of log, thinking that log2 could be implemented in code
(versus preprocessor macro), but got quickly lost in the __MATHCALL stuff.

I guess that I was tossing this out for comment by the knowledgeable folks
that implemented/ported the math library from Linux, and why log2 was
implemented this way versus the Linux code way.  Like I said before, I got
quickly lost and certainly have no basis on which to form any
opinion/suggestion.

Thanks,
-David
---------------------
David Dawson
david DOT w DOT dawson AT lmco DOT com
703-367-3885


-----Original Message-----
From: Martin [mailto:mgainty AT hotmail DOT com]
Sent: Saturday, April 05, 2003 10:57 PM
To: cygwin AT cygwin DOT com
Subject: Re: ACE/TAO under Cygwin (was: ORB)


David-
can you show us the patch of code for #define so we can test the results
from the preprocessor output?
Regards,
Martin

----- Original Message -----
From: "Dawson, David W" <david DOT w DOT dawson AT lmco DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Saturday, April 05, 2003 8:17 PM
Subject: ACE/TAO under Cygwin (was: ORB)


> I have been moderately successful in compiling ACE/TAO under Cygwin (Some
> problems with cone of the Services, but my CORBA programs interoperate
with
> our Solaris-based TAO services (and other CORBA clients/servants) fine.
>
> I encountered two problems with a couple of the definitions in the Cygwin
> /usr/include files:
>
> 1) In limits.h, IOV_MAX is defined as (__INT_MAX__-1) (a *very* large
> number).
> The other UNIX systems I could examime set it to a much smaller value
(like
> 1024).
> The comment says this is the "/* Maximum number of iovcnt in a writev */".
> Does Cygwin really support this many? Or is this just a convenient
setting?
>
> The reason for the question is that ACE (and TAO) define arrays for the
full
> number of supported IOV entries, and g++ chokes on an array of size
> __INT_MAX__-1
>
> (To set ACE/TAO to compile, I patched this value to 1024)
>
> 2) As a convenience (I suppose), math.h has a macro definition for log2.
> This is not the case in any other math.h I have been able to examine and
> causes a real problem in the development of a platform-independent "log2"
> routine.
>
> The problem is that the pre-processor replaces the string "log2" with it's
> defined value without regard to context.  This means that while I can
write
> my own log() function (in my namespace, or course) I cannot write a log2
> function -- it won't compile.
>
> (To get ACE/TAO to compile, I patched math.h to remove this define.)
>
> The real questions in this post are:
> 1) Should there a better value for IOV_MAX in limits.h
> 2) Should the (as far as I can tell) non-standard define for log2 be
removed
> (or replaced with a real log2 function?)
> 3) Should I just go away and be quiet?
>
> Thanks,
> -David.
>
You make it unnecessarily hard to figure out this message, when you top post
after your respondents have starting bottom posting.

Did you forget the usual precautions, when implementing your own version of
a standard intrinsic?

# undef log2

double (log2)(double x){}

Using a preprocessor macro for log2() is a usual tactic for ia32.  It's a
standard function in C99, included in most libraries which implement (even
partly) gcc's c99 support.  You __must__ use the #undef if you want a "real"
log2() according to the current standard, whether you provide it yourself,
or hope for the library to have it already (cygwin/newlib doesn't).  The way
it's implemented in the default cygwin/newlib installation is unnecessarily
slow and inaccurate, but you're entitled to change that in your own
installation.  In case you don't feel like looking it up, here's the usual
glibc macro:
__inline_mathcode (log2, __x, \
  long double __value;       \
    __asm__ ("fyl2x" : "=t" (__value) : "0" (__x), "u" (1.0) : "st(1)");  \
  return __value)
__________________________________________________
This wouldn't be the first time C99 made an older program questionably compliant by providing a log2() function in the standard list.  I guess the worst case would be if an exact int result were expected, but the standard log2() happened to present a result which is slightly smaller.  This shouldn't happen with the glibc macro, because rounding from long double to double prior to truncating would take care of it.
Tim Prince

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/