Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73070 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-10-16 13:29 -0700 |
| Last post | 2015-10-16 20:45 -0700 |
| Articles | 20 on this page of 168 — 20 participants |
Back to article view | Back to comp.lang.c
C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 13:29 -0700
Re: C struct syntax allowance by usage Siri Cruz <chine.bleu@yahoo.com> - 2015-10-16 13:47 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 14:12 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-16 22:15 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 10:32 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 05:26 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 14:17 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 06:48 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 19:01 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 11:17 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 15:28 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 01:41 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 18:23 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:04 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 10:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:14 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:25 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 12:32 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:35 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 11:16 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:40 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 17:35 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 10:52 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 11:02 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 19:59 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 12:15 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 21:41 +0100
Likeliehood of RDC/SeaAlive implementation (Was: C struct syntax allowance by usage) gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-19 08:23 +0000
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:02 -0400
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:19 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 21:13 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 20:37 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:27 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 23:14 +0200
Re: C struct syntax allowance by usage asetofsymbols@gmail.com - 2015-10-18 15:09 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 16:11 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 07:57 +1300
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:11 +0100
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 09:19 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:19 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 03:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:52 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 05:39 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 14:57 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 10:31 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 15:49 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:53 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 01:50 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 02:28 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 12:38 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 12:09 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:26 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 13:34 +0100
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:36 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 05:09 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:41 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 06:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 15:20 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 08:24 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 08:43 +1300
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 13:00 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-19 20:34 +0000
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 09:47 +1300
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-19 16:32 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 10:37 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 21:24 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 13:49 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-20 07:33 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:53 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:37 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:05 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 02:02 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 06:07 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 14:15 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 09:23 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 18:30 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 12:13 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 21:17 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 14:21 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-21 14:55 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:45 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:33 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 08:54 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-23 15:59 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:03 -0700
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:37 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 23:26 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:56 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:19 +0000
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 11:08 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:58 +0200
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:06 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 07:41 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 14:00 +0100
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 21:00 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 14:57 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 14:41 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 13:01 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 13:25 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 07:44 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:41 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:22 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-22 01:01 -0700
Re: C struct syntax allowance by usage Les Cargill <lcargill99@comcast.com> - 2015-10-22 08:00 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:49 -0400
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:40 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-20 11:55 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:11 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:47 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:32 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 10:08 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 21:45 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:09 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:22 -0400
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 17:49 -0700
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 21:13 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:36 +0000
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-22 20:18 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:55 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:14 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 09:09 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:31 +0000
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:17 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-11-10 10:39 -0800
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 11:02 -0800
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 15:54 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 13:51 -0700
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 17:41 -0400
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:32 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:17 -0700
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 16:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:51 +0000
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:01 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 12:38 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-24 13:56 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 15:17 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-25 13:47 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 23:46 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 07:05 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-25 10:59 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:24 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-25 11:13 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:58 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-24 11:02 -0700
Re: C struct syntax allowance by usage Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-10-24 20:13 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-24 12:45 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-24 10:30 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 12:05 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:57 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 00:54 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 17:19 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:33 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 19:41 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:58 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:10 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 16:49 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:59 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:32 +0200
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-16 23:15 -0400
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:34 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:45 -0700
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-19 06:08 -0700 |
| Message-ID | <c139fda1-8bfb-42bc-8e67-31b7af3d115e@googlegroups.com> |
| In reply to | #73283 |
On Monday, October 19, 2015 at 1:42:04 PM UTC+1, David Brown wrote: > > I don't understand what you mean by saying "shell scripting insists that > subroutines be in named separate files" - that's not my experience of > shell scripting. > You make a shell subroutine by creating a file consisting of shell commands, or a binary executable. It's then available from the shell as a new command, or a subroutine. I'm sure that there are some shells that relax that. Busybox comes to mind. But a file per subroutine is the the shell "way".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-19 15:20 +0200 |
| Message-ID | <n02qip$vpi$1@dont-email.me> |
| In reply to | #73289 |
On 19/10/15 15:08, Malcolm McLean wrote: > On Monday, October 19, 2015 at 1:42:04 PM UTC+1, David Brown wrote: >> >> I don't understand what you mean by saying "shell scripting insists that >> subroutines be in named separate files" - that's not my experience of >> shell scripting. >> > You make a shell subroutine by creating a file consisting of shell commands, > or a binary executable. > It's then available from the shell as a new command, or a subroutine. > > I'm sure that there are some shells that relax that. Busybox comes to mind. > But a file per subroutine is the the shell "way". > That is not how you make a shell subroutine - that is how you make a new shell script. And yes, one shell script can call another one - doing so instead of using subroutines or functions can sometimes be convenient, but is quite inefficient if you are doing it a lot. I can't think of any shell that doesn't support functions or subroutines - at least, not any reasonably current ones. Anything posix compliant, including bash, dash, and busybox, certainly supports them. Shell subroutines are extremely common in practice (just look at a few scripts on any *nix system - it should not take you long to find examples). Perhaps you are thinking of DOS batch files (before NT introduced "call").
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-19 08:24 -0700 |
| Message-ID | <lntwpmzxso.fsf@kst-u.example.com> |
| In reply to | #73289 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Monday, October 19, 2015 at 1:42:04 PM UTC+1, David Brown wrote:
>> I don't understand what you mean by saying "shell scripting insists that
>> subroutines be in named separate files" - that's not my experience of
>> shell scripting.
>>
> You make a shell subroutine by creating a file consisting of shell commands,
> or a binary executable.
> It's then available from the shell as a new command, or a subroutine.
>
> I'm sure that there are some shells that relax that. Busybox comes to mind.
> But a file per subroutine is the the shell "way".
The Bourne shell (sh) and all shells derived from it support functions.
There is absolutely no need to define shell functions in separate files.
csh and its derivative tcsh don't have functions -- which is one reason
why they're not recommended for use as programming languages. Shells
that *don't* provide functions are the exception.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-20 08:43 +1300 |
| Message-ID | <d8kvfgFge23U6@mid.individual.net> |
| In reply to | #73279 |
Malcolm McLean wrote: >> > Java and C# are both samples of languages designed by people who took > a look at C++, said, "yes, we see what they are trying to do, but we don't think > they did it very well". No, they are not. Java started life as an interpreted form of C++ for dummies designed to run in a secure, sand-boxed environment which enabled Java applications to run anywhere there was a JVM. It's main use was to run applications from a web browser. C# was Microsoft's response to Java once the latter started encroaching into the sever space and threatened to liberate their tied customers! C# derived more from from Java, not C. > Then they returned to C as their base and re-derived > the extensions, admittedly with some influence from C++. No, they did not. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-19 13:00 -0700 |
| Message-ID | <lnmvvey6gg.fsf@kst-u.example.com> |
| In reply to | #73329 |
Ian Collins <ian-news@hotmail.com> writes:
> Malcolm McLean wrote:
>>>
>> Java and C# are both samples of languages designed by people who took
>> a look at C++, said, "yes, we see what they are trying to do, but we don't think
>> they did it very well".
>
> No, they are not.
>
> Java started life as an interpreted form of C++ for dummies designed to
> run in a secure, sand-boxed environment which enabled Java applications
> to run anywhere there was a JVM. It's main use was to run applications
> from a web browser.
Java's was *originally* designed (with the name "Oak") for interactive
television. Its use in web browsers came later.
Calling it interpreted is a bit of an oversimplification. Java is
compiled to Java byte code, which is then executed by a JVM. Other
languages can be compiled to Java byte code, and at least in principle
you could (I think) have an implementation of the Java language that
doesn't use Java bytecode or the JVM.
In a sense it's a pity that the byte code format and the virtual machine
have "Java" in their names.
(None of this refutes your underlying points.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-19 20:34 +0000 |
| Message-ID | <slrnn2akuo.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #73329 |
On Mon, 2015-10-19, Ian Collins wrote: > Malcolm McLean wrote: >>> >> Java and C# are both samples of languages designed by people who >> took a look at C++, said, "yes, we see what they are trying to do, >> but we don't think they did it very well". > > No, they are not. > > Java started life as an interpreted form of C++ for dummies designed to > run in a secure, sand-boxed environment which enabled Java applications > to run anywhere there was a JVM. It's main use was to run applications > from a web browser. As I remember it, around 1998 a lot of people were pitching Java as "C++ done right", so in that sense I partly agree with Malcolm. > C# was Microsoft's response to Java once the latter started encroaching > into the sever space and threatened to liberate their tied customers! > C# derived more from from Java, not C. > >> Then they returned to C as their base and re-derived >> the extensions, admittedly with some influence from C++. > > No, they did not. With Java it was almost a selling point that they ditched C compatibility: arrays, pointers, the various scalar types, the standard libraries and all third-party libraries ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-20 09:47 +1300 |
| Message-ID | <d8l36oFge23U7@mid.individual.net> |
| In reply to | #73334 |
Jorgen Grahn wrote: > On Mon, 2015-10-19, Ian Collins wrote: >> Malcolm McLean wrote: >>>> >>> Java and C# are both samples of languages designed by people who >>> took a look at C++, said, "yes, we see what they are trying to do, >>> but we don't think they did it very well". >> >> No, they are not. >> >> Java started life as an interpreted form of C++ for dummies designed to >> run in a secure, sand-boxed environment which enabled Java applications >> to run anywhere there was a JVM. It's main use was to run applications >> from a web browser. > > As I remember it, around 1998 a lot of people were pitching Java as > "C++ done right", so in that sense I partly agree with Malcolm. It was more a case of C++ with the "dangerous" bits removed. Those "dangerous" bits where the bits C++ inherited from C :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-19 16:32 -0700 |
| Message-ID | <3f1743f1-7188-47ce-acda-13c9c9a2088b@googlegroups.com> |
| In reply to | #73336 |
On Monday, October 19, 2015 at 3:47:31 PM UTC-5, Ian Collins wrote: > It was more a case of C++ with the "dangerous" bits removed. Those > "dangerous" bits where the bits C++ inherited from C :) C++ uses an object-lifetime model which works well for almost everything except owner-less objects which encapsulate data in sub-objects of mutable type which are never exposed to anything that might mutate them. It really does not work very well for those, however. While it should be possible for multiple threads to pass around references to an object of such a type without conflict, C++ requires synchronization on the data structures used to keep track of remaining references. Java uses a fundamentally different model which works well for everything except objects which encapsulate resources (i.e. have acquired ownership of something from an outside entity with a promise to tell that entity when it's no longer needed). It really does not work well for those. I wish someone would design a language/framework which was designed to combine the two ownership models, since each offers good support for some situations which the other handles rather poorly.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-20 10:37 +0000 |
| Message-ID | <slrnn2c6br.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #73336 |
On Mon, 2015-10-19, Ian Collins wrote: > Jorgen Grahn wrote: >> On Mon, 2015-10-19, Ian Collins wrote: >>> Malcolm McLean wrote: >>>>> >>>> Java and C# are both samples of languages designed by people who >>>> took a look at C++, said, "yes, we see what they are trying to do, >>>> but we don't think they did it very well". >>> >>> No, they are not. >>> >>> Java started life as an interpreted form of C++ for dummies designed to >>> run in a secure, sand-boxed environment which enabled Java applications >>> to run anywhere there was a JVM. It's main use was to run applications >>> from a web browser. >> >> As I remember it, around 1998 a lot of people were pitching Java as >> "C++ done right", so in that sense I partly agree with Malcolm. > > It was more a case of C++ with the "dangerous" bits removed. Those > "dangerous" bits where the bits C++ inherited from C :) You're right -- it comes back to me now. It was interesting: at least around where I worked, there was this feeling we'd all be programming in Java in a few years; that it would replace C and make C++ (and most other languages) irrelevant. It's better the way it turned out instead: a lot of languages to choose from, many of the important ones free. And (although I prefer C++) C alive and well. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-19 21:24 +0000 |
| Message-ID | <n03n28$2ji$2@speranza.aioe.org> |
| In reply to | #73329 |
Ian Collins <ian-news@hotmail.com> wrote: > Malcolm McLean wrote: >> Java and C# are both samples of languages designed by people who took >> a look at C++, said, "yes, we see what they are trying to do, >> but we don't think they did it very well". > No, they are not. > Java started life as an interpreted form of C++ for dummies designed to > run in a secure, sand-boxed environment which enabled Java applications > to run anywhere there was a JVM. It's main use was to run applications > from a web browser. As far as I understand it, Java was intentionally more C-like than C++ was. They wanted Java to be easy for C programmers to learn and use. Note the addition, finally, of System.out.format(). -- glen
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-20 13:49 +0000 |
| Message-ID | <slrnn2chk3.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #73343 |
On Mon, 2015-10-19, glen herrmannsfeldt wrote: > Ian Collins <ian-news@hotmail.com> wrote: >> Malcolm McLean wrote: > >>> Java and C# are both samples of languages designed by people who took >>> a look at C++, said, "yes, we see what they are trying to do, >>> but we don't think they did it very well". > >> No, they are not. > >> Java started life as an interpreted form of C++ for dummies designed to >> run in a secure, sand-boxed environment which enabled Java applications >> to run anywhere there was a JVM. It's main use was to run applications >> from a web browser. > > As far as I understand it, Java was intentionally more C-like > than C++ was. > > They wanted Java to be easy for C programmers to learn and use. Care to cite any examples? I don't know a lot about Java, but I cannot think of a single such feature -- Java seems very different from C, and C++ is more or less a superset of C ... > Note the addition, finally, of System.out.format(). /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-20 07:33 -0700 |
| Message-ID | <a5506a43-242d-4582-8343-3510154bb23a@googlegroups.com> |
| In reply to | #73403 |
On Tuesday, October 20, 2015 at 2:50:21 PM UTC+1, Jorgen Grahn wrote: > On Mon, 2015-10-19, glen herrmannsfeldt wrote: > > > They wanted Java to be easy for C programmers to learn and use. > > Care to cite any examples? I don't know a lot about Java, but I > cannot think of a single such feature -- Java seems very different > from C, and C++ is more or less a superset of C ... > Java has the C superficialities - the use of curly braces for blocks, the same keywords for flow control and for basic types, the same shift and logical operators and array subscript operator. However it doesn't allow raw pointer access, and strings are quite different, being read only. It also encourages the use of C++ style classes with inheritance hierarchies and member functions, using a similar syntax to C++. The deeper similarity is that everything is based on a call stack, once you strip away the the syntax, with a mixture of direct and indirected calls, just like C, with the types of the objects on the stack essentially determined at compile time. There is a "reflection" system that allows a form of dynamic typing, but it's bolted on as an extension, it's not used as part of the base functionality.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-20 15:53 +0000 |
| Message-ID | <n05o1o$k29$1@speranza.aioe.org> |
| In reply to | #73406 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: (snip, I wrote) >> > They wanted Java to be easy for C programmers to learn and use. (someone wrote) >> Care to cite any examples? I don't know a lot about Java, but I >> cannot think of a single such feature -- Java seems very different >> from C, and C++ is more or less a superset of C ... > Java has the C superficialities - the use of curly braces for > blocks, the same keywords for flow control and for basic types, > the same shift and logical operators and array subscript operator. > However it doesn't allow raw pointer access, and strings are > quite different, being read only. It also encourages the use > of C++ style classes with inheritance hierarchies > and member functions, using a similar syntax to C++. Note that >> and << are shift operators, unlike the way C++ uses them. > The deeper similarity is that everything is based on a > call stack, once you strip away the the syntax, with a > mixture of direct and indirected calls, just like C, > with the types of the objects on the stack essentially > determined at compile time. There is a "reflection" system > that allows a form of dynamic typing, but it's bolted on as > an extension, it's not used as part of the base functionality. If you write only static methods, it works very much like C. One interesting thing is that Java doesn't have anything like C's mutli-dimensional arrays. There is no: int x[10][10]; If you say: int x[][]=new int[10][10]; you end up with an array of 10 references to arrays of 10 ints, the way C programmers more often use arrays. In one statement, it does the same as: int x[][]; x=new int[10][]; for(int i=0;i<10;i++) x[i]=new int[10]; arrays are objects, allocated the same way all objects are. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-20 10:37 -0700 |
| Message-ID | <ln1tcpxwy7.fsf@kst-u.example.com> |
| In reply to | #73414 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Malcolm McLean <malcolm.mclean5@btinternet.com> wrote:
[...]
>> Java has the C superficialities - the use of curly braces for
>> blocks, the same keywords for flow control and for basic types,
>> the same shift and logical operators and array subscript operator.
>> However it doesn't allow raw pointer access, and strings are
>> quite different, being read only. It also encourages the use
>> of C++ style classes with inheritance hierarchies
>> and member functions, using a similar syntax to C++.
>
> Note that >> and << are shift operators, unlike the way C++ uses them.
">>" and "<<" are shift operators in C++, just as they are in C.
The C++ standard library happens to overload them for I/O.
(Lengthy flame war about how bad an idea it was to use << and >> for I/O
omitted.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-10-21 05:05 +0000 |
| Message-ID | <n076fb$ikb$1@speranza.aioe.org> |
| In reply to | #73430 |
Keith Thompson <kst-u@mib.org> wrote: (snip, I wrote) >> Note that >> and << are shift operators, unlike the way C++ uses them. > ">>" and "<<" are shift operators in C++, just as they are in C. > The C++ standard library happens to overload them for I/O. Yes, that is what I meant. Maybe I could have said "mostly uses", and it would have been closer. What fraction of << and >> are used for shift, and what fraction for I/O? > (Lengthy flame war about how bad an idea it was to use << > and >> for I/O omitted.) Good. Anyway, Java avoided that one. To me, that was a pretty important difference. That difference is a big part of why I believe that Java is more C-like than C++, considering how important I/O is for many programs. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-10-21 02:02 -0700 |
| Message-ID | <32a8a665-cc49-4d11-9740-8e4eaac46212@googlegroups.com> |
| In reply to | #73445 |
On Wednesday, October 21, 2015 at 6:05:55 AM UTC+1, glen herrmannsfeldt wrote: > > Anyway, Java avoided that one. To me, that was a pretty important > difference. That difference is a big part of why I believe > that Java is more C-like than C++, considering how important > I/O is for many programs. > What Java did, but not well, was to introduce a "serialisable" interface. Serialisation is one of those think, like memory allocation, which can be implemented in ordinary user code, but is in fact fundamental to most programs, and should be part of the language. IO itself should be decoupled from it (except for trivial low level reformatting, such as bit-endianness and text terminal control codes).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-21 06:07 -0700 |
| Message-ID | <bd954bab-e5cc-42d4-89e1-2b0b61d5ea9f@googlegroups.com> |
| In reply to | #73465 |
On Wednesday, October 21, 2015 at 4:02:29 AM UTC-5, Malcolm McLean wrote: > What Java did, but not well, was to introduce a "serialisable" interface. > > Serialisation is one of those think, like memory allocation, which can be > implemented in ordinary user code, but is in fact fundamental to most > programs, and should be part of the language. IO itself should be decoupled > from it (except for trivial low level reformatting, such as bit-endianness > and text terminal control codes). It's also one of those things which seems to have been viewed as "dubious" by the authors of the C89 Standard (or at least the rationale), with the consequence that even on systems with known endian-ness and alignment requirements there's often still (as of C11) no way to write code which is efficient and optimizer-proof. IMHO, C would really benefit from a standard set of compiler intrinsics which would accept a pointer and a value, and store the value at the pointer using a hard-coded number of bytes and endian-ness (using a simple store instruction if the endian-ness and alignment matched machine requirements, or something more complicated if necessary), and a matching set which given a pointer and a hard-coded number of bytes and endian-ness would read the data and return a number. It's possible to write something like: foo[0] = dat>>24; foo[1] = dat>>16; foo[2] = dat>>8; foo[3] = dat; but there are so many possible patterns a programmer might use it would be hard for an optimizer to recognize them all and turn them all into a combination of a byte-swap-register instruction and a word store. By contrast, if the Standard defined an intrinsic like __wu32be8 (write unsigned 32-bit value as little-endian octets) such a thing could be handled in the code generator directly with no pattern matching required.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-21 14:15 +0100 |
| Message-ID | <n0832f$m7$1@dont-email.me> |
| In reply to | #73480 |
On 21/10/2015 14:07, supercat@casperkitty.com wrote: > By > contrast, if the Standard defined an intrinsic like __wu32be8 (write unsigned > 32-bit value as little-endian octets) such a thing could be handled in the > code generator directly with no pattern matching required. It would be interesting to see what the language would look like if it adopted all your suggestions for pragmas and intrinsics that tell the compiler how to do its job. My view is that such code would be painful to write and a nightmare for anyone else to read. Take a quick survey of a few other languages. If any of them are also bursting with controls such as "__wu32be8", then I take back what I said! But I still think that the point of using C is that it should be simpler to read or write then assembly. All these additions to it would make it harder. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-21 09:23 -0700 |
| Message-ID | <aedc6450-d0f4-4739-91e1-3390dc389d36@googlegroups.com> |
| In reply to | #73481 |
On Wednesday, October 21, 2015 at 8:16:15 AM UTC-5, Bart wrote:
> It would be interesting to see what the language would look like if it
> adopted all your suggestions for pragmas and intrinsics that tell the
> compiler how to do its job.
>
> My view is that such code would be painful to write and a nightmare for
> anyone else to read.
A lot of programs write their own macros to do the sort of things I describe.
Unfortunately, there's no real consistency in them. Suppose one is reading
some code and encounters "x = ror32(y, z);" One might guess that it rotates
a 32-bit value y to the right by z bits and stores the result into x, but
how would one answer the following questions:
1. If z is outside the range 0 to 31, will the code rotated by (z mod 32),
will it yield a possibly-nonsensical value, or will it invoke Undefined
Behavior?
2. What might the above code do if y and/or z were replaced by expressions
with side-effects? Would such side-effects be executed once or twice?
If y or z were a volatile variable and it changed during execution, would
the function yield a value corresponding with either the old or new
value, would it yield a possibly-nonsensical value, or will it invoke
Undefined Behavior.
When reading code, would you like to have to look up the definition of every
ror32() you find to see what it's doing, or would it be nicer to know that
every __ror32m() is going to behave the same way (rotate a 32-bit value,
using mod-32 semantics)?
Also, I'm curious: suppose you were tasked with writing portable code to
fill in the following structure from a sequence of bytes which is stored
in LSB-first order without padding, how would you go about it:
typedef struct {long x,y;} SHAPE;
typedef struct {
unsigned short mode, count;
long x,y;
struct POINT deltas[];
} SHAPE;
Using the kind of intrinsics I'd like to see, if the source were known to
be 32-bit aligned, the code would be something like:
SHAPE *parse(void *dat)
{
SHAPE *result;
POINT *result_deltas;
unsigned char *p = dat;
__ALIAS_REGION
{
unsigned count = __fetch_u16le8a(p+2);
result = malloc(sizeof (SHAPE) + count * sizeof (POINT));
result->mode =__fetch_u16le8a(p+0);
result->count=count;
result->x=__fetch_s32le8a(p+4);
result->y=__fetch_s32le8a(p+8);
result_deltas = &result->deltas;
p+=12;
while(count--)
{
result_deltas->x = __fetch_u32le8a(p+0);
result_deltas->y = __fetch_u32le8a(p+4);
p+=8;
result_deltas++;
}
}
return result;
}
While I can imagine additional language features that would allow the code
to be written more nicely, one could define strictly-conforming functions
which would make the above code work correctly on any standard-compliant
machine, regardless of the sizes of "char" or any of the integer types
(if "unsigned char" is larger than 8 bits, the data would be expected to be
stored in the bottom 8 bits of each character).
If the language supporting intrinsics, someone who had never seen them
before would have to look up __fetch* and learn that __fetch_* means
"take a pointer and fetch enough values of a given size (typically 8 bits)
to hold up an signed/unsigned integer of some size, either assuming the
pointer has some kind of alignment or not, and assemble those values into
the indicated type", and then learn that in particular __fetch_s32le8a()
would mean "take a pointer to a sequence of 32/8=four 8-bit values which
is aligned to a multiple of four, and interpret those four values as a
32-bit signed number stored LSB first." Having learned what "__fetch*"
meant once, a programmer would know what it meant in every program where
it was encountered.
If you don't like the idea of intrinsics such as I described, how would
you suggest writing the above code so it remains portable but remains
just as efficient and readable?
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-21 18:30 +0100 |
| Message-ID | <n08i05$uil$1@dont-email.me> |
| In reply to | #73497 |
On 21/10/2015 17:23, supercat@casperkitty.com wrote:
> On Wednesday, October 21, 2015 at 8:16:15 AM UTC-5, Bart wrote:
>> It would be interesting to see what the language would look like if it
>> adopted all your suggestions for pragmas and intrinsics that tell the
>> compiler how to do its job.
> A lot of programs write their own macros to do the sort of things I describe.
> Unfortunately, there's no real consistency in them. Suppose one is reading
> some code and encounters "x = ror32(y, z);" One might guess that it rotates
> a 32-bit value y to the right by z bits and stores the result into x, but
> how would one answer the following questions:
I find such operations incredibly rare. (My own language at one time had
rol and rot operators built-in; but they were never used and were
eventually dropped.)
If they are needed, then you write a function to do it exactly how you
want it. Such a function will be largely portable (it might be awkward
on a system with 29-bit ints). And C compilers could well be clever
enough to recognise when it maps to a hardware rotate operation.
> Also, I'm curious: suppose you were tasked with writing portable code to
> fill in the following structure from a sequence of bytes which is stored
> in LSB-first order without padding, how would you go about it:
>
> typedef struct {long x,y;} SHAPE;
(You meant POINT here?)
> typedef struct {
> unsigned short mode, count;
> long x,y;
> struct POINT deltas[];
> } SHAPE;
>
> Using the kind of intrinsics I'd like to see, if the source were known to
> be 32-bit aligned, the code would be something like:
>
> SHAPE *parse(void *dat)
> {
> SHAPE *result;
> POINT *result_deltas;
> unsigned char *p = dat;
> __ALIAS_REGION
> {
> unsigned count = __fetch_u16le8a(p+2);
> result = malloc(sizeof (SHAPE) + count * sizeof (POINT));
> result->mode =__fetch_u16le8a(p+0);
> result->count=count;
> result->x=__fetch_s32le8a(p+4);
> result->y=__fetch_s32le8a(p+8);
> result_deltas = &result->deltas;
> p+=12;
> while(count--)
> {
> result_deltas->x = __fetch_u32le8a(p+0);
> result_deltas->y = __fetch_u32le8a(p+4);
> p+=8;
> result_deltas++;
> }
> }
> return result;
> }
I would do it the same way, but without those complicated intrinsics.
Example:
result->mode = readshort();
result->count = readshort();
result->x = readlong();
etc.
All the gubbins needed to make it work is inside readshort() and
readlong(). This gives the main code highly portable and less cluttered
with __fetch_s32le8a which people are really not going to be interested in.
(And what happens when the input is big-endian? You've now got
__fetch_s32LE8a all over the place.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web