Re: advance="no" not portable

In article <1117224920.753751.3200@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Eric Lavigne" <lavigne.eric@xxxxxxxxx> wrote:

> WRITE(2,*,ADVANCE="NO") '*'

Your problem is not with the advance='no'. It is with the list-directed
formatting (indicated by the first "*" above).

The standard doesn't even allow advance='no' with list-directed
formatting, and you have found *EXACTLY* the reason why not. Using the
two together is misleading. It makes you think that you have specified
something that you haven't really done.

The standard allows a compiler is allowed to start new records quite
freely in list-directed output. Thus, if the standard allowed the above
combination at all, a compiler could validly accept it and do nothing
differently than if you had specified advance='yes'. In particular, the
vendor could claim that a new record was started as part of the
list-directed formatting instead of as part of an advance='yes'.

The "universal" advice relating to list-directed output applies here.
List-directed output is simple and handy, but it does not allow you
precise control of the formatting. In using list-directed formatting,
you abdicate detailed decisions to the compiler, and the results *WILL*
vary among compilers.

In your case above, it is simple to just use the explicit format '(a)'
instead of list-directed formatting. I would expect that to do what you
wanted. In other cases, it can be a bit more bother, sometimes best
handled by doing a list-directed write to an internal file (character
variable), and then writing out that character variable with an explicit
format; this wasn't standard-conforming in f77, which made some things
quite a pain.

Note, by the way, that the prohibition against list-directed output with
advance='no' is a constraint in the standard. This means that the
compiler is in violation of the standard if it is not able to diagnose
this as an error (though such diagnosis does not have to be enabled by
default). Did you use the compiler options for diagnosing violations of
the standard? If not, I recommend getting in the habit of doing so, not
necessarily on every compilation, but on occasion, and particularly when
diagnosing problems.

If you did use such options and the compilers failed to diagnose this,
then I suggest submitting a bug report.

As long as the compilers have the capability of diagnosing the violation
of the constraint, what they otherwise do with it would be an extension
and thus any behavior could be considered as "right". But even without
resorting to calling it an extension, I would interpret the standard as
allowing either behavior if the constraint against this were deleted/

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
.

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... > that someone will try compile their stuff on an old compiler. ... > because the ANSI standard obsoleted them, and everyone picked up the ANSI ... fixed by using another language. ... >>are multiplying two expressions of the widest type supported by your ...
    (comp.lang.c)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... Program name in quotes (allowed in '02 Standard) ... > If J can be made an independent item which the compiler can put wherever it ... > has to be associated with a hardware device in SPECIAL-NAMES. ... > that ALTER *always* modifies the address parameter of the hardware branch ...
    (comp.lang.cobol)
  • ANSI C compliance
    ... "My boss would fire me if I wrote 100% ANSI C code" ... standard which is defined by an international committee. ... as intended on all platforms for which you have an ANSI C compiler, ... Writing truly standard C as valued by the "regulars" ...
    (comp.lang.c)
  • Re: interesting use of NEXT SENTENCE vs. CONTINUE
    ... These days I don't do compiler maintenance, but I HAVE done in the past, so ... You had a chance to point out how adherence to the standard can improve ... >> compile it WITH MINOR MODIFICATIONS for a specific platform. ... > platform-specific extension to COBOL ...
    (comp.lang.cobol)
  • Re: Ping from C/C++ doesnt work properly using either System() or popen()
    ... The only correct result, on *any* architecture, is 1. ... but quoting the ANSI standard is a red herring. ... guarantee a given compiler will even be ANSI C compliant. ... No assumption about ANSI C compliance should be made... ...
    (comp.os.linux.networking)