Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!CITHEX.CALTECH.EDU!carl From: carl@CITHEX.CALTECH.EDU.UUCP Newsgroups: comp.os.vms Subject: Re: C RTL [again?] Message-ID: <870607122607.00h@CitHex.Caltech.Edu> Date: Sun, 7-Jun-87 15:26:17 EDT Article-I.D.: CitHex.870607122607.00h Posted: Sun Jun 7 15:26:17 1987 Date-Received: Tue, 9-Jun-87 00:48:20 EDT References: <12308535119.47.AWALKER@RED.RUTGERS.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 130 > Did I miss it back whenever, or is there really a bug in VAXCRTL that > silently limits the size of a read() to 65535 bytes? I found this the hard > way, while porting unix "ispell" to vms -- down there in the dirty stuff > called by read(), at childopen+0b9 there's a "movzwl" that trashes the high > half of the "int nbytes" argument you fed it. *Why*?!?! There is no > mention of any limitation in the vax C book [but then again, it's the vax C > book]. > This is Vax-11 C v2.1 [I should probably have a later one, I know] and the > image header of vaxcrtl contains the string "VAXCRTL ... V04-005" [if that > helps]. > I did finally work around the various limitations and have a version of > "ispell" that works under vms, if anyone wants it. It's not clear to me whether what you're calling a bug is a bug in the C run-time library, a bug in RMS, a bug in the disk ACP or in the device driver for disks, or simply an attempt to insure that all of the above adhere to the definition of the file system they run on, a rather nice idea if you ever plan to move data from your machine to another or to move software from a machine that assumes it will be dealing with FILES-11 ODS-2 disks, rather than some strange combination of FILES-11 and whichever file system happens to be in vogue among UNIX users these days. The following are excerpts from DEC's description of the FILES-11 On-Disk-Structure, Level 2 file system, in particular, their definition of a disk, of a volume, and of a file (the latter is taken from the chapter on RMS). The comments between the excerpts are, of course, mine. +-----------------------------------------------------------------------------+ | ODS-2 defines the largest record supported at the hardware level to be 64K. | | Software that insists on using larger records won't be guaranteed portable. | +-----------------------------------------------------------------------------+ 2.1 Volume The basic medium that carries a Files-11 structure is re- ferred to as a volume. A volume (also often referred to as a unit) is defined as an ordered set of logical blocks. A logical block is an array of 512 8-bit bytes. The logical blocks in a volume are consecutively numbered from 0 to n-1, where the volume contains n logical blocks. The number as- signed to a logical block is called its logical block number, or LBN. Files-11 is capable of describing volumes up to 2**32 blocks in size. In practice, a volume should be at least 100 blocks in size to be useful. The logical blocks of a volume must be randomly addressable. The volume must also allow transfers of any length up to 65K bytes, in multiples of four bytes. When a transfer is longer than 512 bytes, consecutively numbered logical blocks are transferred until the byte count is satisfied. In other words, the volume can be viewed as a partitioned array of bytes. It must allow reads and writes of arrays of any length less than 65K bytes, provided that they start on a logical block boundary and that the length is a multiple of four bytes. When only part of a block is written, the con- tents of the remainder of that logical block will be unde- fined. The logical blocks of a volume are grouped into clusters. The cluster is the basic unit of space allocation on the vo- lume. Each cluster contains one or more logical blocks; the number of blocks in a cluster is known as the volume cluster factor, or storage map cluster factor. A volume is identified as a Files-11 volume by the home block. The home block is located at a defined physical lo- cation on the volume, and is identified by the presence of checksums and predictable values. The home block is des- cribed in detail in section 5.1. To identify the volume, the home block contains a volume label, which is a string of up to 12 ASCII characters. The characters are restricted to the printing ASCII set (i.e., excluding control characters and rubout). Further, it is recommended that volume labels be restricted to alphanumerics only to avoid conflicts with the command languages of supporting systems. The volume label of a volume may not be null. +-----------------------------------------------------------------------------+ | Still not convinced? Well, DEC's definition of a file involves a 64K limit | | on the record size, as indicated below. Larger than that, RMS doesn't like. | +-----------------------------------------------------------------------------+ 3.0 Files Any data in a volume or volume set that is of any interest (i.e., all blocks not available for allocation) is contained in a file. A file is an ordered set of virtual blocks, where a virtual block is an array of 512 8-bit bytes. The virtual blocks of a file are consecutively numbered from 1 to n, where n is the hightes numbered block that has been allocated to the file. The number assigned to a virtual block is called (obviously) its virtual block number, or VBN. Virtual blocks are mapped to unique logical blocks in the volume set by Files-11. Virtual blocks may be processed in the same manner as logical blocks. Any array of bytes less than 65K in length may be read or written, provided that the transfer starts on a virtual block boundary and that its length is a multiple of four. For most files, all VBN's less than or equal to the highest VBN allocated map to some LBN in the volume set. Such files are said to be dense. Files which are sparse contain virtu- al blocks which have not been allocated logical blocks. +-----------------------------------------------------------------------------+ | Well, then maybe you can explain how a record length biffer than 65535 fits | | in a two-byte field? Of course this doesn't apply to STREAM and UDF files. | +-----------------------------------------------------------------------------+ 7.2.3 F.RSIZ 2 Bytes - Record Size In files containing fixed length format records this word contains the size of the records in bytes. In Sequential files containing variable or variable with fixed control formatted records this field contains the size in bytes of the longest record in the file. This field is undefined for Relative and Indexed files containing variable or variable with fixed control format records. +-----------------------------------------------------------------------------+ | As a matter of fact, with variable-record-length files, RMS is unhappy with | | anything over 327567 bytes long. Such records are declared invalid by RMS. | +-----------------------------------------------------------------------------+ 7.2.9 F$MRS 2 Bytes - Maximum Record Size This field contains a user specified maximum re- cord size limit in bytes, to be enforced on output operations. Files containing Fixed length format records have F$MRS set equal to F$RSIZ. For all other record formats F$MRS is set to the user specified value given when the file was created. A value of 0 is interpreted as no maximum record size limit specified.