[TUHS] What sparked lint? [Was: Unix stories]

[TUHS] What sparked lint? [Was: Unix stories]

[Nemo]

On 4 January 2017 at 13:51, Steve Johnson <scj at yaccman.com> wrote (in part):
> These rules provided rich fodder for Lint, when it came along, [...]

All this lint talk caused me to reread your Lint article but no
history there.  Was there a specific incident that begat lint?

N.

[TUHS] What sparked lint? [Was: Unix stories]

[Larry McVoy]

On Wed, Jan 04, 2017 at 08:30:48PM -0500, Nemo wrote:
> On 4 January 2017 at 13:51, Steve Johnson <scj at yaccman.com> wrote (in part):
> > These rules provided rich fodder for Lint, when it came along, [...]
> 
> All this lint talk caused me to reread your Lint article but no
> history there.  Was there a specific incident that begat lint?

That would be cool to know.  Another thing I wish they had put in was
the ability to print the type (underlying type, not the typedef) names.

My first job was porting /usr/src/cmd to the ETA-10 which had bit pointers.
Yup, hardware pointers pointed at bits, not bytes.  The C compiler people
had to decide what to do if you took an int and cast it into a C pointer.
They choose to shift it from bit to byte.  So an int could countain an 
address but it countained a bit address.  Consider this code:

foo(size)
{
    char *p = (char*)malloc(size);      /* little white lie?  uh-uh. */
    ....
}

If there is no #include <malloc.h> then the compiler thought that malloc
returned an int. The conversion caused a 3 bit shift when it shouldn't.

I wacked lint to print out the type names and any time I saw a ptr/int
type mismatch I just #included all the header files like malloc.h et al.

Turned a 6 month job into a 2 week job.

I believe at some point System V made the same changes.  I'm sort of sure
that I sent my diffs to Dennis, not positive.  They may have come up with
the same idea on their own.

Lint is a great tool.

[TUHS] What sparked lint? [Was: Unix stories]

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5002 bytes --]

OK, more history...

In 1973, I spent a 9 month Sabbatical at the University of Waterloo in
Canada.  When I left, B was the dominant language on Unix -- when I
came back, C had taken over.  I had made a B compiler for the
Honeywell mainframe, as much to test out Yacc as anything.  When I
came back,  an Intern from MIT, Al Snyder, had rewritten my B
compilers into C compilers.  He left, and I took back his code. 
Dennis' compiler was still the touchstone on Unix, but Al's was
working on the Honeywell and there was a lot of interest in making one
for OS 360 and also for an internal switching machine.   Al's
compiler for the Honeywell still had a fair number of bugs, mostly in
the code generation phase (the code to decide what to do when the
compiler ran out of registers went from one page to two pages to four
pages and there were still bugs).  

Also, about this time I had a fateful discussion with Dennis, in which
he said "I think it may be easier to port Unix to a new piece of
hardware than to port a complex application from Unix to a new OS"
(Most OS's in those days were unique to their hardware, and written in
assembler).  Clearly, such a plan required a portable compiler and I
agreed to take a stab at it...    I started with the existing
compilers and began editing them to make the similar code in the
various compilers identical.  I started with the front end--the
back-end work seemed to be (and was) rather harder.   The grammar
and lexer were fairly easy to clean up, but I really didn't have a
good way to test them...  And the type system was new and evolving.

At that time, C was still fairly close to B.  For example, there were
no function prototypes, so a common source of bugs was to change a
function but miss some of the invocations, leading, usually, to
crashes.  There were also no header files -- the system structures
were printed in the manual (!).   And, 32-bit machines were
beginning to come along and looked attractive.   I realized that I
could kill several birds with one stone by using my nascent front end
to parse C programs and then print out a line for every function call
and definition with the function name, location, and argument types. 
A bit of Unix magic took these lines and sorted them, and a small
program then read the combined file and complained when a function was
called or defined inconsistently.  And, as a side effect, I found and
fixed a number of front-end bugs.

We decided to purchase an Interdata 8/32, a 32-bit machine with an
instruction set that looked like a cleaned-up IBM 360, and all of a
sudden portability became much more important.  We had to do
something about about all those structure definitions printed in the
manual.  Over the summer, the concept of header files was developed,
and Lint at one point required that system calls had to use the
structure definitions in these header files -- a copy from the manual
was no longer acceptable.  Also, as the compiler developed, we added
additional portability messages and some useful things like flagging
expressions that didn't do anything and statements that could not be
reached.

Lint continued for a long time to share the front end of the portable
C compiler.

I should mention that I was not the first person to write a program to
criticize other programs.  Barbara Ryder at the Labs had written, in
FORTRAN, program called PFORT that would look at FORTRAN programs and
flag constructions that would not work on the 6 major FORTRAN
compilers in use at the time.  There were a surprising number of
differences between these languages, and we were able to write a
symbolic algebra system in FORTRAN that ran on all these systems
largely because of the effectiveness of PFORT.

Finally, the name...  At the time Lint first appeared, I had two
young children at home.  This was in the era of cloth diapers, and we
were doing a LOT of wash.  One day, as I was cleaning out the lint
trap in our dryer, I realized that the program I was writing was
performing a similar function, and the name was born.  Since then, I
have written a number of Lint-like programs -- I'm proudest of the one
I did when working for the MathWorks.  It was integrated into the
MATLAB editor, and could give nearly instant feedback when you typed
in faulty code.

----- Original Message -----
From: "Nemo" <cym224@gmail.com>
To:"Steve Johnson" <scj at yaccman.com>
Cc:"TUHS main list" <tuhs at minnie.tuhs.org>
Sent:Wed, 4 Jan 2017 20:30:48 -0500
Subject:What sparked lint? [Was: Unix stories]

 On 4 January 2017 at 13:51, Steve Johnson <scj at yaccman.com> wrote (in
part):
 > These rules provided rich fodder for Lint, when it came along,
[...]

 All this lint talk caused me to reread your Lint article but no
 history there. Was there a specific incident that begat lint?

 N.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170104/3d48fb3c/attachment.html>

[TUHS] What sparked lint? [Was: Unix stories]

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1574 bytes --]

I remember being at an early UUG meeting and the group who did the UNIX port to the IBM series lamenting that it printed NUXI on boot because of byte order issues.    Don’t know if it was true, but NUXI became a synonym for UNIX byte order issues from then on.

 

 

The 8/32 indeed has some 370-ish stuff starting from the fact that it numbers the bits from the MSB end.   Amusingly, it has more minicomputerish other features.

One bizarre source of fun is that where as accessing a 16 bit quantity on an odd address on the PDP-11 gives you a bus error trap, the Interdata just ignores the low order bit and returns you the 16 bit value that you are pointing into the middle of.   Same things happen on 32-bit access (lower 2 bits ignored).    

For nostalgia, here’s a scan of an old 8/32 programmers manual:  http://bitsavers.trailing-edge.com/pdf/interdata/32bit/8-32/29-428_8-32_User_May78.pdf

 

Byte ordering got worked out when networking came in.     I worked on IBM’s AIX which was a productization of the UCLA LOCUS kernel.   The thing was a relatively tightly coupled multiprocessor system that allowed seamless execution of different binary types.    The machines we were working with were the 370 mainframe, the i386 (in the form of IBM PS/2’s), and a four processor i860 add in card IBM built called the W4.    The mainframe having the opposite byte ordering of the others.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/d85c0c07/attachment.html>

[TUHS] What sparked lint? [Was: Unix stories]

[Mary Ann Horton]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1887 bytes --]

I recall at the Delaware Usenix conference (in 1979?) a professor from 
Case Western gave a talk about his port of UNIX to some Interdata or 
Data General or something.  He said that when he booted it up, it said 
"NUXI".


On 01/05/2017 09:46 AM, Ron Natalie wrote:
>
> I remember being at an early UUG meeting and the group who did the 
> UNIX port to the IBM series lamenting that it printed NUXI on boot 
> because of byte order issues.    Don’t know if it was true, but NUXI 
> became a synonym for UNIX byte order issues from then on.
>
> The 8/32 indeed has some 370-ish stuff starting from the fact that it 
> numbers the bits from the MSB end.   Amusingly, it has more 
> minicomputerish other features.
>
> One bizarre source of fun is that where as accessing a 16 bit quantity 
> on an odd address on the PDP-11 gives you a bus error trap, the 
> Interdata just ignores the low order bit and returns you the 16 bit 
> value that you are pointing into the middle of.   Same things happen 
> on 32-bit access (lower 2 bits ignored).
>
> For nostalgia, here’s a scan of an old 8/32 programmers manual: 
> http://bitsavers.trailing-edge.com/pdf/interdata/32bit/8-32/29-428_8-32_User_May78.pdf
>
> Byte ordering got worked out when networking came in.     I worked on 
> IBM’s AIX which was a productization of the UCLA LOCUS kernel.   The 
> thing was a relatively tightly coupled multiprocessor system that 
> allowed seamless execution of different binary types.    The machines 
> we were working with were the 370 mainframe, the i386 (in the form of 
> IBM PS/2’s), and a four processor i860 add in card IBM built called 
> the W4.    The mainframe having the opposite byte ordering of the others.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/dda1ea79/attachment.html>

[TUHS] What sparked lint? [Was: Unix stories]

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]

He is right, it was the IBM Series/1 Port and it was a different school
(Miami of Ohio, I think).

Case was Bill Shannon and Sam Leffler's port to an Interdata.

On Thu, Jan 5, 2017 at 3:55 PM, Mary Ann Horton <mah at mhorton.net> wrote:

> I recall at the Delaware Usenix conference (in 1979?) a professor from
> Case Western gave a talk about his port of UNIX to some Interdata or Data
> General or something.  He said that when he booted it up, it said "NUXI".
>
> On 01/05/2017 09:46 AM, Ron Natalie wrote:
>
> I remember being at an early UUG meeting and the group who did the UNIX
> port to the IBM series lamenting that it printed NUXI on boot because of
> byte order issues.    Don’t know if it was true, but NUXI became a synonym
> for UNIX byte order issues from then on.
>
>
>
>
>
> The 8/32 indeed has some 370-ish stuff starting from the fact that it
> numbers the bits from the MSB end.   Amusingly, it has more minicomputerish
> other features.
>
> One bizarre source of fun is that where as accessing a 16 bit quantity on
> an odd address on the PDP-11 gives you a bus error trap, the Interdata just
> ignores the low order bit and returns you the 16 bit value that you are
> pointing into the middle of.   Same things happen on 32-bit access (lower 2
> bits ignored).
>
> For nostalgia, here’s a scan of an old 8/32 programmers manual:
> http://bitsavers.trailing-edge.com/pdf/interdata/32bit/8-32/
> 29-428_8-32_User_May78.pdf
>
>
>
> Byte ordering got worked out when networking came in.     I worked on
> IBM’s AIX which was a productization of the UCLA LOCUS kernel.   The thing
> was a relatively tightly coupled multiprocessor system that allowed
> seamless execution of different binary types.    The machines we were
> working with were the 370 mainframe, the i386 (in the form of IBM PS/2’s),
> and a four processor i860 add in card IBM built called the W4.    The
> mainframe having the opposite byte ordering of the others.
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/ee9074a8/attachment-0001.html>

[TUHS] What sparked lint? [Was: Unix stories]

[Chet Ramey]

On 1/5/17 3:55 PM, Mary Ann Horton wrote:
> I recall at the Delaware Usenix conference (in 1979?) a professor from Case
> Western gave a talk about his port of UNIX to some Interdata or Data
> General or something.  He said that when he booted it up, it said "NUXI".

That might have been Sam Leffler and Bill Shannon's port of 7th Edition
to the Harris/6.  Somewhere I have both their MS theses describing it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] What sparked lint? [Was: Unix stories]

[Clem Cole]

I stand corrected -- I think you are right, Sam and Bill had a Harris
system not Interdata.

On Thu, Jan 5, 2017 at 4:17 PM, Chet Ramey <chet.ramey at case.edu> wrote:

> On 1/5/17 3:55 PM, Mary Ann Horton wrote:
> > I recall at the Delaware Usenix conference (in 1979?) a professor from
> Case
> > Western gave a talk about his port of UNIX to some Interdata or Data
> > General or something.  He said that when he booted it up, it said "NUXI".
>
> That might have been Sam Leffler and Bill Shannon's port of 7th Edition
> to the Harris/6.  Somewhere I have both their MS theses describing it.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~
> chet/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/7f3c4730/attachment.html>

[TUHS] What sparked lint? [Was: Unix stories]

[ron minnich]

the udel usenix was 1980. I was support staff :-)

On Thu, Jan 5, 2017 at 1:31 PM Clem Cole <clemc at ccc.com> wrote:

> I stand corrected -- I think you are right, Sam and Bill had a Harris
> system not Interdata.
>
> On Thu, Jan 5, 2017 at 4:17 PM, Chet Ramey <chet.ramey at case.edu> wrote:
>
> On 1/5/17 3:55 PM, Mary Ann Horton wrote:
> > I recall at the Delaware Usenix conference (in 1979?) a professor from
> Case
> > Western gave a talk about his port of UNIX to some Interdata or Data
> > General or something.  He said that when he booted it up, it said "NUXI".
>
> That might have been Sam Leffler and Bill Shannon's port of 7th Edition
> to the Harris/6.  Somewhere I have both their MS theses describing it.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU    chet at case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/1270d607/attachment.html>

[TUHS] What sparked lint? [Was: Unix stories]

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Indeed.    I went to Toronto in 1979 (I remember my boss paying me while I was gone) and was working at BRL in 1980 when we went to UDel.

I remember working the AV for Mike Muuss as he was giving is BRL CAD presentation.    He started off with “The Ballistic Research Laboratory is the Army’s Lead in Vulnerability and Lethality Analysis” which got a hot of hisses.    Years later I was having dinner with Mark Krieger, then president of Unipress software, and looking at him and saying “Didn’t you get booed off the stage at the UDel UUG?”   I couldn’t remember the circumstances until he then told me that he was half of Whitesmith’s at the time (and talking about their Idris commercial product and the UUG had a definite non-commercial bent at the time).    I told him I was always kind of amused by the Whitesmith’s C Compiler license stamp that they sent you to stick to your VAX.   Like the Whitesmith’s police were going to raid your facility to make sure you had it.    He said he had left Whitesmiths by then, but the stickers let him know that Plauger had really gone off the deep end.

 

A few months later I found that someone had actually stuck the stamp on a machine at the Rutgers-Newark campus.    I carefully peeled it off and gave it to Mark.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/6eae3454/attachment.html>

[TUHS] What sparked lint? [Was: Unix stories]

[Chet Ramey]

On 1/5/17 4:42 PM, ron minnich wrote:
> the udel usenix was 1980. I was support staff :-)

I think Bill's talk was at Boulder.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/