edstrom%UNCAEDU.BITNET@wiscvm.wisc.EDU (07/01/87)
In resonse to message-ID: <995@bloom-beacon.MIT.EDU> from William Sommerfeld. >>This is correct about descriptors being easy to use. His version of the VMS >>"hello world" program might look like this: > >[ 21 lines of obscure C code follow ] Only if you don't use descriptors or VMS system calls. >That doesn't look easy at all. I don't really know that much about >VMS, but.. True, but then who does? >sys$qiow() appears to be the equivalent to either write(), or >writev(), or probably both at the same time, on UNIX systems. I am not familiar with writev() but the QIOs (sys$qiow and sys$qio) are not the same as write(). In a sense write() is a subset of sys$qiow(). The sys$... family of routines are system calls that are available to programs written in all languages supported by VMS. They are requests to the operating system to perform certain functions. Calls to write() eventualy arrive at sys$qiow's door since it is the ultimate software connection to the hardware. The QIOs are not used for regular IO. They are only used for special functions like asynchronous communication or positioning disk heads to a particular cylinder. QIOs handle everything from changeing a serial line's baud rate to reading a particular block from a disk. >This routine takes 12 arguments??!? Eight of which are zero in this >case??!?? Pretty ugly, eh? Still, the QIOs are meant as the final common software pathway to ALL IO devices and so must be able to handle all contingencies. The particular example (type "hello world") was trivial and didn't need to use all of the arguments. One would think that it would be better to breakup the QIOs into several different functions but DEC didn't and that's that. Because the QIOs are meant to work with all languages it cannot use the variable length argument facility of C and you are forced to include all arguments, even unused ones. >No wonder DEC can't get the C runtime library to work correctly. The RTL works for me. Do you use it? Which RTL routines don't work? >Without those descriptors, on my UNIX system, I can write: > >main() >{ > write(1, "Hello, world!\n", 14); >} Big deal. That program works in VMS C also. Virtualy all of the routines that are available in the UNIX library are available in VMS. The point was not how to write "Hello world." on the terminal. Printf(), write(), fwrite(), puts(), etc... could have been used much more easily. The point was to demonstrate to programmers who are new to VMS how to use descriptors in C. The purpose of descriptors is to provide an unambiguous and common method for transfering data between routines written in different languages. Rather than translate or re-write FORTRAN code (which is not even possible if you are dealing with commercial packages that don't provide the source code) for use in a C program you only need to package your strings in a descriptor to pass to FORTRAN-written functions which don't understand NULL terminated strings. Descriptors are special purpose tools that are not meant for every- day use. Even mapping virtual memory to a user file does not require descriptors. >I also note that the macro he uses to initialize the descriptor uses >illegal Kernighan and Ritchie C: you can't initialize an automatic >structure. Oh yes I can on. If its not pure K&R then so what? The original description of C was a good one and the book is still very useful. That does not mean that C cannot be improved. After all the description was written on paper in New Jersey not engraved in granite on Mt Zion. I don't believe that either Kernighan or Ritchie would argue that C should never change. I haven't seen the ANSI C standard description but from what I have read and heard it, the new standard C, is not K&R C either. The ability to initialize structs makes functional sense to me. Since structs are arrays of (possibly) different data types I see no reason why you souldn't be able to initialize them like regular arrays. If it is not standard C then that is the problem of the standard definition. When you write applications specificaly for one machine/OS combination then non-standard usages are justified if they offer some advantage. Other, what I consider important, non-K&R struct usages are assigning values to structs (as in "x = y;" where x and y are both structs of the same kind), passing structs by value and returning structs by value. These features are available on VMS, some micro compilers and, so I am told, UNIX. I will not deprive myself of these features just because K&R did not include them in their original description of the C language. - John