On Jan 18, 2005, at 7:44 AM, Ian Chivers wrote: > I have a query regarding real literal constants > when reading data from a file or the terminal. Woah... Slow down. Wrong direction. Without yet seeing which exact question you are going to ask, I already see what I presume will be much of the problem... Literal constants do not appear in data files (including the terminal). The term "literal constant" refers to something in Fortran source code, *NOT* in data files. There are forms in data files that look similar to some literal constants, but they are not literal constants and they don't have exactly the same form. This was messed up in the original f90 document, which inappropriately used the term "constant". That was largely corrected in an f90 interpretation (though I think I recall finding one or two cases that either got missed by that interp or slipped back in later). > With the second read I do not need to add _long to the external data > to get the higher precision. Is this standard conforming? Ah. Ok. That one. There are several questions that could have resulted from the above-mentioned confusion. This is one of them. I'll mostly skip over the question of whether it is standard conforming for compilers to provide more precision than requested. I will note that the question of whether it is standard conforming for a compiler to do something is not necessarily the same question as whether it is standard conforming for a program to depend on it. For example, a standard-conforming compiler can support language extensions, but a standard conforming program can't use them. But in this case, that whole issue is irrelevant because you are trying to apply the wrong concept. The data in the file doesn't *HAVE* a precision. It is just a bunch of characters. The process of doing a formatted read converts the characters into internal forms. It is the internal forms that have kinds - not the characters. (Well, the characters have character kinds - usually default - but that's a different matter). Note, for example, that if you have the characters 1234 in an input file, that doesn't necessarily represent an integer at all. It could be read into a character variable as just a string of characters. Or it could be 4 separate integers read with a 4I1 edit descriptor. Along this line, note that kind numbers are not part of the syntax allowed for formatted input (or produced by formatted output). Since kind numbers are compiler-dependent, putting them in formatted data files would be problematic. Formatted data files are not supposed to be compiler-dependent (well, not in that way anyway). And using named constants wouldn't help. Named constants do not have global scope, even in the source code. The same name can represent different constants in different scoping units. I suppose that one *COULD* make the interpretation of formatted data files depend on the particular scoping unit it was read from (being careful with the definitions when multiple scoping units are involved, as with UDDTIOP), but that particular mire is not one that Fortran got stuck in. If you happen to want to write something like the characters 1234_long in a data file, you are certainly free to do so. But you'll have to use something other than an integer edit descriptor at least for the underscore when writing it. When reading it, the parsing and interpretation will be up to you to define, because the syntax won't mean anything special to the compiler i/o run-times. -- Richard Maine | Good judgment comes from experience; [log in to unmask] | experience comes from bad judgment. | -- Mark Twain