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 19:43:00 -0000	[thread overview]
Message-ID: <5e0503be-07fb-8479-bb70-cb7fddc9dbc4@charter.net> (raw)
In-Reply-To: <6cdf9426-2c5b-bb4d-99e3-677239fcb451@charter.net>

On 10/13/18 9:23 AM, Jerry DeLisle wrote:
> 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
> 

The patch attached to pr78351 fixes this and regression tests cleanly.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351

I am wondering if I should put the check behind some condition related 
to the standards to avoid the extra string scan or just leave it as is 
in the patch.

Regards,

Jerry


  reply	other threads:[~2018-10-13 19:43 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
2018-10-13 19:43         ` Jerry DeLisle [this message]
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=5e0503be-07fb-8479-bb70-cb7fddc9dbc4@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).