public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jerry DeLisle <jvdelisle@charter.net>
To: "Browning,
	Robert S IV ERDC-RDE-GSL-MS CIV"
	<Robert.S.Browning@erdc.dren.mil>,
	"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
Subject: Re: read CSV data consistently from string or file
Date: Sat, 13 Oct 2018 16:23:00 -0000	[thread overview]
Message-ID: <6cdf9426-2c5b-bb4d-99e3-677239fcb451@charter.net> (raw)
In-Reply-To: <10d458a1-d2e6-fd1e-abc0-0126f03d0271@charter.net>

On 10/12/18 4:52 PM, Jerry DeLisle wrote:
> On 10/12/18 1:10 PM, Browning, Robert S IV ERDC-RDE-GSL-MS CIV wrote:
>> I am needing to read in a text file that contains numerical data 
>> separated by keywords. Because of the keywords, I need to read each 
>> line in as text first and test if it’s a keyword, and then call the 
>> appropriate subroutine based on the keyword value. Within the 
>> subroutines I also need to read each line as text first so I can stop 
>> the subroutine when the next keyword is found.
>> The numerical data can be in either fixed format or 
>> comma-separated-value (CSV) format. In the CSV data, a zero could be 
>> represented by a pair of commas with no number between them.
>> The issue I have encountered is that the read statement appears to 
>> behave differently when it is reading from a character string than 
>> when it is reading directly from the input file. If I were able to 
>> read directly from the input file, then a simple formatted read 
>> statement does everything I need. But if I am reading from a string, 
>> then things get a bit more complicated.
> 
> Hi Robert,
> 
> This may be a known bug. It sounds familiar. Let me do some checking.
> 
> Fortranners, if I confirm this is the bug I think it is, I think I can 
> squeeze some time to fix it.
> 
> Jerry
> 

I am fairly certain this is PR78351. As far as we can tell the code is 
non-conforming Fortran but the use of comma to terminate a read has been 
around forever and gfortran supported this before.  It was my breakage 
in my endeavors to improve string I/O performance. I feel obligated at 
this point to set it straight.

Jerry

  reply	other threads:[~2018-10-13 16:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <10B680D9-A65E-4B86-9F7C-760184201DAB@contoso.com>
     [not found] ` <0A2AF1BD-224D-4EC7-BD4C-52CEBBDAF1AF@erdc.dren.mil>
2018-10-12 20:10   ` Browning, Robert S IV ERDC-RDE-GSL-MS CIV
2018-10-12 23:53     ` Jerry DeLisle
2018-10-13 16:23       ` Jerry DeLisle [this message]
2018-10-13 19:43         ` Jerry DeLisle
2018-10-14 10:02           ` Bernhard Reutner-Fischer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6cdf9426-2c5b-bb4d-99e3-677239fcb451@charter.net \
    --to=jvdelisle@charter.net \
    --cc=Robert.S.Browning@erdc.dren.mil \
    --cc=fortran@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).