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.
> Hi, > > I currently use netcdf-4.1.1 from the web page. > There are bugs in netcdf2.inc > > doubleprecision fildoub > > ... > > parameter (fildoub = 9.9692099683868690e+36) > > But double precision values in Fortran are denoted with an d in the > exponent and not an e ! Correct would be: > > > parameter (fildoub = 9.9692099683868690d+36) > > > Analog bug in netcdf3.inc > > doubleprecision nf_fill_double > > ... > > parameter (nf_fill_double = 9.9692099683868690e+36) > > Correct would be: > > parameter (nf_fill_double = 9.9692099683868690d+36) > > Cheerio, > Luis > -- > \\\\\\ > (-0^0-) Gutentag Luis! One interesting thing about your bug report is that the fortran include file netcdf2.inc contains code that is 15 years old at least. And yet no one has ever noticed this bug before! I have researched the issue and agree that, according to the fortran standard, double precision real constants should use the "d" not the "e" in their exponent. But how did you notice this? Did it cause a problem for you? Did you get a warning from your compiler? Or did you just notice it while reading the code one day? I have checked in fixes. They will be available in the next snapshot, assuming they don't break the snapshot build (another problem, currently being worked on, precludes me from checking at this time). So this will be tested with tonight's snapshot release testing. Thanks for pointing this out! Ed Ticket Details =================== Ticket ID: LHM-940222 Department: Support netCDF Priority: Normal Status: Closed