The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] What sparked lint? [Was: Unix stories]
Date: Wed, 4 Jan 2017 17:39:13 -0800	[thread overview]
Message-ID: <20170105013907.GE6931@mcvoy.com> (raw)
In-Reply-To: <CAJfiPzz-HegJOtjo524tusOhsu5LP2MTVGWBBM=nZbhHgpOB-g@mail.gmail.com>

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.


  reply	other threads:[~2017-01-05  1:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-05  1:30 Nemo
2017-01-05  1:39 ` Larry McVoy [this message]
2017-01-05  3:20 ` Steve Johnson
2017-01-05 17:46   ` Ron Natalie
2017-01-05 20:55     ` Mary Ann Horton
2017-01-05 21:06       ` Clem Cole
2017-01-05 21:17       ` Chet Ramey
2017-01-05 21:30         ` Clem Cole
2017-01-05 21:42           ` ron minnich
2017-01-05 21:51             ` Ron Natalie
2017-01-05 22:02             ` Chet Ramey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170105013907.GE6931@mcvoy.com \
    --to=lm@mcvoy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).