#152 closed defect (fixed)
WHIZARD ignores last line of input files
| Reported by: | sschmidt | Owned by: | ALL |
|---|---|---|---|
| Priority: | P1 | Milestone: | |
| Component: | interfaces | Version: | 2.0.0beta |
| Severity: | normal | Keywords: | input file |
| Cc: |
Description
The last line in an input file is always ignored. (All example files end with at least one blank line, so it doesn't make a difference there.) See the attached file for an example.
Attachments (1)
Change History (14)
Changed 15 years ago by
comment:1 Changed 15 years ago by
| Component: | configure → interfaces |
|---|
comment:2 Changed 15 years ago by
| Priority: | P3 → P1 |
|---|
comment:3 Changed 15 years ago by
I can't reproduce this with the current trunk and the current SVN gfortran, neither on ia32 nor on ia64. Therefore, this either is some nasty issue with incompatible runtime libraries (my bet) or some compiler issue (unlikely as Sebastian encounters this also with NAG).
comment:4 Changed 15 years ago by
I had the problem yesterday evening but I can't remember which computer it was. Probably the SuSe? Linux Quadcore, but I will recheck. The 32bit Debian doesn't show the problem today.
comment:5 Changed 15 years ago by
| Milestone: | v2.0final → v2.0-rc2 |
|---|
comment:6 Changed 15 years ago by
I retested this on my own computer (SUSE 11.1, 64bit, compiled with gcc/gfortran rev 156365, whizard r1645) and here the last line is also ignored.
comment:7 Changed 15 years ago by
I also reproduced this behaviour on MAC OS X Snow Leopard 64 bit with gfortran.
comment:8 Changed 15 years ago by
OK, my bad can reproduce it now - this happens if the input file doesn't contain a final LF (hex 0A), which vim seems to always add. I'll try to track this critter down.
comment:9 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed in r1656. This was a nasty one: WHIZARD requires an end-of-record condition to process a line, but this only generated when a LF is encountered. If the last line lacks the LF, an EOF is generated instead by the runtime, making WHIZARD ignore the line. I've added an eof flag to the stream_t structure which allows stream_get_record to remember the EOF, return the string which has been read and return EOF on the next call. Again, WK might want to make sure that he is fine with the patch.
comment:10 Changed 15 years ago by
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Still broken for NAG.
comment:11 Changed 15 years ago by
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Fixed for NAG in r1657; this was a side-effect of WK's workaround in iso_varying_string.f90. On the broken compiler, we have no way of finding out how many characters were read before encountering the LF, so I changed GET_BUFFER_LEN to 1 in order to force char-by-char input. This works, but as I dislike the necessity to hack iso_varying_string.f90 this way, I would be very much in favour of reverting this file to its original state as soon as we can afford dropping support for the broken NAG versions.
comment:12 Changed 15 years ago by
There's a discussion on comp.lang.fortran on this issue:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0bf36466c2278c39#
Confirmed by JR: if the last line contains the only integrate statement, WHIZARD does not integrate at all. Although that is a trivial one, it's a really nasty one. It can completely screw up the user. Ranking it high.