Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: strings
Message-ID: <7228@bsu-cs.bsu.edu>
Date: 17 May 89 00:01:46 GMT
References: <2846@tank.uchicago.edu> <5785@cbnews.ATT.COM> <10087@smoke.BRL.MIL> <10245@socslgw.csl.sony.JUNET> <190@mole-end.UUCP> <10255@socslgw.csl.sony.JUNET>
Reply-To: dhesi@bsu-cs.bsu.edu (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 35

In article <10255@socslgw.csl.sony.JUNET> diamond@csl.sony.junet (Norman
Diamond) writes:
     The answer is VMS.  DEC required all of their language developers
     to conform to implementations [of strings] specified by the
     operating system.  This is exactly where they ran into problems
     with C.

Here are excerpts of code adapted from one of the VAX/VMS Pascal
manuals.  I have omitted some declarations and error-checking.  This
code reads a record from a channel that has been (in the original code)
assigned to a mailbox.

     var
	... other stuff ...
        read_input : varying [30] of char;  (* where input will go *)
     
     begin
     ... other code ...
     sys_stat := $qiow (chan := channel, func := io$_readvblk, 
                        iosb := io_statblk,
                        p1 := read_input.body,
                        p2 := size (read_input.body) );
     read_input.length := io_statblk.count;
     ... other stuff ...
     end.

Note that we could not simply pass our variable-length string variable
read_input to QIOW.  Instead, we had to separately pass the address of
the data area of the string (called read_input.body) and its maximum
size.  Then when input was complete, we had to copy the byte count from
the status block field io_statblk.count into the length field of
read_input.length.
-- 
Rahul Dhesi <dhesi@bsu-cs.bsu.edu>
UUCP:    ...!{iuvax,pur-ee}!bsu-cs!dhesi