The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bakul@bitblocks.com (Bakul Shah)
Subject: [TUHS] C declarations.
Date: Thu, 11 May 2017 17:15:20 -0700	[thread overview]
Message-ID: <20170512001520.38000124AEA4@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Thu, 11 May 2017 15:32:32 PDT." <20170511223232.GM4341@mcvoy.com>

On Thu, 11 May 2017 15:32:32 PDT Larry McVoy <lm at mcvoy.com> wrote:
> 
> I dunno if it is one of its greatest joys but pointers in C have always 
> made sense to me.
> 
> I'm curious as to what is busted about arrays in C?  To me they just
> seemed like a way to define how to look at a wad of memory and they
> seem to work for me.  About the only thing I don't like about them is
> that there is no late binding as to the size, Ada has late binding and
> I thought it could be useful (I only know because Rob Netzer and I 
> wrote an Ada compiler for CS736 at UW-Madison that did a lot of Ada
> but exceptions and late binding we did not do).

Coming from a Pascal background I really liked the terseness
of C. But theere were three things that bothered me.

a) K&R style argument declarations. This got fixed in ANSI C.
   C declarations were messy but that did not bother me much.

b) No nested procedures. Gnu C had added them but the
   implementation was a bit screwy and most people didn't care
   in any case so there was no hope of this getting fixed.
   Partly because most people used it as a portable assembly
   language!

c) arrays were not first class objects.  Given "T v[N];" v[i]
   is of type T and i+v or v+i is of type T* -- this is
   perfectly well defined and fine. What is not fine is that
   an array is a second class object. Thus you can not do
   for example,

    int v[5];
    struct foo {
	int w[5];
	int x;
    } y;
	...
	y.w = v;

   You can not pass a whole array to a function (or return
   one) without enclosing it in a struct. You can not take an
   address of an array, only an element of it. There is no way
   to declare or pass a subarray. A function that operates on a
   arbitray sized  multi dim. array can be written but can get
   messy.

   One big impact of current array behavior is that the onus
   to do boundary condition checks is on the programmer and
   can't be done by the compiler.

Just as Pascal got "conformant arrays" in its 1990 standard,
arrays could've been made first class (but without "ref"
parameters code can look messy). For instance, consider the
folloowing:

    double a[5,20], b[20,10], c[5,10];
    int err = mat_multiply(c, a, b);

    int mat_mult(ref double c[int cx, cy], a[int ax, ay], b[int bx, by]) {
	if (cx != ax || cy != by || ay != bx) return -1;
	...
	return 0;
    }

This can be implemented without much trouble and allows
full boundary condition checking.  Currently the user will
have to manually pass {a,b,c}{x,y} parameters and he would
have to either create auxiliary vectors to point to each row
or have the function to do all the index arithmetic explicitly
(and the compiler can't check if your code has no boundary
condition bugs).

A slightly more difficult situation arises when you want to
pass sub arrays. For instance,

	mat_mutl(c[5,0:9], a[5,10:19], b[0:9,0:5])

Here you will have to somehow pass stride and offset (or use
iliffe vectors or some such).


  parent reply	other threads:[~2017-05-12  0:15 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
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 [this message]
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=20170512001520.38000124AEA4@mail.bitblocks.com \
    --to=bakul@bitblocks.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).