From mboxrd@z Thu Jan 1 00:00:00 1970 From: lm@mcvoy.com (Larry McVoy) Date: Sun, 14 May 2017 17:40:19 -0700 Subject: [TUHS] C declarations. In-Reply-To: References: <6D3DCC45-B2C6-4374-83EE-F745C0AF7F36@bitblocks.com> <030d01d2cd06$c44e2840$4cea78c0$@ronnatalie.com> <013240e6-cc66-12c7-325d-a1edf4107726@kilonet.net> Message-ID: <20170515004019.GJ29107@mcvoy.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