libf2c/10885: On 64-bit targets one can write >2Gb records in sequential files, but not in direct access files

[email protected]
Newsgroups gmane.comp.gcc.prs
Message-ID <20030520203321.32205.qmail__6863.93620349026$1053463653@sources.redhat.com>
>Number:         10885
>Category:       libf2c
>Synopsis:       On 64-bit targets one can write >2Gb records in sequential files, but not in direct access files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 20 20:36:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Winfrid Tschiedel
>Release:        all
>Organization:
>Environment:
all 64-bit targets
>Description:
The following code aborts with:

do_ud: off end of record
apparent state: unit 10 named fort.10
lately writing direct unformatted external IO

Sequential I/O uses `long' as the type of the record length,
which will be 64 bits on most 64-bit targets.
Direct I/O should do the same.
The compiler accepts an INTEGER*8 as an argument to
RECL=... on the open statement - see if that really is
compiled correctly.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="wt.f"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="wt.f"

ICAgICAgICByZWFsKjggYSgxMDI0LDEwMjQsMzg0KQogICAgICAgIHJlYWwqOCB0MSx0Mix0MCxl
bGVtZW50CiAgICAgICAgcmVhbCo4IHNlY29uZAogICAgICAgIGludGVnZXIqOCByZWNsCiAgICAg
ICAgaW50ZWdlciBpcmMKICAgICAgICByZWNsPTEwMjRkMCoxMDI0ZDAqMzg0LmQwKjguZDAKICAg
ICAgICBlbGVtZW50PTAuCiAgICAgICAgb3BlbiAodW5pdD0xMCxhY2Nlc3M9ImRpcmVjdCIscmVj
bD1yZWNsLGlvc3RhdD1pcmMsCiAgICAgKiAgICAgICAgZm9ybT0idW5mb3JtYXR0ZWQiKQogICAg
ICAgIHdyaXRlICh1bml0PSosZm10PSopICIgb3BlbiByZXR1cm5lZCAiLGlyYwogICAgICAgIGRv
IGw9MSwzODQKICAgICAgICAgIGRvIGo9MSwxMDI0CiAgICAgICAgICAgIGRvIGk9MSwxMDI0CiAg
ICAgICAgICAgICAgZWxlbWVudD1lbGVtZW50KzEuZDAKICAgICAgICAgICAgICBhKGksaixsKT1l
bGVtZW50CiAgICAgICAgICAgIGVuZGRvCiAgICAgICAgICBlbmRkbwogICAgICAgIGVuZGRvCiAg
ICAgICAgd3JpdGUgKHVuaXQ9KixmbXQ9KikgIiBhcnJheSBhIHNldCAiCiAgICAgICAgd3JpdGUg
KHVuaXQ9KixmbXQ9KikgYSgxLDEsMSksIiAuLi4gIixhKDEwMjQsMTAyNCwzODQpCiAgICAgICAg
d3JpdGUgKHVuaXQ9KixmbXQ9Iih6MTcuMTYsZzE2LjUpIikgdDEsdDEKICAgICAgICB0MT0gIHNl
Y29uZCgpCiAgICAgICAgd3JpdGUgKHVuaXQ9MTAscmVjPTEpIHQxLGEKICAgICAgICB3cml0ZSAo
dW5pdD0xMCxyZWM9MikgdDEsYQogICAgICAgIHQyPSAgc2Vjb25kKCkKICAgICAgICB3cml0ZSAo
dW5pdD0qLGZtdD0iKHoxNy4xNixnMTYuNSkiKSB0Mix0MgogICAgICAgIHdyaXRlICh1bml0PSos
Zm10PSopIDM4NCo4KjYsICIgbWJ5dGVzIHdyaXR0ZW4gaW4gIiwKICAgICAqICB0Mi10MSwgIiBz
ZWNvbmRzICIKICAgICAgICB3cml0ZSAodW5pdD0qLGZtdD0qKSBhKDEsMSwxKSwiIC4uLiAiLGEo
MTAyNCwxMDI0LDM4NCkKISAgICAgICByZXdpbmQgKHVuaXQ9MTApCiAgICAgICAgZG8gbD0xLDM4
NAogICAgICAgICAgZG8gaj0xLDEwMjQKICAgICAgICAgICAgZG8gaT0xLDEwMjQKICAgICAgICAg
ICAgICBhKGksaixsKT0gMC5kMAogICAgICAgICAgICBlbmRkbwogICAgICAgICAgZW5kZG8KICAg
ICAgICBlbmRkbwogICAgICAgIHQxPSAgc2Vjb25kKCkKICAgICAgICByZWFkICh1bml0PTEwLHJl
Yz0xKSB0MCxhCiAgICAgICAgd3JpdGUgKHVuaXQ9KixmbXQ9KikgYSgxLDEsMSksIiAuLi4gIixh
KDEwMjQsMTAyNCwzODQpCiAgICAgICAgcmVhZCAodW5pdD0xMCxyZWM9MikgdDAsYQogICAgICAg
IHQyPSAgc2Vjb25kKCkKICAgICAgICB3cml0ZSAodW5pdD0qLGZtdD0qKSAiIHBhcnRpYWwgcmVh
ZCBpbiAiLAogICAgICogIHQyLXQxLCAiIHNlY29uZHMgIgogICAgICAgIGVuZAo=
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.