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 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-16 02:25 -0800 |
| Subject | Re: C String terminator |
| Message-ID | <861rquhlqk.fsf@linuxsc.com> |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes: > > [...] > >>> Correction #1: in this case, the critical point is that, here, >>> printf() expects a C "string" as it's second argument (as well as >>> the first argument, which is the given format string "[%s]\n"). >> >> Technically, that isn't right. A %s conversion specifier requires >> as its argument a pointer to the first element of an array of >> character type, not a pointer to a string. It is true in this >> particular case that the array must have a null character in it to >> avoid undefined behavior, but the argument description says "pointer >> to array of character type", and does not mention "string". >> >> (Also: the possessive of "it" is "its", with no apostrophe. The >> word "it's", with an apostrophe, is a contraction of "it is".) > > I believe the reason it's described that way is that %s with a field > width can require a pointer that isn't necessarily a pointer to a > string. [..example..] The passage in question is part of paragraph 8 in section 7.21.6.1. This paragraph describes conversion /specifiers/, not conversion /specifications/. Considered as a conversion /specifier/, an 's' specifier takes a pointer to (an initial element in) an array of characters (which are wide characters if an 'l' length modifier is present, or regular characters if not). The wording used most likely reflects wanting to describe the 's' conversion specifier generally, rather than particular conversion specifications that use an 's' specifier. Incidentally, it's precision, not field width. > The standard *could* have equivalently stated that a pointer to a > string is required when the format contains a "%s" directive, but > that would have made it overly wordy with no clear benefit. More significantly, it would have been inconsistent with other parts of the same paragraph, which defines the semantics of conversion specifiers, not of whole conversion specifications (which are also called directives). It would be out of place in this paragraph to talk about a particular directive that contains an 's' specifier (and besides which is incomplete, because there are other cases where the character array needs to have a null character). > A pointer to a string *is* required for a "%s" directive, but the > standard says so only indirectly. I have some quibbles about the wording here, but more importantly I think this is a bad way to take in what the Standard does say. What the Standard does say is that an 's' specifier takes a pointer to an array of character type, which in some situations much include a null character within the array (and a %s specification is one of those). It can be convenient to think of a %s directive as needing a string argument, but the Standard doesn't say anything about strings in its description of 's' specifiers, only arrays of character type. In some cases an array argument needs to contain a string, but the argument is still the array, not the string.
[toc] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-02-16 14:24 -0800 |
| Message-ID | <87wo8m9nm4.fsf@nosuchdomain.example.com> |
| In reply to | #150040 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> A pointer to a string *is* required for a "%s" directive, but the
>> standard says so only indirectly.
>
> I have some quibbles about the wording here, but more importantly I
> think this is a bad way to take in what the Standard does say. What
> the Standard does say is that an 's' specifier takes a pointer to an
> array of character type, which in some situations much include a
> null character within the array (and a %s specification is one of
> those).
As you know, and as long as we're being precise, it doesn't take a
pointer to an array of character type. It takes a pointer to char (and
the char in question is treated as an element of an array). The
standard defines a "pointer to a string" as a pointer to the initial
element of a string. It has no such special-case definition for a
"pointer to an array", which already has a distinct meaning.
> It can be convenient to think of a %s directive as needing
> a string argument, but the Standard doesn't say anything about
> strings in its description of 's' specifiers, only arrays of
> character type. In some cases an array argument needs to contain a
> string, but the argument is still the array, not the string.
The argument is a pointer to the initial element of the array. Other
than that, I agree, and that was pretty much my point. The requirements
for the argument corresponding to a "%s" are equivalent to requiring a
pointer to a string, though they're not stated that way (and it would
not be particularly useful to state them that way).
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-22 08:13 -0800 |
| Message-ID | <86imjyd2hl.fsf@linuxsc.com> |
| In reply to | #150060 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > [...] > >>> A pointer to a string *is* required for a "%s" directive, but the >>> standard says so only indirectly. >> >> I have some quibbles about the wording here, but more importantly I >> think this is a bad way to take in what the Standard does say. What >> the Standard does say is that an 's' specifier takes a pointer to an >> array of character type, which in some situations much include a >> null character within the array (and a %s specification is one of >> those). > > As you know, and as long as we're being precise, it doesn't take a > pointer to an array of character type. It takes a pointer to char (and > the char in question is treated as an element of an array). [...] Yes, I glossed over the distinction between pointing to an array and pointing to the first element of an array. I thought the meaning would be clear from context. I need to add though that 'char' is not really accurate. The Standard says "character type" and I think it means that, not just 'char'. Furthermore if an 'l' length modifier is present then the array elements are assumed to be of type 'wchar_t'. Both the regular character types and wchar_t fall under the common umbrella of "character type". >> It can be convenient to think of a %s directive as needing >> a string argument, but the Standard doesn't say anything about >> strings in its description of 's' specifiers, only arrays of >> character type. In some cases an array argument needs to contain a >> string, but the argument is still the array, not the string. > > The argument is a pointer to the initial element of the array. Other > than that, I agree, and that was pretty much my point. The requirements > for the argument corresponding to a "%s" are equivalent to requiring a > pointer to a string, though they're not stated that way (and it would > not be particularly useful to state them that way). I'm glad we are essentially in agreement.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-02-22 09:05 -0800 |
| Message-ID | <87blpqa6y6.fsf@nosuchdomain.example.com> |
| In reply to | #150148 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> [...]
>>
>>>> A pointer to a string *is* required for a "%s" directive, but the
>>>> standard says so only indirectly.
[...]
> I need to add though that 'char' is not really accurate. The Standard
> says "character type" and I think it means that, not just 'char'.
> Furthermore if an 'l' length modifier is present then the array
> elements are assumed to be of type 'wchar_t'. Both the regular
> character types and wchar_t fall under the common umbrella of
> "character type".
When I wrote "%s" directive, I meant "%s" directive.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-03-27 19:58 -0700 |
| Message-ID | <867dz589t3.fsf@linuxsc.com> |
| In reply to | #150153 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] > >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>> [...] >>> >>>>> A pointer to a string *is* required for a "%s" directive, but the >>>>> standard says so only indirectly. > > [...] > >> I need to add though that 'char' is not really accurate. The Standard >> says "character type" and I think it means that, not just 'char'. >> Furthermore if an 'l' length modifier is present then the array >> elements are assumed to be of type 'wchar_t'. Both the regular >> character types and wchar_t fall under the common umbrella of >> "character type". > > When I wrote "%s" directive, I meant "%s" directive. Sorry, I thought we were talking about things the Standard actually discusses. The Standard makes no statements about '"%s" directives', unless you want to count examples that happen to have a %s as part of a format string.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-03-27 23:26 -0700 |
| Message-ID | <875zepvvu1.fsf@nosuchdomain.example.com> |
| In reply to | #150867 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> [...]
>>
>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>> [...]
>>>>
>>>>>> A pointer to a string *is* required for a "%s" directive, but the
>>>>>> standard says so only indirectly.
>>
>> [...]
>>
>>> I need to add though that 'char' is not really accurate. The Standard
>>> says "character type" and I think it means that, not just 'char'.
You're right. (Note that that was in response to text that was later
snipped.) Still, I believe "pointer to a string" is correct, though the
elements of a string may be of type char, signed char, or unsigned char.
(It's possible the standard's definition of "character" leaves some
additional wiggle room.)
>>> Furthermore if an 'l' length modifier is present then the array
>>> elements are assumed to be of type 'wchar_t'. Both the regular
>>> character types and wchar_t fall under the common umbrella of
>>> "character type".
>>
>> When I wrote "%s" directive, I meant "%s" directive.
>
> Sorry, I thought we were talking about things the Standard
> actually discusses.
I don't know (and I'm not asking) why you thought that. If I were
talking about "things the Standard actually discusses", I wouldn't
have written "... but the standard says so only indirectly".
> The Standard makes no statements about
> '"%s" directives', unless you want to count examples that
> happen to have a %s as part of a format string.
My statement was precisely about a directive consisting only of
the character sequence "%s". If by 'a "%s" directive' I had meant
"a directive containing an 's' conversion specifier" you could
have rightly criticized me for being imprecise. I observed, as a
mildly interesting point, that the requirements for the argument
corresponding to a "%s" specifier are equivalent to requiring a
pointer to a string, though the standard doesn't state it in those
terms (and I do not suggest that it should).
Regarding a point I raised above, 3.7.1 defines a "character"
as a "bit representation that fits in a byte", and 7.1.1 defines
a "string" as a sequence of characters -- but "%s" specifically
requires a pointer to the initial element of an array of character
type, i.e., one of char, signed char, or unsigned char. I see
no requirement that a "character" must be of "character type".
Possibly the standard's definition of "character" is incomplete
and/or does not fully convey the intent.
An implementation could have an extended integer type (say, "_Byte")
with a size of 1 byte that is not a character type. A pointer value
of type _Byte* might meet the definition of "a pointer to a string",
but would not be valid as an argument corresponding to "%s". I doubt
that this is relevant for any real-world implementation, but my
original statement might not be correct for all possible conforming
implementations, assuming we take the standard's definitions literally.
Single-byte enums might also raise some issues (they could be
*compatible* with a character type without *being* a character type).
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 09:21 -0700 |
| Message-ID | <86sghl6eop.fsf@linuxsc.com> |
| In reply to | #150871 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> [...]
>>>
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> A pointer to a string *is* required for a "%s" directive, but the
>>>>>>> standard says so only indirectly.
>>>
>>> [...]
>>>
>>>> I need to add though that 'char' is not really accurate. The Standard
>>>> says "character type" and I think it means that, not just 'char'.
>
> You're right. (Note that that was in response to text that was later
> snipped.) Still, I believe "pointer to a string" is correct, though the
> elements of a string may be of type char, signed char, or unsigned char.
> (It's possible the standard's definition of "character" leaves some
> additional wiggle room.)
>
>>>> Furthermore if an 'l' length modifier is present then the array
>>>> elements are assumed to be of type 'wchar_t'. Both the regular
>>>> character types and wchar_t fall under the common umbrella of
>>>> "character type".
>>>
>>> When I wrote "%s" directive, I meant "%s" directive.
>>
>> Sorry, I thought we were talking about things the Standard
>> actually discusses.
>
> I don't know (and I'm not asking) why you thought that. If I were
> talking about "things the Standard actually discusses", I wouldn't
> have written "... but the standard says so only indirectly".
My original response to Lew Pitcher referred to "a %s conversion
specifier". Perhaps this came across as a '"%s" conversion
sequence' (which is also a directive), but I meant in particular
's' as a conversion specifier, not a conversion sequence. In
your responses to that you started using '"%s" directive', but
I didn't notice the change right away.
>> The Standard makes no statements about
>> '"%s" directives', unless you want to count examples that
>> happen to have a %s as part of a format string.
>
> My statement was precisely about a directive consisting only of
> the character sequence "%s". If by 'a "%s" directive' I had meant
> "a directive containing an 's' conversion specifier" you could
> have rightly criticized me for being imprecise. I observed, as a
> mildly interesting point, that the requirements for the argument
> corresponding to a "%s" specifier are equivalent to requiring a
> pointer to a string, though the standard doesn't state it in those
> terms (and I do not suggest that it should).
>
> Regarding a point I raised above, 3.7.1 defines a "character"
> as a "bit representation that fits in a byte", and 7.1.1 defines
> a "string" as a sequence of characters -- but "%s" specifically
> requires a pointer to the initial element of an array of character
> type, i.e., one of char, signed char, or unsigned char. I see
> no requirement that a "character" must be of "character type".
> Possibly the standard's definition of "character" is incomplete
> and/or does not fully convey the intent.
The term "character" is a restriction on values, not types. The
constant 's' is a character, but has type int.
> An implementation could have an extended integer type (say, "_Byte")
> with a size of 1 byte that is not a character type. A pointer value
> of type _Byte* might meet the definition of "a pointer to a string",
> but would not be valid as an argument corresponding to "%s". I doubt
> that this is relevant for any real-world implementation, but my
> original statement might not be correct for all possible conforming
> implementations, assuming we take the standard's definitions literally.
> Single-byte enums might also raise some issues (they could be
> *compatible* with a character type without *being* a character type).
Surely the definition in 7.1.1 is meant to refer to elements of
an array of character type. The array
int blah[4] = { 'a', 'b', 'c' };
is a sequence of characters, and terminated with a zero (which is
also a character value) but surely is not meant to be a "string"
in the sense of 7.1.1. For another example, the type uint8_t is a
single, 8-bit type, and may be a distinct type (more specifically,
not the same as char, unsigned char, or signed char). Because in
that situation uint8_t is not compatible with any character type,
a uint8_t * could have a different representation than a char *.
I haven't checked this, but I feel confident the Standard avoids
all of these problems by, eg, using parameter types such as 'char *'
so there is no question about what type is being referred to, or
by doing what is done for printf, namely, giving the specification
so it references "an array of character type".
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-02 09:54 -0700 |
| Message-ID | <61f8fb26-45fb-46c4-8bf4-d85d8fb94a8d@googlegroups.com> |
| In reply to | #150960 |
On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > > > Regarding a point I raised above, 3.7.1 defines a "character" > > as a "bit representation that fits in a byte", and 7.1.1 defines > > a "string" as a sequence of characters -- but "%s" specifically > > requires a pointer to the initial element of an array of character > > type, i.e., one of char, signed char, or unsigned char. I see > > no requirement that a "character" must be of "character type". > > Possibly the standard's definition of "character" is incomplete > > and/or does not fully convey the intent. > > The term "character" is a restriction on values, not types. The > constant 's' is a character, but has type int. > That's so that EOF can be coded as -1, and is not a "character". >. > I haven't checked this, but I feel confident the Standard avoids > all of these problems by, eg, using parameter types such as 'char *' > so there is no question about what type is being referred to, or > by doing what is done for printf, namely, giving the specification > so it references "an array of character type". > The "%s" format specifier can take char *, unsigned char *, or signed char *. That's quite a mouthful, so "array of character type" is used as shorthand.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-02 11:17 -0700 |
| Message-ID | <87r1x5sqfa.fsf@nosuchdomain.example.com> |
| In reply to | #150961 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote:
[...]
>> The term "character" is a restriction on values, not types. The
>> constant 's' is a character, but has type int.
>>
> That's so that EOF can be coded as -1, and is not a "character".
No, fgetc(), getc(), and getchar() return int so that EOF can be
coded as -1. Character constants are of type int for historical
reasons. In C++, 's' is of type char, but EOF is still -1.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-02 13:12 -0700 |
| Message-ID | <4ea45dd6-d0b6-4f24-a846-3b62d265f3ed@googlegroups.com> |
| In reply to | #150962 |
On Thursday, 2 April 2020 19:17:39 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > [...] > >> The term "character" is a restriction on values, not types. The > >> constant 's' is a character, but has type int. > >> > > That's so that EOF can be coded as -1, and is not a "character". > > No, fgetc(), getc(), and getchar() return int so that EOF can be > coded as -1. Character constants are of type int for historical > reasons. In C++, 's' is of type char, but EOF is still -1. > And functions like strchr() take an int as the character argument. It's a general principle in standard C that a single character variable is of type int.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-02 13:28 -0700 |
| Message-ID | <87eet5skd8.fsf@nosuchdomain.example.com> |
| In reply to | #150964 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Thursday, 2 April 2020 19:17:39 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> > On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote:
>> [...]
>> >> The term "character" is a restriction on values, not types. The
>> >> constant 's' is a character, but has type int.
>> >>
>> > That's so that EOF can be coded as -1, and is not a "character".
>>
>> No, fgetc(), getc(), and getchar() return int so that EOF can be
>> coded as -1. Character constants are of type int for historical
>> reasons. In C++, 's' is of type char, but EOF is still -1.
>>
> And functions like strchr() take an int as the character argument.
Yes.
> It's a general principle in standard C that a single character variable
> is of type int.
No, a single character variable is very often of type char if it doesn't
need to hold the value EOF.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 19:17 -0700 |
| Message-ID | <86a73tpb20.fsf@linuxsc.com> |
| In reply to | #150961 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > >>> Regarding a point I raised above, 3.7.1 defines a "character" >>> as a "bit representation that fits in a byte", and 7.1.1 defines >>> a "string" as a sequence of characters -- but "%s" specifically >>> requires a pointer to the initial element of an array of character >>> type, i.e., one of char, signed char, or unsigned char. I see >>> no requirement that a "character" must be of "character type". >>> Possibly the standard's definition of "character" is incomplete >>> and/or does not fully convey the intent. >> >> The term "character" is a restriction on values, not types. The >> constant 's' is a character, but has type int. > > That's so that EOF can be coded as -1, and is not a "character". > >> . >> I haven't checked this, but I feel confident the Standard avoids >> all of these problems by, eg, using parameter types such as 'char *' >> so there is no question about what type is being referred to, or >> by doing what is done for printf, namely, giving the specification >> so it references "an array of character type". > > The "%s" format specifier can take char *, unsigned char *, or signed char *. > That's quite a mouthful, so "array of character type" is used as shorthand. The depth of your understanding truly defies my ability to describe it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-03 09:47 +0200 |
| Message-ID | <r66pnf$g1k$1@dont-email.me> |
| In reply to | #150967 |
On 03/04/2020 04:17, Tim Rentsch wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: >> >>>> Regarding a point I raised above, 3.7.1 defines a "character" >>>> as a "bit representation that fits in a byte", and 7.1.1 defines >>>> a "string" as a sequence of characters -- but "%s" specifically >>>> requires a pointer to the initial element of an array of character >>>> type, i.e., one of char, signed char, or unsigned char. I see >>>> no requirement that a "character" must be of "character type". >>>> Possibly the standard's definition of "character" is incomplete >>>> and/or does not fully convey the intent. >>> >>> The term "character" is a restriction on values, not types. The >>> constant 's' is a character, but has type int. >> >> That's so that EOF can be coded as -1, and is not a "character". >> >>> . >>> I haven't checked this, but I feel confident the Standard avoids >>> all of these problems by, eg, using parameter types such as 'char *' >>> so there is no question about what type is being referred to, or >>> by doing what is done for printf, namely, giving the specification >>> so it references "an array of character type". >> >> The "%s" format specifier can take char *, unsigned char *, or signed char *. >> That's quite a mouthful, so "array of character type" is used as shorthand. > > The depth of your understanding truly defies my > ability to describe it. > And yet you cannot resist the urge to try. If you want to correct Malcolm, do so - plenty of people correct his posts, and he does not seem to mind. Sarcastic mockery from your ivory tower, on the other hand, is not helpful to anyone.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2020-04-03 08:03 -0700 |
| Message-ID | <2a770f28-0124-4b7e-8da3-24c05dd75636@googlegroups.com> |
| In reply to | #150973 |
On Friday, April 3, 2020 at 10:48:08 AM UTC+3, David Brown wrote: > On 03/04/2020 04:17, Tim Rentsch wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > >> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: > >> > >>>> Regarding a point I raised above, 3.7.1 defines a "character" > >>>> as a "bit representation that fits in a byte", and 7.1.1 defines > >>>> a "string" as a sequence of characters -- but "%s" specifically > >>>> requires a pointer to the initial element of an array of character > >>>> type, i.e., one of char, signed char, or unsigned char. I see > >>>> no requirement that a "character" must be of "character type". > >>>> Possibly the standard's definition of "character" is incomplete > >>>> and/or does not fully convey the intent. > >>> > >>> The term "character" is a restriction on values, not types. The > >>> constant 's' is a character, but has type int. > >> > >> That's so that EOF can be coded as -1, and is not a "character". > >> > >>> . > >>> I haven't checked this, but I feel confident the Standard avoids > >>> all of these problems by, eg, using parameter types such as 'char *' > >>> so there is no question about what type is being referred to, or > >>> by doing what is done for printf, namely, giving the specification > >>> so it references "an array of character type". > >> > >> The "%s" format specifier can take char *, unsigned char *, or signed char *. > >> That's quite a mouthful, so "array of character type" is used as shorthand. > > > > The depth of your understanding truly defies my > > ability to describe it. > > > > And yet you cannot resist the urge to try. If you want to correct > Malcolm, do so - plenty of people correct his posts, and he does not > seem to mind. Sarcastic mockery from your ivory tower, on the other > hand, is not helpful to anyone. The point is *not* to correct any specific mistake of Malcolm McLean> but to persuade him to stop taking part in discussions in-between High Priesthood. Which I consider not a bad advice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-03 17:34 +0200 |
| Message-ID | <r67l1c$v4t$1@dont-email.me> |
| In reply to | #150979 |
On 03/04/2020 17:03, already5chosen@yahoo.com wrote: > On Friday, April 3, 2020 at 10:48:08 AM UTC+3, David Brown wrote: >> On 03/04/2020 04:17, Tim Rentsch wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>>> On Thursday, 2 April 2020 17:22:11 UTC+1, Tim Rentsch wrote: >>>> >>>>>> Regarding a point I raised above, 3.7.1 defines a >>>>>> "character" as a "bit representation that fits in a byte", >>>>>> and 7.1.1 defines a "string" as a sequence of characters -- >>>>>> but "%s" specifically requires a pointer to the initial >>>>>> element of an array of character type, i.e., one of char, >>>>>> signed char, or unsigned char. I see no requirement that a >>>>>> "character" must be of "character type". Possibly the >>>>>> standard's definition of "character" is incomplete and/or >>>>>> does not fully convey the intent. >>>>> >>>>> The term "character" is a restriction on values, not types. >>>>> The constant 's' is a character, but has type int. >>>> >>>> That's so that EOF can be coded as -1, and is not a >>>> "character". >>>> >>>>> . I haven't checked this, but I feel confident the Standard >>>>> avoids all of these problems by, eg, using parameter types >>>>> such as 'char *' so there is no question about what type is >>>>> being referred to, or by doing what is done for printf, >>>>> namely, giving the specification so it references "an array >>>>> of character type". >>>> >>>> The "%s" format specifier can take char *, unsigned char *, or >>>> signed char *. That's quite a mouthful, so "array of character >>>> type" is used as shorthand. >>> >>> The depth of your understanding truly defies my ability to >>> describe it. >>> >> >> And yet you cannot resist the urge to try. If you want to correct >> Malcolm, do so - plenty of people correct his posts, and he does >> not seem to mind. Sarcastic mockery from your ivory tower, on the >> other hand, is not helpful to anyone. > > The point is *not* to correct any specific mistake of Malcolm McLean> > but to persuade him to stop taking part in discussions in-between > High Priesthood. Which I consider not a bad advice. > It is good advice for most people not to get involved in some of these discussions about the small details in the wording of the standards - the details are not easy to get right, and their influence in real-world practical programming is usually very small. (It can, however, be useful for the rest of us that /someone/ has read and understood them.) But do you think Tim was giving advice like that? Do you think Malcolm would take such advice, if it were clearly given? Do you think Tim made his post in the sincere belief that Malcolm might read it as such advice, and take the advice? Or do you think (as I) that the post was self-promotion through insult, fitting with Tim's "holier than thou" attitude to C and "I am the master, you are the student - I give hints and leave the rest as a homework exercise for my disciples" posting style? (These are clearly highly speculative and very leading questions, not intended to be answered.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-03 12:39 -0400 |
| Message-ID | <r67oso$smn$1@dont-email.me> |
| In reply to | #150980 |
On 4/3/20 11:34 AM, David Brown wrote: > On 03/04/2020 17:03, already5chosen@yahoo.com wrote: >> On Friday, April 3, 2020 at 10:48:08 AM UTC+3, David Brown wrote: ... >>> And yet you cannot resist the urge to try. If you want to correct >>> Malcolm, do so - plenty of people correct his posts, and he does >>> not seem to mind. Sarcastic mockery from your ivory tower, on the >>> other hand, is not helpful to anyone. I think that it probably does help Tim feel better about himself. >> The point is *not* to correct any specific mistake of Malcolm McLean> >> but to persuade him to stop taking part in discussions in-between >> High Priesthood. Which I consider not a bad advice. Nonsense - there's no "High Priesthood" of clc, and no one who should avoid participating in a conversation here just because of being "unworthy". There are other reasons why Malcolm shouldn't post, such as usually not making sense, and routinely using words and phrases with special Malcolm-meanings that are different from both conventional usage and the definitions of those terms as they are defined in the C standard. However, not being "worthy" to participate isn't one of those reasons. > But do you think Tim was giving advice like that? Do you think Malcolm > would take such advice, if it were clearly given? Do you think Tim made > his post in the sincere belief that Malcolm might read it as such > advice, and take the advice? Or do you think (as I) that the post was > self-promotion through insult, fitting with Tim's "holier than thou" > attitude to C and "I am the master, you are the student - I give hints > and leave the rest as a homework exercise for my disciples" posting style? You said what I was going to say, and you said it better than I was planning to.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-04-03 18:05 +0100 |
| Message-ID | <f1KhG.92394$Oi.36768@fx29.am4> |
| In reply to | #150980 |
On 03/04/2020 16:34, David Brown wrote: > On 03/04/2020 17:03, already5chosen@yahoo.com wrote: >> The point is *not* to correct any specific mistake of Malcolm McLean> >> but to persuade him to stop taking part in discussions in-between >> High Priesthood. Which I consider not a bad advice. >> > > It is good advice for most people not to get involved in some of these > discussions about the small details in the wording of the standards - > the details are not easy to get right, and their influence in real-world > practical programming is usually very small. (It can, however, be > useful for the rest of us that /someone/ has read and understood them.) Or, possibly, not understand them. It's useful to know that even 'high priests' can't agree about some of that stuff.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-03 10:18 -0700 |
| Message-ID | <5f11e9cb-67df-4c87-bab1-c7272ccf3ebc@googlegroups.com> |
| In reply to | #150984 |
On Friday, 3 April 2020 18:05:26 UTC+1, Bart wrote: > On 03/04/2020 16:34, David Brown wrote: > > On 03/04/2020 17:03, already5chosen@yahoo.com wrote: > > >> The point is *not* to correct any specific mistake of Malcolm McLean> > >> but to persuade him to stop taking part in discussions in-between > >> High Priesthood. Which I consider not a bad advice. > >> > > > > It is good advice for most people not to get involved in some of these > > discussions about the small details in the wording of the standards - > > the details are not easy to get right, and their influence in real-world > > practical programming is usually very small. (It can, however, be > > useful for the rest of us that /someone/ has read and understood them.) > > Or, possibly, not understand them. > > It's useful to know that even 'high priests' can't agree about some of > that stuff. > With the "day one" versus "the first day" argument in Genesis, you can argue that God guided the hand of the scribe to make him write something significant. Some people believe that the text was dictated verbatim to Moses on Mt Sinai. But when it's "character" in the C standard, we know that this a purely human document. Doubtless I'll be accused of inventing "Malcolm-characters" just I was accused of inventing "Malcolm functions" (a "Malcolm function" is a mapping of input bits to output bits, so I'm not too unhappy to have this concept named after me). "Character" can mean several things, one of which, in the context of C, is the full word for the abbreviation "char". But that's only one meaning. Characters are usually passed about as ints. Early C didn't have any prototypes, so there were problems specifying functions which took the non-register or non-double types. The other reason was to encode EOF.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-04-03 22:13 +0100 |
| Message-ID | <874ku09ssw.fsf@bsb.me.uk> |
| In reply to | #150985 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > ... I was accused of inventing "Malcolm functions" (a "Malcolm function" is > a mapping of input bits to output bits, Is it? I thought a key feature of Malcolm-functions is that they don't do input or output. Or do you mean Malcolm-input and Malcolm-output? > so I'm not too unhappy to have this concept named after me). Only in comp.lang.c. You would have to use "function" to mean "a formal celebratory gathering" in sci.math for that meaning to be named after you there. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-03 14:36 -0700 |
| Message-ID | <6bf35dde-de1f-4635-a69d-4d4860d84a29@googlegroups.com> |
| In reply to | #150998 |
On Friday, 3 April 2020 22:13:28 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > ... I was accused of inventing "Malcolm functions" (a "Malcolm function" is > > a mapping of input bits to output bits, > > Is it? I thought a key feature of Malcolm-functions is that they don't > do input or output. Or do you mean Malcolm-input and Malcolm-output? > Really the key feature is that they are not specified to do IO in the interface description. So you can always eliminate the IO whilst maintaining correct behaviour for a compliant caller. That's not just a quibble, often you want to add white box diagnostics to a Malcolm function to debug it. So yes, Malcolm-input and Malcolm-output. The key reason for defining the Malcolm function is not to teach people what the word "function" normally means outside of C, but to separate the portions of the program which are inherently portable and (except for running out of memory) failure free, from those which are inherently hardware bound and can fail if the device they are attached to fails. > > > so I'm not too unhappy to have this concept named after me). > > Only in comp.lang.c. You would have to use "function" to mean "a formal > celebratory gathering" in sci.math for that meaning to be named after > you there. > If I distinguished "function" from "workction" then I might get "Malcolm function" named after me, even on sci.math. But only if I actually held one, and currently we're on lockdown so that's not going to happen.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web