The C Users' Group Library 1994 August/wc-cdrom-cusersgrouplibrary-1994-08.iso/vol_100/137_01/aug84col.ddj

Text File | 1979-12-31 | 17KB | 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.