🚀 go-pugleaf

Barry Shein writes:
[READ and WRITE in Pascal]
>[...] are not "system routines" in any useful sense of the word, they
>are built-ins specifically recognized (and handled) by the compiler.
>The fact that Pascal admits that such constructs are necessary yet
>does not allow any equivalent way for a programmer to write such code
>has always been damning in my mind (that is, you CANNOT provide read()
>or write() as your own pascal subroutines (not because of the names,
>call them myread() and mywrite() if you like.)

Well, they aren't admitted as necessary (in the orginal report).  They are
provided strictly as conveniences.  And in a teaching language environment
people don't write such routines often; when they do they should be forced
to do so in a disciplined manner.

>The C equivalent is a language feature available to the programmer,
>routines like printf() can and are written in C.

The varargs facility is a feature.  The implicit use of variable length
lists is a sloppiness (perhaps deliberate) which is exploited all over the
place.  Kernighan and Ritchie admit themselves that the original state of
affairs has gross defects.

> Perhaps [always running lint] should be an
>extension or option to CC commands but it's easy enough to implement
>on your own system with a shell script or by modifying the CC command
>(this is not equivalent to adding some major language feature or
>anything, you could "add" it by simply running lint by hand all the
>time, I am just suggesting that automating that and hiding it under
>the CC command would be trivial.)

You still haven't explained why lint as a processor should be logically and
functionally distinct from cc as a processor.  The ONLY reason I can see for
separating them is so that you don't have to be confronted with messages
telling you that you're writng tricky or otherwise dubious code.

>>Pascal, of course, takes a very extreme viewpoint on this.  Considering its
>>teaching language heritage, I find it hard to attack the decision that was
>>made.  Students need to learn to write diciplined programs before they go
>>out and break all the rules, and thus there's advantage to be had in making
>>those sort of restrictions syntactic requirements.

>I find this a weak justification. Students should learn to use things
>like lint etc.

No.  Students shouldn't HAVE to learn to use things like lint, in my
opinion, because they shouldn't have the option of NOT running things like
lint.

> You first posit that using variable argument lists is
>the definition of undisciplined and then proceed to use this axiom.

No.  What I insist upon is that variable length argument lists should be a
feature which is explicitly invoked, rather than the deliberate exploitation
of a sloppy point in the language, which is what C has now.

>I don't agree with the axiom. If a student can't remember to "line up"
>his/her arguments to routines then I have little hope for the student
>(yes, I do teach programming and have for several years, I think this
>kind of thinking has done more harm than good to students allowing
>instructors of mediocre quality [or intent] to evade giving the students
>what they really need, a decent working mental model of computation.)

Oh, come now.  Do you REALLY never ever make a careless mistake and forget
one of the arguments to a routine?  And why should this mistake be
syntactically equivalent to deliberately variable length argument lists?  It
seems to me that there's every advantage in the world to having the computer
catch stupid and careless errors wherever possible; I utterly fail to see
the advantage in deliberately maintaining a syntactic confusion between
mistakes and a "feature", especially when making the latter explicit makes
it vastly more obvious what the code really does.

CGW

In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes:
>Barry Shein writes:
>>Perhaps [always running lint] should be an extension or option to
>>CC commands ...

>You still haven't explained why lint as a processor should be logically and
>functionally distinct from cc as a processor.

What is this, a flame war?  Charley, I know you are capable of
thinking of this one yourself.  How about the *time* it takes to
run lint?  Remember, you are not compiling on a top-of-the-line
Amdahl, but a poor little PDP-11 shared by sixteen other users.
It takes 15 minutes to recompile your program after a one line
change in a header file.  A full lint-style check would extend that
to 30 minutes.

(Yes, this argument breaks down rapidly when you are running on a
top-of-the-line Amdahl . . . unless you pay for CPU time.  The
point is that this is a historic artifact, yet still, I think,
useful---in the right hands.)

>The ONLY reason I can see for separating them is so that you don't
>have to be confronted with messages telling you that you're writng
>tricky or otherwise dubious code.

No, separating them gives YOU the *option* of deciding whether to
expend computer time checking for tricky or otherwise dubious code.
I work on a poor little Vax 11/750 much of the time, and I run
lint, but sparingly.  I have that choice, and often I am glad of
it.  (I *still* wish the compiler were faster, even after Donn
Seeley and I sped it up by 25%, and even though I ship compiles
over the Ethernet to the 8600.)

>Students shouldn't HAVE to learn to use things like lint, in my
>opinion, because they shouldn't have the option of NOT running
>things like lint.

This may well be true.  On the other hand, I wonder if these students
will have any idea what happens in `real world' FORTRAN programs
after they graduate.  It is a tradeoff:  Confuse them now, or
confuse them later?  (The proper time is `as soon as they can handle
it', which is quite difficult to determine---but at this university,
likely later than sooner.  [Note that a BS in CS is still considered
a Trade School diploma, at least by all the employers around here.
Some think this sorry state of affairs, but that is not a matter
to discuss in this newsgroup.  <Can I really head off flame wars
this way?>])

>Do you REALLY never ever make a careless mistake and forget one of
>the arguments to a routine?  And why should this mistake be syntactically
>equivalent to deliberately variable length argument lists?

I do, but lint catches them.  That is one of the reasons I use it.

(Not only that, but it has become natural for me to type

	/* VARARGS */
or	/* ARGSUSED */

in front of functions that have variable argument lists, or sometimes
do not use some arguments.  Others, watching me code, have mentioned
that I am just warped. :-)  I would not, though, object to a source
syntax for variable length argument lists, as opposed to this rather
odd commentary syntax.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu

In article <4900@mimsy.UUCP>, mangoe@mimsy.UUCP (Charley Wingate) writes:
> You still haven't explained why lint as a processor should be logically and
> functionally distinct from cc as a processor.  The ONLY reason I can see for
> separating them is so that you don't have to be confronted with messages
> telling you that you're writng tricky or otherwise dubious code.

Most of the things lint points out either aren't available to ccom, or
are definitely not appropriate.  How is ccom going to know what is in
the other files that I'm going to link with?  Detection of incompatible
arguments, return values, etc across modules is lint's most useful
function.  Also, so you really want ccom to tell you that you haven't
used some of the variables you declare?  Then there are things that are
technically portability problems, but are unavoidable -- for instance,
when I assign a long to an int, lint will complain about it, but if I
can't change the types of the variables and I know that the magnitude
of the long will be <= the magnitude of a short, I'll just put #ifndef
LINT around that statement and get rid of the warnings.  If ccom
complained about it I couldn't do that.

	Wayne

In article <4900@mimsy.UUCP>, mangoe@mimsy.UUCP (Charley Wingate) writes:
>...It
>seems to me that there's every advantage in the world to having the computer
>catch stupid and careless errors wherever possible; I utterly fail to see
>the advantage in deliberately maintaining a syntactic confusion between
>mistakes and a "feature", especially when making the latter explicit makes
>it vastly more obvious what the code really does.
> 
> CGW

I largely agree with this however consider that C has about 46
operators and 15 precedence levels.  This complexity can lead to
subtle bugs.  The reason these 'bugs' slip by cc are that they are
allowed in the language and *can be intentional*.  The worse compiler
is one that complains about something that isn't wrong.  Perhaps lint
will be changed - I'm trying to get it changed but until then you'll
have to write a separate program to find them (I already have).  Sorry,
I can't give you a copy or tell you much more about it.  If I get
something published on it, I'll talk some more about it.
-- 

Larry Cipriani	AT&T Network Systems
cbosgd!{danews,cbsck}!lvc

In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes:

>You still haven't explained why lint as a processor should be logically and
>functionally distinct from cc as a processor.  The ONLY reason I can see for
>separating them is so that you don't have to be confronted with messages
>telling you that you're writng tricky or otherwise dubious code.

I dont want to get into a "to lint or not to lint" fight here, but i 
do think that there are very good reasons to keep lint separate from cc :

In a large system, lint looks at everything, and in "edit-run-think-debug..."
loops, the overhead of lint is unnecessary and unhelpful. (I change a
loop from "for (i=0 ; i < 100 ; i++)" to "for (i=0 ; i < 101 ; i++)", and
need to re-lint the file.  Absurd.

I might be building something that produces C code as output, and linting
it will be expensive, and will require that i build in the annotations to
keep lint happy as i build the processor.  This will interfere with my
concentrating on the important structure of the program.

I (or the people i work for) might have a modified lint with strong 
stylistic guidelines, or... which should be run instead.

In general, i believe that it is a good idea to keep things which are
logically separate, separate.  Thus, i like having a c compiler which
keeps the preprocessor, the compiler, the assembler, .... all
distinct.  In this way i can change a processor that does that step
when i need to, omit steps (where that makes sense), or add additional
steps (like editing the assembler).  Most of the time, i do not do
this, but i have needed to in the past, and found difficulties with
compilers that would not let me get to intermediate stages.  (I needed
to get at the assembler output to do something once, and the only way
to do it was to use the flag that produced an assembler listing
(interleaved with the code, and the results of the assembly!), then
edit the listing to produce usable assembler - and that didnt even
assemble correctly without more work.)

Keep separate parts separate!  Wasnt this part of the "Unix(tm) Philosophy"?

-- 
               O                   -- jefu
       tell me all about           -- UUCP: steinmetz!putnam
Anna Livia! I want to hear all.... -- ARPA: putnam@GE-CRD

In article <4906@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes:
>> Barry Shein writes:
>>> Perhaps [always running lint] should be an extension or option to
>>> CC commands ...
>> You still haven't explained why lint as a processor should be
>> logically and functionally distinct from cc as a processor.
> How about the *time* it takes to run lint?
> [also]
> [S]eparating them gives YOU the *option* of deciding whether to
> expend computer time checking for tricky or otherwise dubious code.

Not to mention the fact that lint often yells about things it
shouldn't, and it is even occaisonally outright wrong.

For example, I seem to recall that there is some routine (read()?)
which has an argument that lint and lint -p disagree over the correct
type for.  Not good.

For another example, I refuse to uglify my code with (void) casts just
to make lint shut up about strcpy(), close(), fprintf(stderr,...), etc,
returning values that I don't use.  This is one thing lint *needs*: a
way to say "this routine returns a value, but it's OK to ignore it".

There also should be a way to shut off lint complaints about
nonportable code in just a small region that you know is
machine-specific (eg, stuff inside #ifdef machine-type).

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu

[Followups to comp.lang.c, unless other languages are discussed.]
In article <593@mcgill-vision.UUCP> mcgill-vision!mouse (der Mouse) writes:
>In article <4906@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
[Concerning whether lint should be an enforced part of cc]
>>Separating them gives YOU the *option* of deciding whether to
>>expend computer time checking for tricky or otherwise dubious code.
>
>Not to mention the fact that lint often yells about things it
>shouldn't, and it is even occaisonally outright wrong.

More precisely, lint feels free to complain about things that *might* be
wrong, on the grounds that it was explicitly invoked by the user to look for
such things.  If it were built into cc (and some parts of it should be, and
have been; e.g. "pointer == integer"), it would have to give the user the
benefit of the doubt.  (And there would still be a need for a separate program
to check for legal-but-questionable things.)

>For example, I seem to recall that there is some routine (read()?)
>which has an argument that lint and lint -p disagree over the correct
>type for.  Not good.

That's a job for the standards committee to resolve.

>For another example, I refuse to uglify my code with (void) casts just
>to make lint shut up about strcpy(), close(), fprintf(stderr,...), etc,
>returning values that I don't use.  This is one thing lint *needs*: a
>way to say "this routine returns a value, but it's OK to ignore it".

It's questionable whether it's okay to ignore the result from functions that
actually have an error return (though strcpy() is certainly safe).

>There also should be a way to shut off lint complaints about
>nonportable code in just a small region that you know is
>machine-specific (eg, stuff inside #ifdef machine-type).

I don't think I've ever needed that myself, but it's a reasonable request,
easily supported with a new lint-pragma.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

If anyone is looking for "extended" type checking in a C compiler and
has access to a PC, I suggest you try Microsoft's C compiler with the
options -W2 -DLINT_ARGS.

I think it does a thorough but not unreasonable job.