C/C++ Interactive Guide/c-cplusplus-interactive-guide.iso/c_ref/csource3/137_01/apr84col.ddj

Text File | 1979-12-31 | 18.2 KB | 484 lines

.pl 61
.po 0
..
.. this article was prepared for the C/Unix Programmer's Notebook
.. Copyright 1984 Pyramid Systems, Inc.
..
.. by A. Skjellum
..
.he "C/Unix Programmer's Notebook"   for April 1984 DDJ.


                               Introduction

    Readers  responded to my December,  1983,  column where I discussed



perceived  deficiencies in the Unix operating system.   Their comments  are



included here in part.

    The  follow-up  discussion  on runtime libraries  and  link  format



incompatibilities are also presented here.

    It  was also my intention to discuss two C compilers which  support



the  large memory  concept on the 8086.   One of the compilers has not  yet



been  received,  so this comparative review will have to be included  in  a



future column.

    I have received several more letters concerning C layout standards.



While  we  don't  have room to include their  comments  at  present,  their



comments will undoubtedly lead to several columns concerning related topics



of interest.

                            Comments about Unix

    In the December column,  I mentioned several aspects of  Unix which



I believe constitute weaknesses.   Tony LiCausi of Canoga Park, California,



sent me a letter with his dissenting opinions.  He begins by remarking:

    "Unix was designed for the programming environment, for use by folk

already  familiar with computers.   Unnecessary I/O slows down a  program's

performance and hence should be eliminated.   Thankfully verbosity is often

eliminated,  in Unix,  as the default option.  However many of the programs

do  have  command line switches to increase the progress reporting  of  the

program."

    Unix  was  designed to circumvent the flaws of  existing  operating



systems. Under Unix, modular programs are coupled via pipelines to create a



convenient   working   environment   and  reduce  repetition   of   effort.



Furthermore,  Unix  offers unequalled portability between large  and  small



computer  systems.   Since  it  is successful  in  these  respects,  Unix's



popularity  is growing.   Hence,  more and more computer users are  gaining



access  to machines which use Unix.   Many of these users are familiar with



computers  and programming while others are novices to both  computing  and



Unix.

    Let's  assume that a user is well-versed in programming but is  new



to  Unix.   According  to Mr.  LiCausi,  this user belongs to the group  of



people  for  whom  Unix was designed.   I'll assume that the  user  has  an



application  in mind,  since the average user won't be writing programs  as



ends unto themselves.  To succeed in implementing his application, the user



will have to learn about various aspects of Unix,  including various  shell



commands, system calls, and runtime libraries.  However, I submit that this



type  of user will be slowed down significantly by overall poor quality  of



the Unix documentation.  Since examples in the Unix documents are typically



both terse and highly complicated, the typical user could spend an enormous



amount of time circumventing a single snag.

    Imagine  linking  the mathematical function library as part of a  C



compilation.  Two seemingly possible ways for doing this are:

        cc -o test test.c -lm

or

        cc -lm -o test test.c

It  turns out that the former method is correct while that latter  produces



undefined  function  error messages at  the  linker  stage.   However,  the



documentation  does not indicate that the '-lm' must be near the end of the



line.

    Our  hypothetical  user  will also be slowed down  by  the  cryptic



nature  of error messages.   It is true that the more  sophisticated  users



require  little or no prompting,  and only gentle nudges when they make  an



incorrect  entry,  but the vast majority of users probably don't belong  to



this category.


    Finally,  the  user  will  be slowed down by inexplicable  and  un-



documented bugs in systems such as troff and eqn which I mentioned  before.



Furthermore,  circumventing bugs requires highly specific knowledge.  Also,



the  solutions,  even if available,  may not be widely known.   On the Unix



machine I use,  only a small group of people are aware of the procedure for



avoiding some common, but annoying, bugs in eqn.

    Mr. LiCausi makes a very valid point concerning this:

    "Software  bugs are not acceptable in any form at any  time.   Unix

from  Bell Labs is sold as unsupported software.   Their attitude is,  'OK,

we'll  sell it to you but,  we don't want to here from you.'  There  is  no

mechanism  to  report or correct bugs at the source.   Source code  is  not

typically  available to the average user.   Source code is guarded on  Unix

like gold;  just like any other commercial software.  Having done debugging

of  the f77 compiler on one system,  access to other software (for  example

and integration) was severely limited."

    Thus,  while Mr. LiCausi contends that Unix was designed for people



with programming experience, he sets his standard for 'unnecessary I/O' and



'program  performance' based on the most sophisticated level of Unix  user.



Furthermore, it is still not clear to me why the sophisticated users should



be more willing to stand for poor quality documentation and user-unfriendly



software  than every-day users.   Finally,  it is not at all apparent to me



from  practical  experience  that 'many' of  the  standard  shell  commands



support extended progress reporting.

    Mr. LiCausi goes on to state:

    "The secret society of Unix is partially the result of the paranoia

of  'unauthorized access.'  The remainder is due to the lack of  commercial

incentive.   The  incentive has obviously increased as can be evidenced  by

the proliferation of books and articles on Unix anc C."

    I  stated in my previous column that some users perceive Unix as  a



secret society.  This is the case because they cannot grasp certain aspects



of  its  operation  based on the written and on-line  documentation  alone.



Only through initiated members can the knowledge (and undocumented  tricks,



patches  etc.)  be obtained.   Thus people feel left  out.   Other  popular



operating  systems do not have the same aura as Unix.   For  example,  CP/M



users  are  not  considered a 'secret society' even though  CP/M  has  non-



trivial  aspects.   Furthermore,  minicomputer  operating systems  such  as



VAX/VMS  (DEC) and AOS/VS (Data General) don't have the mysterious  quality



of  Unix.   That's because they have much more documentation to explain the



nitty-gritty of using the system.

    Mr. LiCausi finishes by stating:

    "Unix  is not user-unfriendly.   Admittedly it is beginner hostile.

Changes will be required to adopt Unix en masse,  ie for the micro,  but  I

hope that it does not spell the end of 'silent' software."

    My final counter-remark is that most users never become sufficently



sophisticated  in enough diverse aspects of Unix to escape the  feeling  of



user-hostility.   I personally run into difficulties, even though I've used



Unix for almost four years.  As soon as I use aspects of Unix which are not



part of my daily routine, 'gottchas' appear.

                           Other Points of View


    H.T. Gordon sent in a letter concerning Unix.  He writes:

    "It  was a pleasure to read the Skjellum critique of [Unix] in  DDJ

#86.   Since  C/Unix  is becoming the sacred cow of the computer  Brahmins,

few have the courage to point out its flaws.  It was designed by one of the

elite,  for elite users.  To them it's concise and elegant, even 'obvious.'

Only  rarely  is any explanation needed.   If it is,  a terse one will  do.

Prophets inspired by the high gods cannot waste their time spelling  things

out for mere morals in words of one syllable."

    I  don't  think that the state of C/Unix is as bad  as  Mr.  Gordon



suggests.   While there are problems,  I think that Unix has many strengths



and these strengths will be the basis for future operating systems.   It is



the  purpose  of this column to discuss strengths and weaknesses of  C  and



Unix  and  to propose solutions as well as to point out  the  problems.   I



encourage  readers  to  pose  solutions to these and  other  problems  they



perceive.
                        Low level Input-Output in C

    Patrick Cawood of Los Angeles writes:

    "I read with great interest your last article on tendencies in Unix

to produce poor operator interaction programs.   I seem to have met some of

the same in C."

    "In order to provide a secure operator interface, one does not echo

a keyboard character to the screen until it has been examined and  approved

by the program. But getch() function automatically echoes--even line feeds,

up arrows,  etc.!!   Function putch() provides an automatic line feed after

printing on the screen!!

    He goes on to state:

    "I  simply cannot believe that anyone would wittingly design  these

functions as they are,  or not provide any alternative hardware interfaces.

Especially  considering   some of the tasks I've heard were written  in  C.

But  perhaps these people writing serious software were all forced to write

their own hardware interfaces."

    The problem which Mr.  Cawood is referring to exists in a number of



non-Unix C compilers.   To begin with, let's review the problem in the Unix



environment.   Under  Unix,  putc() and getc() acquire and return a  single



character respectively.  However, to offload the host system, many terminal



interface boards programmatically handle user input-output in lines.  Thus,



before  any input is received by the host,  a whole line must  be  entered.



Naturally,   the   characters   are  echoed  by  the   terminal   interface



hardware/firmware,  and only limited line editing is permitted.  On output,



a  whole  line is buffered up before transmission to  the  terminal.   This



process  can be overcome by use of the 'raw' terminal mode (raw implies  no



host  character  processing.)   In this mode,  the  program  is  completely



responsible for input-output.  This mode is much more expensive in terms of



input-output  cost,  since the host must handle an interrupt for each input



character  and  perform  an  output request  for  each  printed  character.



However,  as I mentioned in the previous column, this is the only way for a



program  to get full control of what is entered and appears on the  display



device.

    With the introduction of C to microcomputers, compiler implementors



often based the behavior of the runtime libraries on their Unix experiences



rather  than  on The C Programming Language.   Thus,  whole lines are  pre-



buffered  by  typical  C runtime libraries before  a  single  character  is



received  by  getc().   Conversely,  a whole line of output  is  internally



buffered before it is printed on the display.   Thus, the runtime libraries



of  microcomputer C compilers often emulate the terminal hardware found  on



real  Unix systems.   However,  this is not what putc() and getc() are sup-



posed  to do.   In the truest sense,  raw mode is the fundamental  terminal



mode.   These  functions  should really work on a  character  by  character



basis.   C libraries should permit selection between the 'raw' and 'cooked'



modes (and echo,  no-echo) and thus permit input-output flexibility without



resorting to assembly language routines.

    One  C compiler which correctly handles the low-level  input-output



is the Q/C compiler from The  Code Works.   For example,  single characters



are only required when a getchar() call is made.   However, it doesn't seem



possible to turn off the echo.   Nevertheless,  this can be effected  under



Q/C,  since  The Code Works is kind enough to provide runtime and  compiler



source code.

                               Link Formats

    In  the October,  1983,  column I discussed incompatibility between



link formats.  Readers had quite a bit to say about this and their comments



are summarized here.

    Guy Scharf of Mountain View, California, writes:

    "I  find the incompatibility of linkage editor formats to be a real

problem.   For example, I want to use Digital Research's Access Manager and

Display Manager 86 with C.   I would prefer CI-86 (because I am used to it)

but  have  to  switch  to DRI's C because  of  the  link  format.   Another

compiler to learn and idiosynchracies to surmount."

    He concludes:

    "I'm not sure what to do about this problem (except complain).

    David D. Clark of State College, Pennsylvania, writes:

    "The  big problem isn't really the format of linkable files.   Even

compilers  that use Microsoft's M80 and L80 will not allow linkage to  code

produced  by  different compilers.   The function  calling  protocols  vary

tremendously  from  compiler  to  compiler.   BDS C  and  Q/C  have  fairly

straightforward function calling protocols.  Eco-C,  on the other hand, has

a  tortuous function calling sequence.   And even though Q/C and Eco-C  use

the Microsoft assembler and linker, the code files produced by them are not

compatible."

    The  problem that Mr.  Clark mentions is also present in  the  8086



(MS-DOS,  CP/M-86)  world.   Code from different compilers cannot be  mixed



because:

        1. each requires its own main function
        2. a wide variety of link formats exist
        3. calling conventions differ between compilers.

The  first two points are essentially insurmountable problems from the  end



user's point of view.   However,  the third point can be overcome by adding



dummy routines to convert calling conventions.

    Mr.  Clark makes some additional points concerning the deficiencies



of  the  8080 Microsoft .REL (relocatable) format.   These are of  interest



since many 8080 C compilers rely on this format.  His comments are included



in Figure I. in tabular form.

               ------------------FIGURE I.------------------
              Deficiencies in the Microsoft 8080 .REL format
                           and related software

    1.    M80  and  DRI's  RMAC  assemblers  only  support  six  unique

        characters (all upper case).  This is awkward for many purposes.

        2.  While  the  .REL  format apparently will  handle  seven  unique

        characters, neither M80 nor RMAC support this.

        3.   Apparently the .REL format,  M80 and L80 were designed to work

        with  the  FORTRAN-80  compiler which permits  only  six  character

        symbols.   This is an old standard,  and does not reflect the needs

        of  today's compilers.   The absence of case sensitivity in symbols

        is especially limiting.

            -------------------END FIGURE I.------------------


    It is obvious that an enhanced standard is necessary for the  CP/M-



80  world.   Even  under MS-DOS,  where Microsoft has enhanced the  linkage



editor format,  problems still exist.   These problems, as I perceive them,



will be discussed next.

    Microsoft's MS-DOS linkage format supports long symbols (31  unique



characters)  and has case sensitivity.   Thus,  it overcomes the objections



that  Mr.  Clark  posed for the 8080 .REL  system.   However,  one  nagging



problem  still exists.   This is the dichotomy between object  modules  and



libraries.   Because  of this dichotomy,  the MS-DOS linker always includes



the full contents of a .OBJ module during linking.   However, libraries are



searched.   In  order to make a library efficient,  each function  must  be



compiled into its own .OBJ file.  Each .OBJ file becomes a single sub-block



in  the library;  all the functions of that sub-block file are included  at



program  linkage.   If libraries and object modules were  equivalent,  this



problem  would be overcome since the functions of an object module would be



separable during linking.

                             Runtime Libraries

    Non-standard runtime libraries are a plague to  programmers.   They



inhibit  portability,  and  introduce  bugs when  software  is  transported



between different compilers.   Charles Brady of New South Wales, Australia,



writes:

    "An enormous contribution to standardization of C programs would be

the publication of a standard I/O library for BDS C,  with, if necessary, a

modified   runtime  package.    The  very  fast  and  efficient   compiler,

particularly  with  the symbolic debugger tool,  provides a  very  inviting

environment  for software development.   It is a great pity that this means

abundant non-standard C.  As there is no inherent reason why this should be

the case ...  someone should be able to ...  produce a Unix compatible  I/O

library."

    This  point is especially well-taken in view of the large amount of



BDS  C  software  available through the C User's  Group  of  Yates  Center,



Kansas.

    In  the  case  of  the runtime library itself,  there  is  a  clear



standard.  This standard is spelled out in The C Programming Language.  All



compilers  have  to  do  is support a  proper  subset  appropriate  to  the



environment in which they work.

                                Conclusion

    In  this column,  I have included the follow-up discussions on Unix



and  on link formats/runtime libraries.   The nature of the discussion  has



been  mainly  of  a  critical  nature.   This  is  not  intended  to  be  a



condemnation of the systems, but only an impetus for readers to suggest new



ideas to improve what we already have.   Unix is a worthwhile standard  and



should  be supported.   C is a valuable tool,  but can be  improved.   This



column  is a forum in which we can discuss,  develop and nurture new  ideas



about C and Unix.