Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #150040 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2020-02-16 02:25 -0800 |
| Last post | 2020-04-09 07:38 -0700 |
| Articles | 20 on this page of 148 — 20 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-16 02:25 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-16 14:24 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-22 08:13 -0800
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-02-22 09:05 -0800
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-03-27 19:58 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-03-27 23:26 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 09:21 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 09:54 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 11:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-02 13:12 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-02 13:28 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 19:17 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 09:47 +0200
Re: C String terminator already5chosen@yahoo.com - 2020-04-03 08:03 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 17:34 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 12:39 -0400
Re: C String terminator Bart <bc@freeuk.com> - 2020-04-03 18:05 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 10:18 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:13 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 14:36 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 16:18 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 01:43 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:23 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 11:18 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:02 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-05 21:54 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 13:59 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-06 09:07 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 02:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 11:43 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 03:56 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 16:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 10:30 -0700
Re: C String terminator richard@cogsci.ed.ac.uk (Richard Tobin) - 2020-04-06 17:50 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 11:31 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 12:04 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 21:51 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:34 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 14:39 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 14:52 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 15:31 -0700
Re: C String terminator jameskuyper@stellarscience.com - 2020-04-06 16:05 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 03:08 +0100
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-06 21:12 -0600
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 16:55 +0000
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 11:05 -0600
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-07 20:39 +0200
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:48 -0700
Re: C String terminator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-04-07 21:21 -0600
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 20:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 01:41 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 07:40 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 08:16 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 09:17 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 09:46 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 10:37 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 10:48 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-08 14:07 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 11:29 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-08 16:46 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 01:57 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 08:56 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 12:42 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 10:12 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 15:51 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 13:02 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 13:06 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 14:49 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-09 19:05 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 02:25 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 04:38 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 05:21 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-10 07:13 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-10 11:38 -0700
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-11 17:38 +0000
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:04 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-11 15:16 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-11 21:45 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 04:39 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-12 21:34 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-12 14:38 -0700
Re: C String terminator Richard Damon <Richard@Damon-Family.org> - 2020-04-13 11:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-13 08:24 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-11 15:08 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-09 09:53 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:35 -0400
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-06 21:04 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 01:16 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 02:08 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 02:19 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 08:42 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 10:39 -0700
Re: C String terminator scott@slp53.sl.home (Scott Lurndal) - 2020-04-07 17:45 +0000
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-07 14:40 -0400
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 11:03 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-07 12:19 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:02 +0100
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 06:27 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 07:44 -0700
Re: C String terminator Öö Tiib <ootiib@hot.ee> - 2020-04-07 08:30 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 00:27 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 12:50 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-07 05:25 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-07 23:52 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 03:15 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-08 21:28 +0100
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-08 15:40 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-09 00:31 +0100
Re: C String terminator Ike Naar <ike@sdf.lonestar.org> - 2020-04-07 21:40 +0000
Re: C String terminator luser droog <luser.droog@gmail.com> - 2020-04-06 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-06 12:46 -0700
Re: C String terminator Guillaume <message@bottle.org> - 2020-04-07 17:17 +0200
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:23 -0700
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-04 22:32 +0100
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-03 21:59 +0200
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:48 -0400
Jared Kushner would be proud... (Was: C String terminator) gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-04 09:00 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 02:45 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-04-04 10:24 +0000
Re: Jared Kushner would be proud... (Was: C String terminator) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 03:55 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 13:27 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 13:52 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-04 14:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:12 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-04 15:03 -0700
Re: Jared Kushner would be proud... Richard Damon <Richard@Damon-Family.org> - 2020-04-04 18:46 -0400
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 01:53 -0700
Re: Jared Kushner would be proud... Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-05 02:33 -0700
Re: Jared Kushner would be proud... Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 06:43 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 19:48 -0700
Re: Jared Kushner would be proud... (Was: C String terminator) James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-04 06:37 -0700
Re: C String terminator David Brown <david.brown@hesbynett.no> - 2020-04-04 18:36 +0200
Re: C String terminator dave_thompson_2@comcast.net - 2020-05-02 15:13 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 09:41 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 10:33 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 11:14 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 11:34 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 14:48 -0400
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-03 12:10 -0700
Re: C String terminator Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-03 13:24 -0700
Re: C String terminator James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-03 23:59 -0400
Re: C String terminator Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-03 22:05 +0100
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 20:34 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 02:05 -0700
Re: C String terminator Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-09 07:35 -0700
Re: C String terminator Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-09 07:38 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-06 15:31 -0700 |
| Message-ID | <87h7xwmejp.fsf@nosuchdomain.example.com> |
| In reply to | #151163 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 6 April 2020 22:39:08 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>> > The English word for that relationship is "function". That's the right
>> > term to use.
>> [...]
>>
>> No, that's not what "function" means in C, which is the topic of this
>> newsgroup.
>>
>> (Don't worry, I'm not planning to do this indefinitely.)
>>
> OK, so sugest another term for "a relationship bewteen an first set
> of bits and a second set of bits, such that there is a mapping
> of every member of the first set to one and only one member of
> the second set".
I'll leave that to you.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@stellarscience.com |
|---|---|
| Date | 2020-04-06 16:05 -0700 |
| Message-ID | <657c1ac4-9c19-4fe0-a9f1-9332a53c408f@googlegroups.com> |
| In reply to | #151163 |
On Monday, April 6, 2020 at 5:52:23 PM UTC-4, Malcolm McLean wrote: > On Monday, 6 April 2020 22:39:08 UTC+1, Keith Thompson wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > [...] > > > The English word for that relationship is "function". That's the right > > > term to use. > > [...] > > > > No, that's not what "function" means in C, which is the topic of this > > newsgroup. > > > > (Don't worry, I'm not planning to do this indefinitely.) > > > OK, so sugest another term for "a relationship bewteen an first set > of bits and a second set of bits, such that there is a mapping > of every member of the first set to one and only one member of > the second set". When there's a question how a term should be defined, it's often useful to consider how you would use the term. It would certainly not be appropriate to take any sentence in the the C standard and re-write it by simply replacing "function" with "Malcolm-function", because that would change the meaning of the sentence, and the meaning of that sentence as currently written, with the meaning of "function" as currently defined, is the meaning that the committee intended that sentence to have. Is there any clause in the standard which could be made simpler, without changing it's meaning, by re-writing it to use "Malcolm-function" rather than "function"? If so, could you provide that re-write? Can you give an example of a sentence you would write using the term "Malcolm-function" which conveys any useful information other than simply defining the term? It should be a sentence for which the term "function" as defined in mathematics would not be a good substitute, because that definition excludes rand(). Also, is should be one where the term "function" as defined in C would not be appropriate, because it would include printf().
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-07 03:08 +0100 |
| Message-ID | <87blo49heb.fsf@bsb.me.uk> |
| In reply to | #151160 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > Ok, so what about indirect subroutines? Clearly qsort is a function > and not a procedure. But what if someone slips a printf into the > comparison function? Doesn't that break our rules? > > More about that later. Does anyone else care about the distinction you are making? But if you come up with any references that support the idea that a routine that does not do IO should be called a function and one the does, a procedure, I'd be interested. It might answer the questions you have not. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-04-06 21:12 -0600 |
| Message-ID | <1blfn8m1ke.fsf@pfeifferfamily.net> |
| In reply to | #151166 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> Ok, so what about indirect subroutines? Clearly qsort is a function >> and not a procedure. But what if someone slips a printf into the >> comparison function? Doesn't that break our rules? >> >> More about that later. > > Does anyone else care about the distinction you are making? But if you > come up with any references that support the idea that a routine that > does not do IO should be called a function and one the does, a > procedure, I'd be interested. It might answer the questions you have > not. Of course not. If anyone did, either there would be competing definitions of "function" and "procedure" (or, conceivably, the existing terms could match Malcolm's definitions), or there would be new terms based on the distinction.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2020-04-07 16:55 +0000 |
| Message-ID | <2g2jG.166546$xv4.74746@fx18.iad> |
| In reply to | #151167 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> Ok, so what about indirect subroutines? Clearly qsort is a function >>> and not a procedure. But what if someone slips a printf into the >>> comparison function? Doesn't that break our rules? >>> >>> More about that later. >> >> Does anyone else care about the distinction you are making? But if you >> come up with any references that support the idea that a routine that >> does not do IO should be called a function and one the does, a >> procedure, I'd be interested. It might answer the questions you have >> not. > >Of course not. If anyone did, either there would be competing >definitions of "function" and "procedure" (or, conceivably, the existing >terms could match Malcolm's definitions), or there would be new terms >based on the distinction. He's probably an old Pascal programmer, wherein there was a distinction between procedure and function.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-04-07 11:05 -0600 |
| Message-ID | <1bblo3mdkr.fsf@pfeifferfamily.net> |
| In reply to | #151195 |
scott@slp53.sl.home (Scott Lurndal) writes: > Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >>Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>>> Ok, so what about indirect subroutines? Clearly qsort is a function >>>> and not a procedure. But what if someone slips a printf into the >>>> comparison function? Doesn't that break our rules? >>>> >>>> More about that later. >>> >>> Does anyone else care about the distinction you are making? But if you >>> come up with any references that support the idea that a routine that >>> does not do IO should be called a function and one the does, a >>> procedure, I'd be interested. It might answer the questions you have >>> not. >> >>Of course not. If anyone did, either there would be competing >>definitions of "function" and "procedure" (or, conceivably, the existing >>terms could match Malcolm's definitions), or there would be new terms >>based on the distinction. > > He's probably an old Pascal programmer, wherein there was a distinction > between procedure and function. I thought about mentioning Pascal, but the distinction there isn't Malcolm's. Likewise Fortran functions and subroutines.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-07 20:39 +0200 |
| Message-ID | <r6ihcr$psd$2@dont-email.me> |
| In reply to | #151197 |
On 07/04/2020 19:05, Joe Pfeiffer wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > >> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: >>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >>> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>> Ok, so what about indirect subroutines? Clearly qsort is a function >>>>> and not a procedure. But what if someone slips a printf into the >>>>> comparison function? Doesn't that break our rules? >>>>> >>>>> More about that later. >>>> >>>> Does anyone else care about the distinction you are making? But if you >>>> come up with any references that support the idea that a routine that >>>> does not do IO should be called a function and one the does, a >>>> procedure, I'd be interested. It might answer the questions you have >>>> not. >>> >>> Of course not. If anyone did, either there would be competing >>> definitions of "function" and "procedure" (or, conceivably, the existing >>> terms could match Malcolm's definitions), or there would be new terms >>> based on the distinction. >> >> He's probably an old Pascal programmer, wherein there was a distinction >> between procedure and function. > > I thought about mentioning Pascal, but the distinction there isn't > Malcolm's. Likewise Fortran functions and subroutines. > I /did/ mention Pascal - and as you say, its distinction between procedures and functions does not match Malcolm's.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-07 11:48 -0700 |
| Message-ID | <de0b717c-85eb-49b6-91b2-e2122a94bdea@googlegroups.com> |
| In reply to | #151206 |
On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: > > I /did/ mention Pascal - and as you say, its distinction between > procedures and functions does not match Malcolm's. > However C does make the distinction. With C, you can implement any mathematical function using just the language, within the limits of the computer's memory. However you can't implement a single one of what I call procedures, other than by knowing the hardware you are running on and writing to absolute memory addresses when that's the IO facility.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2020-04-07 21:21 -0600 |
| Message-ID | <1bftder7by.fsf@pfeifferfamily.net> |
| In reply to | #151208 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: >> >> I /did/ mention Pascal - and as you say, its distinction between >> procedures and functions does not match Malcolm's. >> > However C does make the distinction. With C, you can implement any > mathematical function using just the language, within the limits of > the computer's memory. However you can't implement a single one > of what I call procedures, other than by knowing the hardware you > are running on and writing to absolute memory addresses when that's > the IO facility. A very quick search doesn't find the word "procedure" in the standard at all, let alone make any distinction between procedures and functions.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-07 20:40 -0700 |
| Message-ID | <097a50af-465c-4b1d-85e5-679dae8cf919@googlegroups.com> |
| In reply to | #151208 |
On Tuesday, April 7, 2020 at 2:48:21 PM UTC-4, Malcolm McLean wrote: > On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: > > > > I /did/ mention Pascal - and as you say, its distinction between > > procedures and functions does not match Malcolm's. > > > However C does make the distinction. No, it does not. You cannot make a distinction between a procedure and a function without using both terms. The C standard only uses the term "function", never uses the term "procedure", and uses the term "function" to refer to things you call procedures, as is consistent with the C standard's definition for the term "function".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 01:41 -0700 |
| Message-ID | <bc551179-10ce-4249-bb22-7c421dfd765c@googlegroups.com> |
| In reply to | #151223 |
On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: > On Tuesday, April 7, 2020 at 2:48:21 PM UTC-4, Malcolm McLean wrote: > > On Tuesday, 7 April 2020 19:39:32 UTC+1, David Brown wrote: > > > > > > I /did/ mention Pascal - and as you say, its distinction between > > > procedures and functions does not match Malcolm's. > > > > > However C does make the distinction. > > No, it does not. You cannot make a distinction between a procedure and a > function without using both terms. The C standard only uses the term > "function", never uses the term "procedure", and uses the term > "function" to refer to things you call procedures, as is consistent with > the C standard's definition for the term "function". > In C, every "Malcolm function" if I must still use the term can be written using just the language, and none of the libraries. Not a single "Malcolm procedure" can be written using just the language, ubless IO is memory-mapped and you know the absolute address to which to write, in which case you are using a non-portable feature. So C does make the distinction I'm making. That's not necessarily true of other languages where IO is implememted by statements which are part of the language and always available.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 07:40 -0700 |
| Message-ID | <b2fd88f2-f146-4920-99ed-1ed1c38bcdae@googlegroups.com> |
| In reply to | #151227 |
On Wednesday, April 8, 2020 at 4:41:49 AM UTC-4, Malcolm McLean wrote: > On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: ... > > No, it does not. You cannot make a distinction between a procedure and a > > function without using both terms. The C standard only uses the term > > "function", never uses the term "procedure", and uses the term > > "function" to refer to things you call procedures, as is consistent with > > the C standard's definition for the term "function". > > > In C, every "Malcolm function" if I must still use the term can be written > using just the language, and none of the libraries. Not a single > "Malcolm procedure" can be written using just the language, ubless > IO is memory-mapped and you know the absolute address to which to write, > in which case you are using a non-portable feature. > > So C does make the distinction I'm making. So, Malcolm-"make a distinction" is yet another phrase that has a different meaning for you than it does in ordinary English. Using normal English, you could describe those facts by saying that C provides terminology that allows you to make the distinction, but C itself does not make the distinction. Even though C Malcolm-"makes a distinction" between a Malcolm-function and a Malcolm-procedure, C does not make a distinction between a function and a procedure.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 08:16 -0700 |
| Message-ID | <432104cf-304d-4cb6-b1a7-894c046a1607@googlegroups.com> |
| In reply to | #151232 |
On Wednesday, 8 April 2020 15:41:13 UTC+1, James Kuyper wrote: > On Wednesday, April 8, 2020 at 4:41:49 AM UTC-4, Malcolm McLean wrote: > > On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: > ... > > > No, it does not. You cannot make a distinction between a procedure and a > > > function without using both terms. The C standard only uses the term > > > "function", never uses the term "procedure", and uses the term > > > "function" to refer to things you call procedures, as is consistent with > > > the C standard's definition for the term "function". > > > > > In C, every "Malcolm function" if I must still use the term can be written > > using just the language, and none of the libraries. Not a single > > "Malcolm procedure" can be written using just the language, ubless > > IO is memory-mapped and you know the absolute address to which to write, > > in which case you are using a non-portable feature. > > > > So C does make the distinction I'm making. > > So, Malcolm-"make a distinction" is yet another phrase that has a > different meaning for you than it does in ordinary English. Using normal > English, you could describe those facts by saying that C provides > terminology that allows you to make the distinction, but C itself does > not make the distinction. Even though C Malcolm-"makes a distinction" > between a Malcolm-function and a Malcolm-procedure, C does not make a > distinction between a function and a procedure. > C is an abstract thing rather than a person or a text, so it can't actually "make a distinction". However the standard provides terminology that allows us to make the distiction - the "freestanding environment" and the "hosted enviornment". Every Malcolm function can be implemented in conforming C in a free standing enviornment, not a single Malcolm procedure can. And the C language provides facilities that allow us to enforce the distinction in the compiler. Basically remove all the includes and can the function still be implemented? So we've got the terminology and the language facilities in C to make the distinction. Happy?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 09:17 -0700 |
| Message-ID | <9c846fe9-50e0-4dff-a4e2-95a3c4de0481@googlegroups.com> |
| In reply to | #151233 |
On Wednesday, April 8, 2020 at 11:16:26 AM UTC-4, Malcolm McLean wrote: > On Wednesday, 8 April 2020 15:41:13 UTC+1, James Kuyper wrote: > > On Wednesday, April 8, 2020 at 4:41:49 AM UTC-4, Malcolm McLean wrote: > > > On Wednesday, 8 April 2020 04:40:42 UTC+1, James Kuyper wrote: > > ... > > > > No, it does not. You cannot make a distinction between a procedure and a > > > > function without using both terms. The C standard only uses the term > > > > "function", never uses the term "procedure", and uses the term > > > > "function" to refer to things you call procedures, as is consistent with > > > > the C standard's definition for the term "function". > > > > > > > In C, every "Malcolm function" if I must still use the term can be written > > > using just the language, and none of the libraries. Not a single > > > "Malcolm procedure" can be written using just the language, ubless > > > IO is memory-mapped and you know the absolute address to which to write, > > > in which case you are using a non-portable feature. > > > > > > So C does make the distinction I'm making. > > > > So, Malcolm-"make a distinction" is yet another phrase that has a > > different meaning for you than it does in ordinary English. Using normal > > English, you could describe those facts by saying that C provides > > terminology that allows you to make the distinction, but C itself does > > not make the distinction. Even though C Malcolm-"makes a distinction" > > between a Malcolm-function and a Malcolm-procedure, C does not make a > > distinction between a function and a procedure. > > > C is an abstract thing rather than a person or a text, so it can't > actually "make a distinction". The C standard is a text. As such, it could have made the distinction you talk about: - it could have defined the term "function" to mean one thing, and it could have defined the term "procedure" to mean something different - but it doesn't. It doesn't even use the term "procedure" at and it gives a very different meaning than yours to the term "function". > ... However the standard provides terminology > that allows us to make the distiction - the "freestanding environment" > and the "hosted enviornment". Every Malcolm function can be implemented > in conforming C in a free standing enviornment, not a single Malcolm > procedure can. Every free-standing environment has to provide some way to do input/output. Not because the standard says so, but because a program that doesn't do any I/O can't do anything useful except consume CPU resources (which can, in a limited number of contexts, be a useful thing to do). The difference is that in a freestanding environment, the ways in which I/O can be performed are implementation-specific. For instance, in some environments, initializing a volatile-qualified pointer by conversion from a integer constant with the proper value will allow writes through that pointer to do output, or reads through that pointer to do input. There's also likely to be implementation-specific libraries of functions to help you with such things. Note also that in a freestanding environment you can't rely upon support for anything in, for example, <math.h>. I don't believe that use of most of those functions has anything to do with the distinction you're making. > ... And the C language provides facilities that allow us > to enforce the distinction in the compiler. Basically remove all the > includes and can the function still be implemented? > > So we've got the terminology and the language facilities in C to > make the distinction. Except that disallowing #includes would also preclude use of <float.h>, <limits.h>, <stdarg.h>, <stddef.h>, and <stdint.h>, all of which must be supported in a freestanding environment. They all allow you to do useful things that are irrelevant, as I understand it, to the distinction between Malcolm-functions and Malcom-procedures. Also, you can do I/O without using any #includes, through command line arguments, the exit status from the program, and through volatile- qualified pointers.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 09:46 -0700 |
| Message-ID | <bf9c278e-e2b0-4b18-8e81-21a066dec4c8@googlegroups.com> |
| In reply to | #151234 |
On Wednesday, 8 April 2020 17:18:14 UTC+1, James Kuyper wrote: > > Note also that in a freestanding environment you can't rely upon support > for anything in, for example, <math.h>. I don't believe that use of most > of those functions has anything to do with the distinction you're > making. > No, but you can supply the math.h functions. As in fact you often have to do, though you write faster and less accurate versions typically. > > Except that disallowing #includes would also preclude use of <float.h>, > <limits.h>, <stdarg.h>, <stddef.h>, and <stdint.h>, all of which must be > supported in a freestanding environment. They all allow you to do useful > things that are irrelevant, as I understand it, to the distinction > between Malcolm-functions and Malcom-procedures. > Yes, in reality these headers are useful and will always be supplied, so there's no reason to ban them. There is a bit of fuzziness of C types. Whilst i've spoken about a "mapping of bits to bits" to try to explain, first that Malcolm functions are just "functions" in the mathematical but not the C sense, in fact we normally specify functions in terms of C types. So sqrt takes a double in whatever representation the platform uses for doubles, and returns another douuble which is closest representation to the square root. It doesn't make sense to specify it in terms of exponent and mantissa bit patterns. That is slightly problematic, because whilst I've said that Malcolm functions are portable, for some extreme inputs sqrt may succeed on some implentations and fail on others. C isn't a bit-based language. > > Also, you can do I/O without using any #includes, through command line > arguments, the exit status from the program, and through volatile- > qualified pointers. > main() is a special function, and might not be available. As for volatile, it can't have any effect unless you use non-core language facilities, like interrupts. So you can't implement a Malcolm procedure with just "volatile". Malcolm functions shouldn't use the volatile keyword, of course.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 10:37 -0700 |
| Message-ID | <2edf2e71-9692-4d9a-a112-23f8ad6b50e1@googlegroups.com> |
| In reply to | #151235 |
On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: ... > As for volatile, it can't have any effect unless you use non-core > language facilities, like interrupts. volatile int *port1 = (volatile int*)0x12345678; The result of that conversion is implementation-defined, and a fully conforming freestanding implementation of C could define that the result of that conversion is a pointer through which you can do either input or output through a device. That code only involves core language facilities.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 10:48 -0700 |
| Message-ID | <895233b7-8933-44ca-a8e9-c5cc980ec876@googlegroups.com> |
| In reply to | #151236 |
On Wednesday, 8 April 2020 18:38:15 UTC+1, James Kuyper wrote: > On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: > ... > > As for volatile, it can't have any effect unless you use non-core > > language facilities, like interrupts. > > volatile int *port1 = (volatile int*)0x12345678; > > The result of that conversion is implementation-defined, and a fully > conforming freestanding implementation of C could define that the result > of that conversion is a pointer through which you can do either input or > output through a device. That code only involves core language facilities. > Yes, as I said earlier upstream. The code isn't compliant, portable C, though it could and probably is used to implement IO. It's got an absolute memory address.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-08 14:07 -0400 |
| Message-ID | <NpojG.347488$mJ2.332099@fx23.iad> |
| In reply to | #151237 |
On 4/8/20 1:48 PM, Malcolm McLean wrote: > On Wednesday, 8 April 2020 18:38:15 UTC+1, James Kuyper wrote: >> On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: >> ... >>> As for volatile, it can't have any effect unless you use non-core >>> language facilities, like interrupts. >> >> volatile int *port1 = (volatile int*)0x12345678; >> >> The result of that conversion is implementation-defined, and a fully >> conforming freestanding implementation of C could define that the result >> of that conversion is a pointer through which you can do either input or >> output through a device. That code only involves core language facilities. >> > Yes, as I said earlier upstream. > The code isn't compliant, portable C, though it could and probably is > used to implement IO. It's got an absolute memory address. > > Maybe the answer is that the whole concept of a compliant portable 'Malcolm-Procedure' is an oxymoron, as there is no such thing as a 100% portable I/O operation. You also see to ignore that the C standard library isn't just a bunch of functions, but IS part of the language. An implementation would be totally conforming even if none of the include files mentioned in the standard actually existed as files, but when the compiler say the include statements the compiler just adjusted it state to indicate that it had seen that header, and all the functions were directly implemented in some manner by the compiler. A printf statement in a program doesn't actually need to call a function with a name something like printf. Making the system header files be real files using the C syntax (maybe with some extensions) and the library largely written in C is just a convenience to the implementation.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-08 11:29 -0700 |
| Message-ID | <d8461fac-4536-4493-812e-0bdb02f3aa0e@googlegroups.com> |
| In reply to | #151238 |
On Wednesday, 8 April 2020 19:07:50 UTC+1, Richard Damon wrote:
>
> Maybe the answer is that the whole concept of a compliant portable
> 'Malcolm-Procedure' is an oxymoron, as there is no such thing as a 100%
> portable I/O operation.
>
Exactly. The common answer is to say provide IO facilities as
subroutines which are abstracted away behind the subroutine
call. When the enviornment changes, the subroutine is replaced
by one with equivalent functionality.
So printf() sends characters to a teletype in early programs,
addresses a memory mapped character raster in middle ones, and
sends a stream of characters to the operating system to redirect
to a second program in modern ones.
But that approach has stopped working. You can't in practice
guarantee that printf("Hello world\n") will send a message to
user, even though you have a better chance that the program
will compile and link.
>
> You also see to ignore that the C standard library isn't just a bunch of
> functions, but IS part of the language.
>
Not it's not. That's part of the reason for the success of C. Every
program must do IO of some sort to be useful. But often that's not
by opening files or printing out messages. The program might be
running a thermostat. Input is the room temperature, based on some
sensor, and the target temperature, maybe entred by user via a
dial attached to another sensor. Output is the valve setting to
control the supply of fuel to the boiler. All this could be written
in C on a small processor with no stanard library.
Now let's say that one of the reasons we are using an electronic
control rather than mechanical one is that we don't want the response
to be linear, we want it to be sigmoid. So for some reason it's
better to ramp up the value slowly when it is coming from the "off"
position, and we only want a small change when we are near are target
to avoid overshoot, in the middle, we change the valve setting quite
quickly.
The sigmoid calculating code can be made portable, it can be tested
and debugged on a PC with a C compiler. The code to input the room
temperature, the target temperature, and to control the value
can't be made portable, it's specific to our device. It might still
be written in C, but it will be platform-dependent C with absolute
memory addresses to access the devices.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-08 16:46 -0700 |
| Message-ID | <673b0629-b32e-4391-9e10-93a6e3b00ffe@googlegroups.com> |
| In reply to | #151237 |
On Wednesday, April 8, 2020 at 1:48:28 PM UTC-4, Malcolm McLean wrote: > On Wednesday, 8 April 2020 18:38:15 UTC+1, James Kuyper wrote: > > On Wednesday, April 8, 2020 at 12:47:01 PM UTC-4, Malcolm McLean wrote: > > ... > > > As for volatile, it can't have any effect unless you use non-core > > > language facilities, like interrupts. > > > > volatile int *port1 = (volatile int*)0x12345678; > > > > The result of that conversion is implementation-defined, and a fully > > conforming freestanding implementation of C could define that the result > > of that conversion is a pointer through which you can do either input or > > output through a device. That code only involves core language facilities. > > > Yes, as I said earlier upstream. What, precisely, is it you're claiming to have said "earlier upstream"? That it is in fact possible for "volatile" to have an effect in code that uses only core language facilities? That's what I'm saying, that you're responding "Yes" to. If so, the why did you follow up at a later time, by saying "volatile ... can't have any effect unless you use non-core language facilities"? > The code isn't compliant, portable C, though it could and probably is > used to implement IO. It's got an absolute memory address. I'm not sure what you mean when you say this code isn't compliant - the standard doesn't use any variant of the term "comply". Normal usage (something that I would never dare accuse you of) is to say that something does or does not comply with a requirement - which relevant requirement does this code fail to comply with? This code contains no syntax errors or constraint violations, and does not have undefined behavior. You're right that this code isn't portable. However, this code uses only core language facilities - it's failure to be portable is due entirely to the fact that those core language facilities have implementation- defined behavior, which means that it isn't strictly conforming code. However, essentially all useful programs fail to be strictly conforming. You said nothing about requiring the code to be strictly conforming. Keeping in mind that implementation-defined behavior is "unspecified behavior where each implementation documents how the choice is made" (3.4.1), a program containing such code could qualify as a "correct program", in which case it is required to "act in accordance with 5.1.2.3" (4p3).
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web