Buffer overflow issues with NAGware f95 v 4.1 
Author Message
 Buffer overflow issues with NAGware f95 v 4.1

Hi

        Thanks to everyone who helped with the precision problem. It seems that the
maximum precision is selected_real_kind(15). It compiles now.

        Anyways, I tried to run this program for whatever it was worth, and came up
against after a successful start :

Buffer overflow on output
Program terminated by fatal I/O error
Aborted

        A google search for this yields :

        http://www.*-*-*.com/ #FAQQ8

        Now, from a practical standpoint, I have plenty of write statements in my
program and it would be painful to added the recl= clauses for each one of
them (btw. what is the de{*filter*} that comes with NAGware ?) just because NAG
is unable to deal with some formatted writes (never had such problems with
IFC or Sun f95). Is there some kind of global directive I could use to get
past this mess ?

Thanks.

(never knew working with NAG would be so painful)



Sat, 17 Mar 2007 08:39:58 GMT  
 Buffer overflow issues with NAGware f95 v 4.1


Quote:
> Hi

>         Thanks to everyone who helped with the precision problem. It
seems that the
> maximum precision is selected_real_kind(15). It compiles now.

>         Anyways, I tried to run this program for whatever it was worth,
and came up
> against after a successful start :

> Buffer overflow on output
> Program terminated by fatal I/O error
> Aborted

>         A google search for this yields :

>         http://www.*-*-*.com/ #FAQQ8

>         Now, from a practical standpoint, I have plenty of write
statements in my
> program and it would be painful to added the recl= clauses for each one
of
> them (btw. what is the de{*filter*} that comes with NAGware ?) just because
NAG
> is unable to deal with some formatted writes (never had such problems
with
> IFC or Sun f95). Is there some kind of global directive I could use to
get
> past this mess ?

> Thanks.

> (never knew working with NAG would be so painful)

So switch to Mathematica (Wolfram) or Matlab (Moler), etc., which have
solid leadership behind them, instead of relying on fortran computational
hobbyists.

--
You're Welcome,
Gerry T.
______
"A cynic is one who knows the price of everything and the value of
nothing." -- Oscar Wilde.



Sat, 17 Mar 2007 12:53:38 GMT  
 Buffer overflow issues with NAGware f95 v 4.1
Quote:
> Now, from a practical standpoint, I have plenty of write statements

 > in my program and it would be painful to added the recl= clauses for
 > each one of them

RECL goes on the OPEN, not a READ or WRITE.

AFAIK, the standard guarantees a minimum record length for formatted I/O,
but the implementation is free to choose any higher value as the default
- or not, as the implementor sees fit. If you always expect a longer record
length, write an editor macro to always insert a RECL=...

        Jan



Sat, 17 Mar 2007 15:00:27 GMT  
 Buffer overflow issues with NAGware f95 v 4.1

Quote:

>> Now, from a practical standpoint, I have plenty of write statements
>  > in my program and it would be painful to added the recl= clauses for
>  > each one of them

> RECL goes on the OPEN, not a READ or WRITE.

> AFAIK, the standard guarantees a minimum record length for formatted I/O,
> but the implementation is free to choose any higher value as the default
> - or not, as the implementor sees fit. If you always expect a longer
> record length, write an editor macro to always insert a RECL=...

> Jan

Sorry about that.

I have plenty of files that i/o'ed as well. I found dbx90 to localize this
problem, but it quit after complaining that it could not find module
F90_UNIX (which I use for getarg).



Sat, 17 Mar 2007 19:43:40 GMT  
 Buffer overflow issues with NAGware f95 v 4.1

Quote:

> Now, from a practical standpoint, I have plenty of write statements in my
> program and it would be painful to added the recl= clauses for each one of
> them

You do not put recl= in write statements.  Read the reference that you
cited again.  The recl= goes in open statements.

Quote:
> (btw. w just because NAG
> is unable to deal with some formatted writes (never had such problems with
> IFC or Sun f95). Is there some kind of global directive I could use to get
> past this mess ?

Well first, the OPEN statement is much like a "global" for all I/O on
the unit opened.  Second, if you are writing "long" formatted
records with any f90 compiler, I recommend exlicitly specifying a recl.
I've run into quite a few compilers that had annoyingly low defaults.
I might add that included old Sun f90 compilers, though recent ones have
higher defaults.  My usage of the term "long" is intentikonally vague.
I'd advise specifying recl on anything larger than about 132 characters
per record for formatted; that might be overly cautious...but it's what
I'd advise anyway.

If your formatted records aren't unusually long, then there may be more
subtle reasons for the error.  Hard to tell from the data I have.

--
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



Sat, 17 Mar 2007 22:58:44 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. KIND related issues on NAGware f95 v 4.1

2. Announcement: Release 4.1 of the NAGWare f95 Compiler

3. NAGWare f95 licencing issues...

4. Announcement: NAGWare f95 Release 5

5. NAGware compiler -- f95 to C

6. Feedback on NAGWare f95 Compiler R5/MinGW

7. allocatables in structures (NAGware f95)

8. Announcement: NAGWare f95 Release 4.2

9. IOSTAT, EOF and NAGWare f95

10. NAGWare f95 Release 4.0 Now available

11. NAGWare f95 4.0 Public Beta Test

12. mysterious buffering and MVC in Objectworks\Smalltalk version 4.1

 

 
Powered by phpBB® Forum Software