🚀 go-pugleaf

rbp@netcom.com (Bob Pasker) writes:

>it seems that the functions i would expect to be included with a C
>compiler have not come with GNU C, but instead the directions tell me
>to link with the VAX C run-time library (VAXCRTL).  so, still ok, i
>have an old version of the VAX C complier on the machine (VAX-11 C
>2.3).

>now, however, i see that there is a difference (bug?) in the VAXCRTL
>function versus the function included in the DOS compiler that i am
>busily converting from.  the function read() is supposed to read the
>*exact* number of bytes (up to EOF), but the read() from VAXCRTL seems
>to act more like fgets() and returns only the first *line* of the
>file.

>can anyone shed some light on (1) why the GNU compiler doesnt have
>these intrinsic functions? if i didn't have the VAXCRTL would i be
>SOL? (2) why my read() of 720 bytes from a 720 byte file returns only
>the first 24 bytes (the first line)?

This is entirely the fault of the VAXCTRL which implements the open/read
/write/lseek/close system calls on top of the RMS File System.  I don't
know if they fixed it any from the last time I gave up in frustration.
The problem is that the RMS system is inherently record oriented.  The
result is that lseeks and reads tend to only work well when the read pointer
is on a record boundary for certain file types.  The closest you can
get to a DOS or UNIX file is to specify that you want STREAM_LF record
structure via the RMS extension to the open function.  Basically your
in for a big pain in the ass if you need to do anything but sequential line
by line I/O or direct fixed length record access.  Try rereading the RMS
extension described in the VAX C manual for more details.

--MDM
-- 
 _________________________________________________________________________ 
(  _______________________________   Brain, and brain!  What is brain!    ) 
 \________________________________)        --Star Trek (Spock's Brain)   /
El_Rayo_X_______________________________________________________________/