bagpiper@mcosm.uucp (06/02/90)
I've been trying to use VMS GNU c v1.36 (and I am using the VMS c rtl libs..so
this probably isn't GNU specific). I had a piece of code under MS-DOS
which reads a file in binary mode (fopen("filename","rb")). This piece of code
does not work under VMS because all of the cr's get cooked out of the file.
The files record attribute is "Carriage Return Carriage Control". I am using
fgetc to read data out of the file. Any hints, clues, ect. I am fairly
new to VMS so I don't know all the insides of RMS. Is there any way to do
this using portable c? How about some RMS call? (oh, I am using VMS 5.1-1...
that shouldn't make much of a difference should it???)
Thankx for any help,
Michael
-------------------------------------------------------------------------------
+ Michael Hunter {backbone}!hacgate!trwind!mcosm!bagpiper +
+ BIX:bagpiper +
+ NOTHING like a spacecraft with a bad attitude!!! +
-------------------------------------------------------------------------------pauls@lion.inmos.co.uk (Paul Sidnell) (06/13/90)
>which reads a file in binary mode (fopen("filename","rb")). This piece of code >does not work under VMS because all of the cr's get cooked out of the file. >The files record attribute is "Carriage Return Carriage Control". I am using >fgetc to read data out of the file. Any hints, clues, ect. I am fairly So you love the VAX too :-) If your program had survived a little longer, it's dying comment may have been "I CAN'T FIND EOF EITHER" ! My understanding (arrived at with much pain and frustration) is that if a file already exists, the mode that you open the file in is ignored completely. If you delete the file and THEN fopen("filename","rb"); then a 'STREAM-LF' file will be created and everything will be happy again. Similarly you will find many 'departures' from ANSII C using ftell and fseek on non 'STREAM-LF' files. Generally, the I/O is at it's sanest ONLY on these types of files. Please excuse any froth around my mouth while I discuss this subject. ------------------------------------------------------------------------------- | Disclaimer: IT'S ALL MY FAULT | -------------------------------------------------------------------------------
daniels@hanoi.enet.dec.com (Bradford R. Daniels) (06/15/90)
The VAX C RTL tries to "do the right thing" with record files. If the file has a carriage control attribute (e.g. carriage return carriage control in this case), it will (by default) append a newline to each record as it is read in. Your fopen() statement, however, specifies "rb" as the file open mode, or "read only in binary mode". This specification that the file is binary overrides C's default carriage control interpretation, and you get the data unadorned, as it were, with newlines. This is fine if you're truly reading a binary file which just happens to be in variable record format, but in the case of the file in question, the record format is significant, and the file is not, in fact, simply binary data. Hope this helps. - Brad ----------------------------------------------------------------- Brad Daniels | Digital Equipment Corp. almost DEC Software Devo | definitely wouldn't approve of "VAX C RTL Whipping Boy" | anything I say here...
daniels@hanoi.enet.dec.com (Bradford R. Daniels) (06/15/90)
In article <7459@ganymede.inmos.co.uk>, pauls@lion.inmos.co.uk (Paul Sidnell) writes: > My understanding (arrived at with much pain and frustration) is that if a file > already exists, the mode that you open the file in is ignored > completely. If you > delete the file and THEN fopen("filename","rb"); then a 'STREAM-LF' file > will be > created and everything will be happy again. Huh? "rb" opens the file read only. Of course the file will still have whatever attributes it had before it ws opened. VAX C tries to balance Unix compatibility and VMS integration wherever possible. On Unix, opening an existing file whether for input or output changes nothing about the file except the date and possibly its contents (if you're truncating the file). Other attributes (ownership, permissions, etc.) remain unchanged. The first implementors of the VAX C RTL decided (quite reasonably, I feel) to extend that concept to the much larger set of attributes files may have under VMS. Thus, if you supercede an existing file, it should (were it not for some bugs in certain code paths in the RTL) have the same protection, format, carriage control, and whatever else as the existing version of the file. If you did not explicitly specify any file format or carriage control options, the C RTL assumes you don't want to change anything. > Similarly you will find many 'departures' from ANSII C using ftell and fseek on > non 'STREAM-LF' files. Yeah, it kinda bugs me, too... It actually would have been possible to get better emulation for files smaller than 4MB if a different encoding had been chosen from day 1, but the algorithm would have been completely broken for larger files, and the values returned by ftell() would not have been simple integer offsets from the beginning of the file. As it is, the current algorithm is the best you can do given 32 bit integers and RMS' requirements. > Generally, the I/O is at it's sanest ONLY on these types of files. Actually, it's pretty sane on most file types if you know what it's supposed to do. The problem is a lack of documentation as to what it's supposed to do... > Please excuse any froth around my mouth while I discuss this subject. We've been looking over ways to improve the VAX C I/O system in a major way, perhaps even rewriting the whole thing. Constructive frothing is always appreciated. - Brad ----------------------------------------------------------------- Brad Daniels | Digital Equipment Corp. almost DEC Software Devo | definitely wouldn't approve of "VAX C RTL Whipping Boy" | anything I say here...