The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bakul@bitblocks.com (Bakul Shah)
Subject: [TUHS] C declarations.
Date: Sat, 13 May 2017 21:24:11 -0700	[thread overview]
Message-ID: <20170514042411.93CCB124AEA4@mail.bitblocks.com> (raw)
In-Reply-To: Your message of "Sat, 13 May 2017 21:59:57 EDT." <57639684-050B-4995-859F-876CAFE4BE9C@serissa.com>

On Sat, 13 May 2017 21:59:57 EDT Lawrence Stewart <stewart at serissa.com> wrote:
>
> * - But I have never been able to remember the syntax for function pointers.  > I always "man qsort" to refresh my memory.

The way I remember:

given *x[] or *x(), x /sticks/ to the /right/ first. Thus

int *x[];	// x is array of ptr to int
int *x();	// x is a function returning ptr to int

If you don't want a var to stick to its right, separate using
using parentheses.

int (*x)[];	// x is a ptr to array of ints
int (*x)();	// x is a ptr to function returning int
int *(*x)[];	// x is a ptr to array of ptrs to int

This sort of also works for multiple variables in one declaration. Given

int *x, y;	// * /sticks/ to the right (x) first, so not available for y.

Now if they'd allowed parenthesizing the type, as in

(int *)x, y;

we would see that both x & y are of type int *. That would've also allowed
declaring multiple vars in one declaration where the previous rule applies!

(int*)(*f,*g)();

Part of the confusion is * is tacked on at the front while []
& () at the back of a variable.  Someone (Chandy?) had
proposed unifying this syntax but it didn't go anywhere.  I
think the author used @ in a suffix place though I don't
recall any other details.  But if you put the var all the way
to the right and read a declaration right to left, it works:

int*[] x	// x is a array of ptr to ints
int() f		// f is a function returning it
int*()* f	// f is a ptr to function returning ptr to int
int*()* f,g	// f & g are ptrs to function returning ptr to int

This is only slightly weird if you are used to the current syntax
but you can easily retrain yourself.

IMHO, where evolution of C, Scheme and most programming
languages goes wrong is doing evolutionary design by
committee.  Most users grasp what is easier to use vs what is
hard but they don't have the aesthetic sense or imagination or
training to make things simple. And in large groups popularity
or force of personality or some other irrelevant attribute
wins not aesthetics.  Language evolution IMHO must be done by
benevolent dictatorship or a guild of like minded people who
have worked together for a long time!  Go seems to have
adapted that style....


  parent reply	other threads:[~2017-05-14  4:24 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 [this message]
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
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=20170514042411.93CCB124AEA4@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).