 |
 |
Richard Maine commented: ! Note that stream I/O was introduced as a C interop feature. That ! doesn't mean we should blindly follow every mistake that C might have ! made. But it does suggest that there is a lot of sense to going ! along with things that do seem to work well. If the C standard does not specify a concrete internal representation for \n, I would call that a blessing, not a mistake. It is also my recollection that stream I/O was introduced as a C interop feature, in which case something equally abstract to \n, unlike the concrete ACHAR(10), seems to be desired. Richard continued: & Indeed, C interop is one of the reasons I like this. There are likely & to be codes that expect to be able to take *THE SAME* internal & character string, including an internal newline representation, and & have it work the same way when written to a file on multiple systems. & You don't want to have to change the internal data depending on what & system it runs on. Very desirable, but if the concrete internal representation of \n isn't specified by the C standard, and you want to interoperate with C, you SHOULDN'T have "*THE SAME* internal character string, including an internal newline representation" on different systems. As I've pointed out in other messages, ACHAR(10) doesn't work if the concrete internal representation of \n isn't specified by the C standard and one needs to send (receive) \n to (from) a C function. & Having a parameter to tell you what it needs & to be on each system isn't nearly as good as not having to change it & at all for different systems. How does using a parameter from ISO_FORTRAN_ENV instead of ACHAR(10) require one to "change it ... for different systems?" The whole point of parameters in ISO_FORTRAN_ENV is to foist portability problems onto the vendors (where they belong, IMNSHO). Correct me if I'm wrong (I'm sure somebody will), but isn't it impossible for users to change intrinsic modules? As I've pointed out in other messages, ACHAR(10) may cause (small) headaches for some vendors in the development of their I/O libraries -- fputc() could need an ACHAR(10) => \n filter. If you need something other than ACHAR(10) to send (receive) \n to (from) a C function: 1. It would be desirable to have a parameter with the value of \n in ISO_FORTRAN_ENV, 2. in which case, why not use that parameter instead of ACHAR(10) to denote a new-line in formatted stream output, 3. which has the benefit that vendors wouldn't need an ACHAR(10) => \n filter to use fputc() for formatted stream output. -- What fraction of Americans believe | Van Snyder Wrestling is real and NASA is fake? | [log in to unmask] Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Dan Goldin, George Bush, the Pope, or anybody else.