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

Text File | 1979-12-31 | 16.7 KB | 464 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 August, 1984 DDJ.


                               Introduction

    In  this  column,  we'll discuss some of the feedback  received  in



response to previous columns, as well as some miscellaneous remarks.

                         uucp (Unix to Unix Copy)

    Mike  Meyers  of  Norman,  OK,  suggested that I  publish  my  uucp



address.   Via  this address,  users on other Unix systems can send me mail



electronically by using the standard Unix mail command.   A uucp address is



specified   relative   to   a   well-known   site.    Thus,   the   address



"ucbvax|cithep|tony"  should allow most users to reach me.   If  your  site



cannot communicate with ucbvax (UC Berkeley) directly, more site names will



have  to be prepended onto this address,  and onto to those listed below as



well.   On  the  other  hand,  if  your site can  communicate  with  cithep



(Caltech High Energy Physics) directly, the ucbvax prefix may be omitted.

    If  a  continuing electronic dialog develops,  I will  occasionally



publish   the  uucp  addresses  of  those  involved  so  that  others   may



participate.   At  the moment,  the following users are participating in  a



discussion about Unix:

        ucbvax|mtxinu|ea|jab   (Jeff A. Bowles)
        ucbvax|cithep|yekta    (Yekta Gursel)
        ucbvax|mtxinu|ea|emjej (James Jones)
        ucbvax|mtxinu|ea|mwm   (Mike Meyers)

Interesting  remarks will be included in future columns for the benefit  of



those readers who cannot access the electronic mail.

                               C Users Group

    Phillip  K.  Landis  of Satellite Beach,  FL,  inquired  about  the



address of the C Users Group of Yates Center,  KS, which I mentioned in the



April column.  Their address and telephone are as follows:

        C Users Group
        105 E. Rutledge
        Yates Center, KS  66783
        [phone]

This  particular  group has 34 volumes of C programs and offers them  in  a



variety  of  disk formats (only for microcomputers).   If there  are  other



public-domain C repositories,  I would like to print their addresses  also.



If you know of one, please forward me their address.

                              Public Domain C

    Robert E. Fiorini of Albany, NY, writes:

    "I'm a new 'C' user trying to find an inexpensive (possibly public-

domain) 'C' compiler (with source code...if possible).  My own efforts have

been  fruitless.   I'm hoping that you or one of your readers may know of a

source  where  I  can find such a compiler.   If you can  help  me  in  any

way...please HELP !!...It's funny,  the only thing holding me back from the

world of C is the C)ompiler itself.  "

    Rod  Cain's Small C is available through the C User's group  listed



above.   An enhanced version (not public domain) for 8080/Z80 CP/M  systems



is available (with source code) from The Code Works of Goleta,  CA.  (Their



address  can  be found in any number of DDJ back issues.)  This  particular



compiler  (Q/C)  is  a  serious subset  implementation  and  includes  full



compiler  source  for $95.00.   An IBM version of this  product  should  be



available  later this year and would be well-worth the investment if priced



comparably to the CP/M version.

                       Comments about C input-output

    Mike Meyers writes:

    "What  you haven't seemed to realize is that almost every  flaw  in

Unix  also  appears in C.   C is terse,  doesn't protect the user,  and  is

poorly  documented.   The  only documentation for C is K&R  [Kernighan  and

Ritchie],  which may be well-written,  but is vague and inconsistent on all

the points you turn to for when you start implementing the language on  new

machines.   To  make matters worse,  nobody (and I do mean nobody) sells  a

compiler that conforms to K&R,  not even AT&T.   I don't think anybody ever

has,  in any case.  AT&T distributes a version of pcc [portable C compiler]

that  met  K&R  internally,  but I think that by the time it  was  released

externally, C had grown past K&R."

    Gerald I. Evenden of N. Falmouth, MA responded about C input-output



as follows, with quite a different point of view:

    "I  was very disturbed with a basic concept about the C programming

language that you kept implying in your column in the April  issue.   First

of all I suggest that you carefully read the beginning paragraph of chapter

7 of Kernighan and Ritchie's book: "The C Programming Language."  It begins

with  'Input and Output are not part of the C Language,  ...'  What remains

is  a  description of i/o procedures contained in a standard  UNIX  library

which will take care of most filter type of functional operations.   I have

generally  found  them to be quite adequate for  most  programming  efforts

involving stream data and simple question-answer type of console i/o."

    I would like to state that I am completely aware of the distinction



between  the C language definition and the standard  input-output  library.



In teaching students how to program in C, this is one of the first points I



emphasize:  C is a language which gives no special favoritism to a specific



set of input-output routines.  One standard set does exist, and this is the



Unix standard.   I consider this an essential feature of C, but I feel that



a  discussion  of a real C compiler environment cannot always be  separated



from  a  discussion of the support library which comes  with  it.   I  also



maintain  that  the  Unix input-output library is more  than  adequate  for



dealing  with stream operations.   Mr.  Evenden summarizes the  distinction



between C and C input-output as follows:

    "The  beauty  of  C  is  that  it  doesn't  have  [a]  plethora  of

specialized  built  in functions but rather provides the programmer with  a

rich  facility  to  build tools required  for  his  own,  and  occasionally

specialized,  needs.   Obviously,  we  shouldn't  have to redesign all  the

wheels  needed,  so  most  suppliers of C compilers include  a  library  of

functions  patterned  after the UNIX libraries.   But  remember,  there  is

absolutely no requirement to use them if they don't fit your needs and they

should only be viewed as a preliminary tool kit."

    One  point that merits further exploration is that of  portability.



While it is well and good to preach the separation of C and C input-output,



only  software  which uses standard Unix input-output calls  (and  routines



built  on  them)  have a prayer of being moved  readily  between  different



machines or even between different compilers on the same machines.

    Mr. Evenden continues: "I suspect that your problem with "getc" et.

al. is related to screen editing and control which is a category of program

that  doesn't fall into the "filter" class of function emphasized  by  UNIX

(and  its libraries) and I certainly agree that these functions don't  work

in  this  case...the astute programmer writes 'rawin()' and 'rawout(),'  to

satisfy  those  needs.   There's nothing to prevent it  and  everything  to

encourage  it...The  worst possible outcome of the problems posed  in  your

article  is  to  even  remotely suggest rewriting the  current  stream  i/o

functions.   Their current form is a de facto standard and a consistency of

implementation is expected by most C programmers."

    I  really  don't  expect anyone to throw away the  existing  stream



functions.   Not  only  would  this  be  unreasonable,  it  would  also  be



undesirable.   However,  I do feel that clean raw input-output should be  a



supported capability;  it needn't be reinvented each time a Unix programmer



discovers   that  stream  input-output  is  inconvenient  for   interactive



purposes.   In  discussing  a  similar worry expressed  by  Mr.  Meyers,  I



summarized  my  argument by stating that interactive  programs  comprise  a



large  fraction  of  those run by Unix users,  and that when  a  programmer



writes  an  interactive program,  he doesn't usually want the  user  to  be



treated like an input file.

    Despite the extremely outspoken way Mr.  Evenden lectures me in his



letter,  we  actually  agree in many respects.   However,  some  things  he



brought up demand careful examination.  He states:


    "The  principle  point of this complaint is that you  should  be  a

little more careful of what you are talking about.   Writing about problems

with  C i/o is impossible since C i/o doesn't exist.   However,  your  less

experienced  readers will take your complaint to heart and decide that C is

a useless language because Mr.  Skjellum,  et. al., don't like the optional

i/o  library supplied with their compiler.   If you were more  positive  in

your  approach  you  would  be  telling readers  how  to  write  their  own

procedures to do specialized console i/o on UNIX,  CP/M, etc.. I've done it

on  both CP/M and UNIX and found it to be a piece of cake in both cases and

never gave the "getc" group a second thought when it was obvious that  they

were not meant for the job at hand."

    The  comments I have made are based on several years of  experience



with C under Unix,  CP/M, VMS etc.  One must come to grips with reality.  C



input-output,  while optional,  is normally what users must utilize to deal



with  a problem at hand;  consequently,  inexperienced users must lean more



heavily on the standard library than experienced users.   It is  meaningful



to  discuss  C input-output.   It does exist,  and  Mr.  Evenden  discusses



several  points about it before stating that the topic is beyond the  realm



of discussion.   Inexperienced users learn by reading dialog between others



who  have  seen problems in their own work.  Censoring this information  to



"protect"  such  users  from  disenchantment  with  C  is  an  unacceptable



alternative.

    We have not reached the computer millenium.  C and Unix as existing



tools  have  flaws  and drawbacks.   Only through discussion  can  we  seek



solutions,  and  create  better future systems.   The idea  of  restricting



discussions  based  on semantic points seems to be contrary to  that  goal.



Some  other writers have taken the approach that C and Unix are 'wonderful'



tools and heap praise on them in review after review.   A certain group  of



individual  feel highly insulted if this approach is not followed.   In  an



evolving  field,  it  makes  sense  to criticize as part  of  the  learning



process. That is why I include Mr. Evenden's final remarks, because I think



that  he  has drawn a counterproductive conclusion from  an  understandable



point of view:

    "C  is  not  a perfect language but it certainly  beats  what's  in

second  place.    Consequently,   my  enthusiasm  about  C  makes  me  very

chauvinistic  about misplaced and invalid criticisms.   I have a couple  of

minor complaints about some aspects of C but I bite my tongue when I  think

about  the dark ages.   After several happy years with Algol in the 60's  I

was  sentenced to over 10 long years of FORTRAN purgatory before being born

again  with  C.   I  guard this language jealously and you  had  better  be

careful  of what you write or I'll curse you to a task of debugging  10,000

lines of BASIC code."

    I  hope that Mr.  Evenden will reconsider and send in his  comments



about C so we can add them to the discussion.

                          BDS C Runtime solution

    Alex  Cameron of Malvern,  (Victoria,) Australia had the  following



comments:

    "I  couldn't  help  responding to your notes  on  the  non-standard

nature of some of BDS C's runtime routines (Dr.  Dobb's No.  90).  There is

probably  little  doubt that most of us gladly  suffer  its  irregularities

because  of  its  speed,  low price and because it is arguably one  of  the

finest C compilers around - all this notwithstanding I still find the  non-

standard  buffered  file  functions,  such as fopen the  most  frustrating,

simply because of the need to continually declare buffers."

    Listing I.  (stdlib3.c) is Mr.  Cameron's proposed solution to this



problem under BDS C.

.pa

                     ---------- LISTING I. ----------

/*
** stdlib3.c -- standard I/O library
**
** Copyright 1984  A. Cameron
*/
#include "bdscio.h"
/*
**
**    Standard fopen
**
**         return fd on success, NULL on error

**
*/

sfopen(filename,mode)
char *filename;
char *mode;
{
    int fd;

    if (*mode == 'w')    /* write mode */
    {
        if (!(fd = alloc(BUFSIZ)))
            return(NULL);
        else
        {
            if (fcreat(filename,fd) == -1)
            {
                free(fd);
                return(NULL);
            }

            return(fd);
        }

    }

    if (*mode == 'r')    /* read mode */
    {
        if (!(fd = alloc(BUFSIZ)))
            return(NULL);
        else
        {
            if (fopen(filename,fd) == -1)
            {
                free(fd);
                return(NULL);
            }


            return(fd);
        }
    }

    if (*mode == 'a')    /* append mode */
    {
        if (!(fd = alloc(BUFSIZ)))
            return(NULL);
        else
        {
            if (fappend(filename,fd) == -1)
            {
                free(fd);
                return(NULL);
            }

            return(fd);

    }

    return(NULL);    /* failure */

}

/*
**
**    Standard fclose
**
*/

sfclose(fd)
int fd;
{
    fputc(CPMEOF,fd);

    if (!(fclose(fd)))
    {
        free(fd);
        return(NULL);
    }

    return(ERROR);
}

                   ---------- END LISTING I. ----------
.pa


                            Unix Comments

    Two users had responses to previous comments about Unix. Tim Prince



of Marblehead, MA writes:

    "As  a  new UNIX user I find some of the subjects  raised  in  your

column  this  month [April] interesting.   Certainly,  in  comparison  with

VAX/VMS, there is a lack of discipline in adhering to uniform standards for

a  user  interface.   This is the almost inevitable result of the way  UNIX

evolved  as  the product of the work of various  organizations.   Also  the

volume  of official documentation is much less,  but if you count the  many

good  books available from third parties,  the comparison will soon go  the

other  way...Unix has collected a set of useful information into a pair  of

volumes which the individual can afford to own."

    He adds:  "I have spent nearly 20 years learning things about GCOS,

which  has  all  the faults of which UNIX is accused without  many  of  the

advantages.  This operating system will soon disappear from the face of the

earth,  making our knowledge of its quirks so much non-biodegradable mental

trash.   What  is learned about UNIX is more likely to remain useful  after

the current hardware is gone."

    Mike Meyers writes:

    "...I tend to agree with most of the things you've said about Unix.

The documentation is, at best, terse.  What's worse, it's either missing or

wrong  in many places.   To top it off,  most of it assumes that  you  have

access to the source,  and are a good computer scientist.   To make matters

still worse,  there really isn't an on-line documentation system.  What you

have is an interactive manual printer.   It is very definitely not friendly

to the naive user.   The best description I have run across is that Unix is

expert-friendly.   If  you know it,  it's going to be great.   If you don't

know it, well, that's just too bad."

    These  two viewpoints are not mutually exclusive;  Unix is  expert-



friendly and beginner-hostile;  many of the Unix systems such as 'man'  and



'mail' are primitive, but this bothers some users less than others.




                                Conclusion

    This column exists for the purpose of discussing C and Unix as they



exist with the problems they have.   As stated emphatically above,  C and C



input-output  are independent concepts.  However,  it is  the  input-output



library  that users generally deal with,  and deviations from it which they



complain about.   Therefore,  such a discussion has a place here.  I invite



Mr.  Evenden and other readers to submit any code which illustrates how  to



deal  with raw input-output in C under CP/M,  Unix or under other operating



systems.

    In this column,  we have considered some user comments about C/Unix



based on several letters received recently.   I would be interested to hear



what  others  think about this ongoing discussion,  as well  as  follow  up



comments from those readers represented here.