Greetings, all. Primdat is coming along. I've got most of the platform dependencies sorted out, I think, so that the only one left is PRM_PAR. That looks like a real pig, however, because it seems to have both odd and non-standard Fortran in it, and some unexplained magic in the declaration of the bad values. That, and _two_ ix86_Linux files. And the comments explaining what platform the files are for don't always match the files' naming extensions. I'm sorely tempted to junk the existing PRM_PAR files, replace it with a prm.h, and generate PRM_PAR from that. However, I'd need to know more about what was in there and why. I've never consciously used primdat, but I'm hoping that someone else has. First is the statements initialising reals with hex values: REAL VAL__BADR PARAMETER ( VAL__BADR = 'FF7FFFFF'X ) I can see what that's doing, but it looks veeeery dodgy. Can anyone point to any details about this? I can't find any support for that syntax in the Fortran standard, though that's rather confusingly arranged and I could have missed it, and I'd confidently say it was a VAXFortran extension except that the Sun files have it, too. Given that, the PRM_PAR files are actually less different from each other than they might appear, so that they're precarious rather than terribly non-standard. Secondly, what is the idea behind the bad values, and how magic are the particular values? Are they just a sort of non-IEEE-specific NaN? Or are they a specific flag value that would possibly find its way into files (in which case the actual values couldn't ever be changed)? I don't think they can be specific values, because the header of PRM_PAR says ``This file defines machine-dependent public constants for the PRIMDAT system'', and they _are_ machine-dependent, because the various PRM_PAR source files define the _same_ bit patterns on both big- and little-endian machines. Unless, that is (and this is the link with the first question), the 'hex'X notation has its value ordered in significance order rather than memory order. And what's with those bit patterns? Given that that FF7FFFFF is just an integer (that is, it's in significance order rather than memory order, which makes sense), then it corresponds to the most negative finite IEEE float, and that means that VAL__BADR is equal to NUM__MINR, which is slightly surprising. But then this is clearly not a special number on a VAX -- and possibly not even a legal float, I can't remember. So this can't be a platform-independent bad value that would ever find its way into a file, and it's just a flag value that's possibly returned by certain VAL_* functions, and it doesn't matter that there's a theoretical chance that a bad value would be the correct result of a calculation. This does seem to match how they're explained in SUN/39. It would also be sensible, I think, to take the minimum and maximum values from something like float.h, and just set the VAL__BADR and NUm__MINR values, for example, to be the same as float.h's FLT_MIN. Thus, yes, I'll make a new prm.h file primary, and effectively generate PRM_PAR from that. All this will be wrong on a 64-bit machine, of course.... Ah no, it wouldn't be, not if it's taken from float.h! So that's a Good Thing. I think. Also, I think that PRM_PAR doesn't have to worry about whether it's on a big- or little-endian machine. Which is also Good. Right: that's probably a bit clearer to me (thanks for listening). Any words of wisdom to add to that, anyone? See you, Norman -- --------------------------------------------------------------------------- Norman Gray http://www.astro.gla.ac.uk/users/norman/ Physics and Astronomy, University of Glasgow, UK [log in to unmask]