The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: lm@mcvoy.com (Larry McVoy)
Subject: [TUHS] C declarations.
Date: Sun, 14 May 2017 17:40:19 -0700	[thread overview]
Message-ID: <20170515004019.GJ29107@mcvoy.com> (raw)
In-Reply-To: <CAEoi9W5RQxi+atsMaOWhNBFo=jahYH-HeHJh_QqHCh5FHxXZfw@mail.gmail.com>

On Sun, May 14, 2017 at 08:14:47PM -0400, Dan Cross wrote:
> The kludge is that it works different than everything else for no really
> good reason.

I'd be curious what Steve thinks about all this, I know he weighed in 
a bit, but does he think that Dennis / Brian/ Ken regret this design choice?

Personally, I can easily see why they did it.  C doesn't really have a lot
of behind-the-scenes magic, it can easily be viewed as a pleasant way to
do portable code that sits directly on the hardware, no frameworks, no
garbage collector, no magic.  It's predictable in ways that higher level
languages are not.  That's one of the things I like about C, I can reason
about it.

But I suspect it was more basic than that.  They were running on 16 bit 
pretty slow machines and having a pass by value model for arrays just
didn't make any sense.  *Everyone* would pass by reference so why bother
having a pass by value model?  If you really, really wanted that you 
could get it

    int salaries[100];
    int payroll = add_them_up(malloc_and_copy(salaries, sizeof(salaries));

But any sane person in that day and age would go "why on God's green earth
would you do that?  It's slow.  Just don't change the salaries array and
you'll be fine".

Think about all the str* stuff - you really want to malloc and free that?
It would have killed performance.

Personally I think they looked at it, said "everyone will use references
for arrays anyway, let's make them references by default".

I get that it is not clean and pure and doesn't match how other types work,
I do see that, but I also see that their choice made a ton of sense at the
time.  And maybe still does.  It's not the same as the other types because
the other types are, typically, small.  Arrays can be big, really big.

--lm


  parent reply	other threads:[~2017-05-15  0:40 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 21:49 Ron Natalie
2017-05-11 22:01 ` Arthur Krewat
2017-05-11 23:44   ` Dave Horsfall
2017-05-11 22:03 ` David Arnold
2017-05-11 22:32   ` Larry McVoy
2017-05-11 22:41     ` Ron Natalie
2017-05-13  1:24       ` Larry McVoy
2017-05-13  2:45         ` Ron Natalie
2017-05-13 12:20           ` Michael Kjörling
2017-05-13 12:35             ` Tim Bradshaw
2017-05-13 12:42               ` Michael Kjörling
2017-05-13 15:36                 ` Stephen Kitt
2017-05-14  1:59                 ` Lawrence Stewart
2017-05-14  2:23                   ` Dave Horsfall
2017-05-14  4:24                   ` Bakul Shah
2017-05-14  6:12                     ` Steve Johnson
2017-05-14  6:48                       ` Bakul Shah
2017-05-14 23:06                         ` Ron Natalie
2017-05-14 23:34                           ` Arthur Krewat
2017-05-15  0:14                             ` Dan Cross
2017-05-15  0:23                               ` Ron Natalie
2017-05-15  3:43                                 ` Random832
2017-05-15  0:40                               ` Larry McVoy [this message]
2017-05-15  2:00                                 ` Nevin Liber
2017-05-15 10:21                                 ` Tony Finch
2017-05-15  4:35                     ` Dave Horsfall
2017-05-15  4:54                       ` Bakul Shah
2017-05-15  5:01                         ` Dave Horsfall
2017-05-15 12:58                       ` Michael Kjörling
2017-05-15 16:58                         ` Dave Horsfall
2017-05-15 19:00                           ` [TUHS] cdecl (Re: " Bakul Shah
2017-05-15 22:52                             ` Dave Horsfall
2017-05-13 13:46               ` [TUHS] " Hellwig Geisse
2017-05-13 19:08               ` Random832
2017-05-13 23:21                 ` Dave Horsfall
2017-05-14 14:48                   ` Nemo
2017-05-13 19:05             ` Random832
2017-05-14 13:14               ` Derek Fawcus
2017-05-12  0:15     ` Bakul Shah
2017-05-12  2:41       ` Theo Pavlidis
2017-05-12 14:04 Richard Tobin
2017-05-13 23:11 Richard Tobin
2017-05-15  6:46 ` Tim Bradshaw
2017-05-14 14:11 Doug McIlroy
2017-05-14 14:58 ` Steve Nickolas
2017-05-15 18:47 Steve Johnson
2017-05-15 19:54 ` Bakul Shah
2017-05-16  7:25 ` George Ross

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=20170515004019.GJ29107@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).