This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Arlindo, >Date: Wed, 26 Feb 1997 11:59:51 -0500 (EST) >From: Arlindo da Silva <address@hidden> >Organization: NASA/GSFC >To: address@hidden (Steve Emmerson) >Subject: Re: 970226: Porting UDunits to PC >Keywords: 199702221703.KAA06697 In the above message, you wrote: > Here is what I get (I am just editing this by hand): > > > struct { > > origin = 5.3853155396696e-322 > > factor = 0.00000 > > hasorigin = 0 > > power = { > > [0] 0 > > [1] 0 > > [2] 0 > > [3] 0 > > [4] 0 > > [5] 0 > > [6] 0 > > [7] 0 > > [8] 0 > > [9] 0 > > > The "factor=0" is what makes utPrint() to return a NULL; it also gives NANs > when used in utRaise(). Last night I was trying to trace where the apparent > junk (origin=...e-322,factor=0) was coming from without much luck. My guess > is that it could be related to the bison/utlib interface, but I am not sure. Tough problem. The parser calls units-handling functions in the file utlib.c. All I can suggest is calling those functions (via a small program) and seeing what they do. I think the steps to investigate are the following (based on the `NAME INT' sequence in utparse.y): UtUnit unit1, unit2; utFind("m", &unit1); utRaise(&unit1, 2, &unit2); utCopy(&unit2, &unit1); Hopefully, at some point one of the above function calls will mess-up. At which point we can investigate further. Let me know what you find. -------- Steve Emmerson <address@hidden>