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 Ed! > > >> --- netcdf-4.0.1-beta2-snapshot2009010202/acinclude.m4.orig 2008-10-06 19:08:25.000000000 +0000 > >> +++ netcdf-4.0.1-beta2-snapshot2009010202/acinclude.m4 2009-01-05 12:49:13.610052000 +0000 > >> @@ -420,9 +420,9 @@ > >> UD_CHECK_CTYPE_FORTRAN(real, float double, REAL) > >> UD_CHECK_CTYPE_FORTRAN(doubleprecision, double float, DOUBLEPRECISION) > >> > >> - UD_CHECK_FORTRAN_NCTYPE(NCBYTE_T, byte integer*1 integer, byte) > >> + UD_CHECK_FORTRAN_NCTYPE(NCBYTE_T, byte integer*1 "integer(kind=1)" "integer(selected_int_kind(2))" integer, byte) > >> > >> - UD_CHECK_FORTRAN_NCTYPE(NCSHORT_T, integer*2 integer, short) > >> + UD_CHECK_FORTRAN_NCTYPE(NCSHORT_T, integer*2 "integer(kind=2)" "integer(selected_int_kind(4))" integer, short) > >> dnl UD_CHECK_FORTRAN_CTYPE(NF_SHORT_T, $NCSHORT_T, short, SHRT_MIN, SHRT_MAX) > >> > >> dnl UD_CHECK_FORTRAN_NCTYPE(NCLONG_T, integer*4 integer, long) > >> > > > > Howdy Harald! > > > > The challenge with this patch is that it breaks the build for F77-only situations. That is, a F77 compiler is not going to be able to figure out selected_int_kind(4). > > I thought that I understood the logics right. configure should first > try integer*2, when it fails it will try integer(kind=2), and then > integer(selected_int_kind(4)), and finally integer. > An F77 compiler will probably accept integer*2, and if not then integer. > An F90 compiler may reject integer*2 because it is illegal in F90, > but will accept one of the next variants. > > The aim is to properly match the C and Fortran types. With the original > checks, a strict F90 compiler would always reject integer*2 and only use > integer, leading to failures in the Fortran self-test. This is the case > for the NEC SX compiler. > > So I guess you have an F77 compiler where you need a different solution. > > > I guess that the ideal would be to see if the fortran compiler is a F90 one, and, if so, use your patched lines, otherwise use the existing lines. > > > > I am working on that now, but if you have any other thoughts about this, please let me know. > > Well, I had hoped that my solution was simple and clever enough. > Maybe it isn't. Actually I can even conceive a situation where > integer(kind=..) leads to an unexpected result (with the NAG compiler), > but integer(selected_int_kind(...)) never should. > > Regards, > Harald No, sorry, I just didn't see that! You are plenty clever but I am just a programmer they keep in a cave! ;-) I have checked in this change and it has passed the first round of tests and a snapshot is available here: http://www.unidata.ucar.edu/software/netcdf/builds/snapshot/ Tonight around midnight the daily snapshot will subject this to more testing. I am also adding g77-only to my main test machine so I can be sure not to break it. If you want to wait until tomorrow to try this, you can make sure the test page is not showing too much red first. Thanks for your patience Harald! Ed Ticket Details =================== Ticket ID: FST-907593 Department: Support netCDF Priority: Critical Status: Closed