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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-04-04 10:24 +0000 |
| Subject | Re: Jared Kushner would be proud... (Was: C String terminator) |
| Message-ID | <slrnr8go36.1r7q.grahn+nntp@frailea.sa.invalid> |
| In reply to | #151007 |
On Sat, 2020-04-04, Malcolm McLean wrote: > On Saturday, 4 April 2020 10:00:30 UTC+1, Kenny McCormack wrote: >> In article <r6902g$bl6$1@dont-email.me>, >> James Kuyper <jameskuyper@alumni.caltech.edu> babbled: >> ... >> >The phrase "High Priests" carries the implication that we claim >> >authority based upon divine endorsement. As someone who doesn't even >> >believe in Divinities, I find the suggestion that I'm making such a >> >claim quite disgusting. What I say is true, if it is true, only because ... > It's a rather literal interpretation of a metaphor. How about this, then? "High priest" implies - Member of a closed group without transparency. - Appointed by some unknown external authority. - Controls the interpretation of the (divine) law. (If you read the New Testament, high priests can also get you crucified.) There's not really any other way to interpret it. You can criticize someone for caring too much about what the standard says, but that would be "biblicism" or something -- that's orthogonal to priesthood. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-04 03:55 -0700 |
| Subject | Re: Jared Kushner would be proud... (Was: C String terminator) |
| Message-ID | <6c870890-6035-4272-bfcc-6d914ba969f3@googlegroups.com> |
| In reply to | #151008 |
On Saturday, 4 April 2020 11:24:48 UTC+1, Jorgen Grahn wrote:
> On Sat, 2020-04-04, Malcolm McLean wrote:
> > On Saturday, 4 April 2020 10:00:30 UTC+1, Kenny McCormack wrote:
> >> In article <r6902g$bl6$1@dont-email.me>,
> >> James Kuyper <jameskuyper@alumni.caltech.edu> babbled:
> >> ...
> >> >The phrase "High Priests" carries the implication that we claim
> >> >authority based upon divine endorsement. As someone who doesn't even
> >> >believe in Divinities, I find the suggestion that I'm making such a
> >> >claim quite disgusting. What I say is true, if it is true, only because
> ...
>
> > It's a rather literal interpretation of a metaphor.
>
> How about this, then? "High priest" implies
>
> - Member of a closed group without transparency.
> - Appointed by some unknown external authority.
> - Controls the interpretation of the (divine) law.
>
> (If you read the New Testament, high priests can also get you crucified.)
>
> There's not really any other way to interpret it. You can criticize
> someone for caring too much about what the standard says, but that
> would be "biblicism" or something -- that's orthogonal to priesthood.
>
It also implies discussion about fine, almost meaningless points.
For instance, since the standard uses the term "array of character type"
(and defines "character type", which I wasn't aware of) what is the
status of this program?
#include <stdio.h>
int main(void)
{
printf("***%.*s***\n", 0, (void *) 0);
return 0;
}
But is there actually an answer in the standard, as opposed to a knowledge
of how C implementations work?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-04 13:27 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <87r1x3ov2a.fsf@nosuchdomain.example.com> |
| In reply to | #151009 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> It also implies discussion about fine, almost meaningless points.
> For instance, since the standard uses the term "array of character type"
> (and defines "character type", which I wasn't aware of) what is the
> status of this program?
>
> #include <stdio.h>
>
> int main(void)
> {
> printf("***%.*s***\n", 0, (void *) 0);
>
> return 0;
> }
>
> But is there actually an answer in the standard, as opposed to a
> knowledge of how C implementations work?
I don't know why you think this is a good example of whatever
point you're trying to make. Yes, there is actually an answer in
the standard. The description of the "s" conversion specifier says:
If no l length modifier is present, the argument shall be a
pointer to the initial element of an array of character type.
(void*)0, even if interpreted as a value of type char*, clearly is
not a pointer to the initial element of an array. The violation
of a "shall" outside a constraint means the program has undefined
behavior.
It's likely that an actual implementation would not dereference
the pointer and the program's output would be "******" followed
by a newline. That is, as you know, entirely consistent with
undefined behavior.
This is why you shouldn't pass a null pointer corresponding to a
"%...s" directive (where "..." is any, possibly empty, sequence of
characters that are valid in that context).
The standard *could* have said that it's permissible to pass a null
pointer if none of the characters are used, but that would have
made the standard more complicated with no real benefit. As it is,
an implementation that calls abort() if it's passed a null pointer
in that context could be conforming.
What was your point again?
--
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-04 13:52 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <3387ce6c-e0b7-4e05-9205-76126f18b5eb@googlegroups.com> |
| In reply to | #151018 |
On Saturday, 4 April 2020 21:27:54 UTC+1, Keith Thompson wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
> > It also implies discussion about fine, almost meaningless points.
> > For instance, since the standard uses the term "array of character type"
> > (and defines "character type", which I wasn't aware of) what is the
> > status of this program?
> >
> > #include <stdio.h>
> >
> > int main(void)
> > {
> > printf("***%.*s***\n", 0, (void *) 0);
> >
> > return 0;
> > }
> >
> > But is there actually an answer in the standard, as opposed to a
> > knowledge of how C implementations work?
>
> I don't know why you think this is a good example of whatever
> point you're trying to make. Yes, there is actually an answer in
> the standard. The description of the "s" conversion specifier says:
>
> If no l length modifier is present, the argument shall be a
> pointer to the initial element of an array of character type.
>
> (void*)0, even if interpreted as a value of type char*, clearly is
> not a pointer to the initial element of an array. The violation
> of a "shall" outside a constraint means the program has undefined
> behavior.
>
> It's likely that an actual implementation would not dereference
> the pointer and the program's output would be "******" followed
> by a newline. That is, as you know, entirely consistent with
> undefined behavior.
>
> This is why you shouldn't pass a null pointer corresponding to a
> "%...s" directive (where "..." is any, possibly empty, sequence of
> characters that are valid in that context).
>
> The standard *could* have said that it's permissible to pass a null
> pointer if none of the characters are used, but that would have
> made the standard more complicated with no real benefit. As it is,
> an implementation that calls abort() if it's passed a null pointer
> in that context could be conforming.
>
> What was your point again?
>
Are you sure the implementation is allowed to call abort() if the char *
argument is null and the character count is zero? Or did you just take
that decision on your own authority?
I'm not saying you are wrong. I'm saying it's a marginal case that isn't
covered, as far as I can tell.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-04 14:12 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <2c5287a7-1c18-4057-a5ae-8c0bdfcb6b45@googlegroups.com> |
| In reply to | #151020 |
On Saturday, 4 April 2020 21:52:27 UTC+1, Malcolm McLean wrote:
> On Saturday, 4 April 2020 21:27:54 UTC+1, Keith Thompson wrote:
> > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> > [...]
> > > It also implies discussion about fine, almost meaningless points.
> > > For instance, since the standard uses the term "array of character type"
> > > (and defines "character type", which I wasn't aware of) what is the
> > > status of this program?
> > >
> > > #include <stdio.h>
> > >
> > > int main(void)
> > > {
> > > printf("***%.*s***\n", 0, (void *) 0);
> > >
> > > return 0;
> > > }
> > >
> > > But is there actually an answer in the standard, as opposed to a
> > > knowledge of how C implementations work?
> >
> > I don't know why you think this is a good example of whatever
> > point you're trying to make. Yes, there is actually an answer in
> > the standard. The description of the "s" conversion specifier says:
> >
> > If no l length modifier is present, the argument shall be a
> > pointer to the initial element of an array of character type.
> >
> > (void*)0, even if interpreted as a value of type char*, clearly is
> > not a pointer to the initial element of an array. The violation
> > of a "shall" outside a constraint means the program has undefined
> > behavior.
> >
> > It's likely that an actual implementation would not dereference
> > the pointer and the program's output would be "******" followed
> > by a newline. That is, as you know, entirely consistent with
> > undefined behavior.
> >
> > This is why you shouldn't pass a null pointer corresponding to a
> > "%...s" directive (where "..." is any, possibly empty, sequence of
> > characters that are valid in that context).
> >
> > The standard *could* have said that it's permissible to pass a null
> > pointer if none of the characters are used, but that would have
> > made the standard more complicated with no real benefit. As it is,
> > an implementation that calls abort() if it's passed a null pointer
> > in that context could be conforming.
> >
> > What was your point again?
> >
>
> Are you sure the implementation is allowed to call abort() if the char *
> argument is null and the character count is zero? Or did you just take
> that decision on your own authority?
>
> I'm not saying you are wrong. I'm saying it's a marginal case that isn't
> covered, as far as I can tell.
>
Note that if you are right, then this code can fail.
void writeN(char *str, int N)
{
char *buff = malloc(N);
if(N > 0 && buff == 0)
return;
for (int i=0;i<N;i++)
buff[i] = tolower(str[i]); /* just make buff meaningful */
printf("lowercase %.*s", N, buff);
free(buff);
}
if N is zero and malloc() returns null for a zero allocation, then the
abort() will be triggered. I doubt that is the intention.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-04 15:12 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <87imieq4rz.fsf@nosuchdomain.example.com> |
| In reply to | #151023 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Note that if you are right, then this code can fail.
>
> void writeN(char *str, int N)
> {
> char *buff = malloc(N);
>
> if(N > 0 && buff == 0)
> return;
>
> for (int i=0;i<N;i++)
> buff[i] = tolower(str[i]); /* just make buff meaningful */
>
> printf("lowercase %.*s", N, buff);
>
> free(buff);
> }
>
> if N is zero and malloc() returns null for a zero allocation, then the
> abort() will be triggered.
Yes, assuming that printf calls abort() if buff is a null pointer.
(I suggested that a conforming implementation could do that, not
that any implementation does or should.)
> I doubt that is the intention.
I'm sure it is, perhaps implicitly. (I don't know whether the
committee members thought about cases like this.) The standard does
not add a special-case rule to let you safely pass a null pointer
in that context. You cannot safely treat a null pointer as if it
were a pointer to an effectively empty array.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-04 15:03 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <87mu7qq57a.fsf@nosuchdomain.example.com> |
| In reply to | #151020 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 4 April 2020 21:27:54 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>> > It also implies discussion about fine, almost meaningless points.
>> > For instance, since the standard uses the term "array of character type"
>> > (and defines "character type", which I wasn't aware of) what is the
>> > status of this program?
>> >
>> > #include <stdio.h>
>> >
>> > int main(void)
>> > {
>> > printf("***%.*s***\n", 0, (void *) 0);
>> >
>> > return 0;
>> > }
>> >
>> > But is there actually an answer in the standard, as opposed to a
>> > knowledge of how C implementations work?
>>
>> I don't know why you think this is a good example of whatever
>> point you're trying to make. Yes, there is actually an answer in
>> the standard. The description of the "s" conversion specifier says:
>>
>> If no l length modifier is present, the argument shall be a
>> pointer to the initial element of an array of character type.
>>
>> (void*)0, even if interpreted as a value of type char*, clearly is
>> not a pointer to the initial element of an array. The violation
>> of a "shall" outside a constraint means the program has undefined
>> behavior.
>>
>> It's likely that an actual implementation would not dereference
>> the pointer and the program's output would be "******" followed
>> by a newline. That is, as you know, entirely consistent with
>> undefined behavior.
>>
>> This is why you shouldn't pass a null pointer corresponding to a
>> "%...s" directive (where "..." is any, possibly empty, sequence of
>> characters that are valid in that context).
>>
>> The standard *could* have said that it's permissible to pass a null
>> pointer if none of the characters are used, but that would have
>> made the standard more complicated with no real benefit. As it is,
>> an implementation that calls abort() if it's passed a null pointer
>> in that context could be conforming.
>>
>> What was your point again?
>
> Are you sure the implementation is allowed to call abort() if the char *
> argument is null and the character count is zero? Or did you just take
> that decision on your own authority?
>
> I'm not saying you are wrong. I'm saying it's a marginal case that isn't
> covered, as far as I can tell.
The behavior is undefined. I cited the wording from the standard that
says so. If you disagree, please explain why.
Again, the standard says that "the argument shall be a pointer to
the initial element of an array of character type". (void*)0 is
not a pointer to the initial element of an array of character type.
The fact that the standard doesn't have extra wording stating
an exception when the pointer needn't be dereferenced means that
that corner case *is* covered. Violation of a "shall" outside a
constraint implies undefined behavior (section 4 paragraph 2).
I presume you agree that calling abort() for a program with undefined
behavior is conforming. If not, please explain why.
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-04-04 18:46 -0400 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <r78iG.185330$Bz7.60027@fx24.iad> |
| In reply to | #151020 |
On 4/4/20 4:52 PM, Malcolm McLean wrote:
> On Saturday, 4 April 2020 21:27:54 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>>> It also implies discussion about fine, almost meaningless points.
>>> For instance, since the standard uses the term "array of character type"
>>> (and defines "character type", which I wasn't aware of) what is the
>>> status of this program?
>>>
>>> #include <stdio.h>
>>>
>>> int main(void)
>>> {
>>> printf("***%.*s***\n", 0, (void *) 0);
>>>
>>> return 0;
>>> }
>>>
>>> But is there actually an answer in the standard, as opposed to a
>>> knowledge of how C implementations work?
>>
>> I don't know why you think this is a good example of whatever
>> point you're trying to make. Yes, there is actually an answer in
>> the standard. The description of the "s" conversion specifier says:
>>
>> If no l length modifier is present, the argument shall be a
>> pointer to the initial element of an array of character type.
>>
>> (void*)0, even if interpreted as a value of type char*, clearly is
>> not a pointer to the initial element of an array. The violation
>> of a "shall" outside a constraint means the program has undefined
>> behavior.
>>
>> It's likely that an actual implementation would not dereference
>> the pointer and the program's output would be "******" followed
>> by a newline. That is, as you know, entirely consistent with
>> undefined behavior.
>>
>> This is why you shouldn't pass a null pointer corresponding to a
>> "%...s" directive (where "..." is any, possibly empty, sequence of
>> characters that are valid in that context).
>>
>> The standard *could* have said that it's permissible to pass a null
>> pointer if none of the characters are used, but that would have
>> made the standard more complicated with no real benefit. As it is,
>> an implementation that calls abort() if it's passed a null pointer
>> in that context could be conforming.
>>
>> What was your point again?
>>
>
> Are you sure the implementation is allowed to call abort() if the char *
> argument is null and the character count is zero? Or did you just take
> that decision on your own authority?
>
> I'm not saying you are wrong. I'm saying it's a marginal case that isn't
> covered, as far as I can tell.
>
Since the Standard (explicitly) says that it is undefined behavior if
the argument is not a pointer to the initial element of an array (as the
NULL pointer doesn't point to any object), then yes, the Standard is
clear on this. And I could actually see a library written defensively
(trying to catch as many undefined behaviors and turning them into some
explicit error condition rather than doing some critical undefined
behavior), catching this, as at the begining of the %s processing, it
might have an assert that the pointer is not null, before checking if
the max width was set to 0.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-05 01:53 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <5f6047c2-d0a6-489c-9d45-a1db8cfb0150@googlegroups.com> |
| In reply to | #151032 |
On Saturday, 4 April 2020 23:46:55 UTC+1, Richard Damon wrote:
> On 4/4/20 4:52 PM, Malcolm McLean wrote:
> > On Saturday, 4 April 2020 21:27:54 UTC+1, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >> [...]
> >>> It also implies discussion about fine, almost meaningless points.
> >>> For instance, since the standard uses the term "array of character type"
> >>> (and defines "character type", which I wasn't aware of) what is the
> >>> status of this program?
> >>>
> >>> #include <stdio.h>
> >>>
> >>> int main(void)
> >>> {
> >>> printf("***%.*s***\n", 0, (void *) 0);
> >>>
> >>> return 0;
> >>> }
> >>>
> >>> But is there actually an answer in the standard, as opposed to a
> >>> knowledge of how C implementations work?
> >>
> >> I don't know why you think this is a good example of whatever
> >> point you're trying to make. Yes, there is actually an answer in
> >> the standard. The description of the "s" conversion specifier says:
> >>
> >> If no l length modifier is present, the argument shall be a
> >> pointer to the initial element of an array of character type.
> >>
> >> (void*)0, even if interpreted as a value of type char*, clearly is
> >> not a pointer to the initial element of an array. The violation
> >> of a "shall" outside a constraint means the program has undefined
> >> behavior.
> >>
> >> It's likely that an actual implementation would not dereference
> >> the pointer and the program's output would be "******" followed
> >> by a newline. That is, as you know, entirely consistent with
> >> undefined behavior.
> >>
> >> This is why you shouldn't pass a null pointer corresponding to a
> >> "%...s" directive (where "..." is any, possibly empty, sequence of
> >> characters that are valid in that context).
> >>
> >> The standard *could* have said that it's permissible to pass a null
> >> pointer if none of the characters are used, but that would have
> >> made the standard more complicated with no real benefit. As it is,
> >> an implementation that calls abort() if it's passed a null pointer
> >> in that context could be conforming.
> >>
> >> What was your point again?
> >>
> >
> > Are you sure the implementation is allowed to call abort() if the char *
> > argument is null and the character count is zero? Or did you just take
> > that decision on your own authority?
> >
> > I'm not saying you are wrong. I'm saying it's a marginal case that isn't
> > covered, as far as I can tell.
> >
>
> Since the Standard (explicitly) says that it is undefined behavior if
> the argument is not a pointer to the initial element of an array (as the
> NULL pointer doesn't point to any object), then yes, the Standard is
> clear on this. And I could actually see a library written defensively
> (trying to catch as many undefined behaviors and turning them into some
> explicit error condition rather than doing some critical undefined
> behavior), catching this, as at the begining of the %s processing, it
> might have an assert that the pointer is not null, before checking if
> the max width was set to 0.
>
It's worse than that, and Keith's inerpretation is right.
The relevant section is actually buried away soemwhere in the preamble
to "functions" where it says that a pinter shall be "valid", and null
is not "valid". Even in N is 0.
So this is a disaster. memcpy() does not handle the null case properly.
Consider. It is very likely that in real code, N can be zero, but such
cases are exceptional and very rare.
It is also likely that the buffers are allocated by a call to malloc().
It is also quite likely that malloc(0) returns non-null.
It is also quite likely that on the platform the code is tested on,
memcpy() does handle memcpy(0, 0, 0) as a no-op.
So this is asking for bugs to slip through and only be detected at
a late stage.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-05 02:33 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <87eet2p98l.fsf@nosuchdomain.example.com> |
| In reply to | #151050 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Saturday, 4 April 2020 23:46:55 UTC+1, Richard Damon wrote:
>> On 4/4/20 4:52 PM, Malcolm McLean wrote:
>> > On Saturday, 4 April 2020 21:27:54 UTC+1, Keith Thompson wrote:
>> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> >> [...]
>> >>> It also implies discussion about fine, almost meaningless points.
>> >>> For instance, since the standard uses the term "array of character type"
>> >>> (and defines "character type", which I wasn't aware of) what is the
>> >>> status of this program?
>> >>>
>> >>> #include <stdio.h>
>> >>>
>> >>> int main(void)
>> >>> {
>> >>> printf("***%.*s***\n", 0, (void *) 0);
>> >>>
>> >>> return 0;
>> >>> }
>> >>>
>> >>> But is there actually an answer in the standard, as opposed to a
>> >>> knowledge of how C implementations work?
>> >>
>> >> I don't know why you think this is a good example of whatever
>> >> point you're trying to make. Yes, there is actually an answer in
>> >> the standard. The description of the "s" conversion specifier says:
>> >>
>> >> If no l length modifier is present, the argument shall be a
>> >> pointer to the initial element of an array of character type.
>> >>
>> >> (void*)0, even if interpreted as a value of type char*, clearly is
>> >> not a pointer to the initial element of an array. The violation
>> >> of a "shall" outside a constraint means the program has undefined
>> >> behavior.
>> >>
>> >> It's likely that an actual implementation would not dereference
>> >> the pointer and the program's output would be "******" followed
>> >> by a newline. That is, as you know, entirely consistent with
>> >> undefined behavior.
>> >>
>> >> This is why you shouldn't pass a null pointer corresponding to a
>> >> "%...s" directive (where "..." is any, possibly empty, sequence of
>> >> characters that are valid in that context).
>> >>
>> >> The standard *could* have said that it's permissible to pass a null
>> >> pointer if none of the characters are used, but that would have
>> >> made the standard more complicated with no real benefit. As it is,
>> >> an implementation that calls abort() if it's passed a null pointer
>> >> in that context could be conforming.
>> >>
>> >> What was your point again?
>> >
>> > Are you sure the implementation is allowed to call abort() if the char *
>> > argument is null and the character count is zero? Or did you just take
>> > that decision on your own authority?
>> >
>> > I'm not saying you are wrong. I'm saying it's a marginal case that isn't
>> > covered, as far as I can tell.
>>
>> Since the Standard (explicitly) says that it is undefined behavior if
>> the argument is not a pointer to the initial element of an array (as the
>> NULL pointer doesn't point to any object), then yes, the Standard is
>> clear on this. And I could actually see a library written defensively
>> (trying to catch as many undefined behaviors and turning them into some
>> explicit error condition rather than doing some critical undefined
>> behavior), catching this, as at the begining of the %s processing, it
>> might have an assert that the pointer is not null, before checking if
>> the max width was set to 0.
>>
> It's worse than that, and Keith's inerpretation is right.
Thank you, but I don't see what's "worse" about it.
> The relevant section is actually buried away soemwhere in the preamble
> to "functions" where it says that a pinter shall be "valid", and null
> is not "valid". Even in N is 0.
The relevant section is the one I cited, the one that says "the argument
shall be a pointer to the initial element of an array of character
type".
I think you're referring to 7.1.4 (Use of library functions) which says
that if an argument to a function (here it's referring to library
functions, not to user-defined functions) has an invalid value the
behavior is undefined. But there's no need to resort to that, since the
undefinedness of passing a null pointer to printf is specified in the
description of printf itself. (Actually fprintf; printf is defined in
terms of fprintf. And actually just in this particular context;
printf("%p", (void*)0) is perfectly valid).
> So this is a disaster. memcpy() does not handle the null case properly.
How is that a disaster? Just don't call memcpy with a null pointer.
In fact it's not possible in general for memcpy to determine whether
a pointer passed to it is valid. It might be uninitialized, or
it might point to memory that's been deallocated, or it might just
point to the wrong object. The standard *could* have required some
kind of checking for null pointers (which would do what if the check
fails?), but since invalid pointers in general are not detectable,
there wouldn't have been much point.
> Consider. It is very likely that in real code, N can be zero, but such
> cases are exceptional and very rare.
> It is also likely that the buffers are allocated by a call to malloc().
> It is also quite likely that malloc(0) returns non-null.
>
> It is also quite likely that on the platform the code is tested on,
> memcpy() does handle memcpy(0, 0, 0) as a no-op.
>
> So this is asking for bugs to slip through and only be detected at
> a late stage.
The fact that malloc(0) might return either a null pointer or a valid
pointer that can't be safely dereferenced is, I'll agree, a bit of a
problem. I think it's defined that way because existing pre-standard
implementations behaved both ways.
https://www.lysator.liu.se/c/rat/d10.html#4-10-3
But really, it's not that big a deal. Don't assume that malloc(0) will
return a non-null pointer, don't assume malloc() always succeeds, and
don't pass null pointers to functions that aren't prepared for them.
You can certainly shoot yourself in the foot with C. You seem to be
complaining that it doesn't provide Kevlar over your left big toenail.
The trick is to avoid shooting yourself in the foot in the first place,
by understanding the rules of the gun and being careful. (And yes, it
is tricky.)
Have you run into the problems you're worried about in real code?
Have you actually written something similar to
printf("***%.*s***\n", 0, (void *) 0);
It looks to me like a contrived example, one that you presented as a
"meaningless point".
--
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-05 06:43 -0700 |
| Subject | Re: Jared Kushner would be proud... |
| Message-ID | <7b598fd0-0272-4d1d-9177-c7f4987aa69f@googlegroups.com> |
| In reply to | #151055 |
On Sunday, 5 April 2020 10:33:59 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > > So this is a disaster. memcpy() does not handle the null case properly. > > How is that a disaster? Just don't call memcpy with a null pointer. > I'm starting a new thread on this.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-04 19:48 -0700 |
| Subject | Re: Jared Kushner would be proud... (Was: C String terminator) |
| Message-ID | <86369iodfd.fsf@linuxsc.com> |
| In reply to | #151008 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Sat, 2020-04-04, Malcolm McLean wrote: > >> On Saturday, 4 April 2020 10:00:30 UTC+1, Kenny McCormack wrote: >> >>> In article <r6902g$bl6$1@dont-email.me>, >>> James Kuyper <jameskuyper@alumni.caltech.edu> babbled: >>> ... >>> >>>> The phrase "High Priests" carries the implication that we claim >>>> authority based upon divine endorsement. As someone who doesn't even >>>> believe in Divinities, I find the suggestion that I'm making such a >>>> claim quite disgusting. What I say is true, if it is true, only because > > ... > >> It's a rather literal interpretation of a metaphor. > > How about this, then? "High priest" implies > > - Member of a closed group without transparency. > - Appointed by some unknown external authority. > - Controls the interpretation of the (divine) law. > > [...] > > There's not really any other way to interpret it. [...] In English (American English, if it's important to be careful), the phrase "high priest" has a common meaning (among several others) that might be expressed as "an acknowledged leader in a particular field", and not necessarily requiring the three attributes you listed, and certainly not needing any relation to any aspect of divinity. This meaning is how I understood the phrase when I read it in the posting upthread, and that understanding has now been reinforced by entries in several online dictionaries. The phrase might be called an idiom or a metaphor, but in any case I don't think there anything wrong either with how it was used or how Malcolm understood it (by which I mean how I think Malcolm understood it, in case that needs saying).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-04 06:37 -0700 |
| Subject | Re: Jared Kushner would be proud... (Was: C String terminator) |
| Message-ID | <0432db50-adc6-4135-86f3-09ec707b6b42@googlegroups.com> |
| In reply to | #151007 |
On Saturday, April 4, 2020 at 5:45:44 AM UTC-4, Malcolm McLean wrote: > On Saturday, 4 April 2020 10:00:30 UTC+1, Kenny McCormack wrote: > > In article <r6902g$bl6$1@dont-email.me>, > > James Kuyper <jameskuyper@alumni.caltech.edu> babbled: > > ... > > >The phrase "High Priests" carries the implication that we claim > > >authority based upon divine endorsement. As someone who doesn't even > > >believe in Divinities, I find the suggestion that I'm making such a > > >claim quite disgusting. What I say is true, if it is true, only because > > >(and therefore, only insofar as) it accurately reflects what the > > >standard says. And the standard doesn't have authority because it is a > > >infallible Holy Book containing the word of God. It is a somewhat > > >fallible document that has authority only because fallible human beings > > >created ISO and gave ISO the authority to create international > > >standards, and ISO in turn gave the fallible committee the authority to > > >produce an international C standard. ... > It's a rather literal interpretation of a metaphor. What does that metaphor mean to you? If it's not intended to imply a claim of divine endorsement, why not use a term like "experts" rather than "High Priests"?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-04 18:36 +0200 |
| Message-ID | <r6ad28$bg6$1@dont-email.me> |
| In reply to | #151003 |
On 04/04/2020 05:48, James Kuyper wrote: > On 4/3/20 3:59 PM, David Brown wrote: > ... >> (I know that the people who know more details of the C standards than >> others in this group don't like to be thought of as "High priests" - the >> phrase has less flattering implications. I prefer to think of them as >> knowledgeable people who are happy to share that knowledge.) > > The phrase "High Priests" carries the implication that we claim > authority based upon divine endorsement. As someone who doesn't even > believe in Divinities, I find the suggestion that I'm making such a > claim quite disgusting. What I say is true, if it is true, only because > (and therefore, only insofar as) it accurately reflects what the > standard says. And the standard doesn't have authority because it is a > infallible Holy Book containing the word of God. It is a somewhat > fallible document that has authority only because fallible human beings > created ISO and gave ISO the authority to create international > standards, and ISO in turn gave the fallible committee the authority to > produce an international C standard. > I was actually thinking that the label "High priest" implies someone who thinks they are above other people, and in possession of special knowledge that they keep secret. And that, of course, is precisely what you (and Keith, and Ben, and other experts here) do /not/ do - you folks willingly share your knowledge (and occasional ignorance or mistakes). So to me at least, you are no "High priest" - you are a nice, helpful guy from whom I have learned a good deal.
[toc] | [prev] | [next] | [standalone]
| From | dave_thompson_2@comcast.net |
|---|---|
| Date | 2020-05-02 15:13 -0400 |
| Message-ID | <cihraf126m6d8540eqfn13bos6a6ibhvfn@4ax.com> |
| In reply to | #151003 |
On Fri, 3 Apr 2020 23:48:31 -0400, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > ... And the standard doesn't have authority because it is a > infallible Holy Book containing the word of God. It is a somewhat > fallible document that has authority only because fallible human beings > created ISO and gave ISO the authority to create international > standards, and ISO in turn gave the fallible committee the authority to > produce an international C standard. ISO _and_ IEC. Everyone always forgets IEC. I probably would too, if it weren't so darn much fun to say 'electrotechnical'. electro-TECH-nical electro-TECH-ni-CAL e-LEC-tro-TECH-ni-CAL I'll go get my meds. :)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2020-04-03 09:41 -0700 |
| Message-ID | <f08c4997-fc32-4958-a23b-13e15ca93410@googlegroups.com> |
| In reply to | #150979 |
On Friday, 3 April 2020 16:04:03 UTC+1, already...@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 a kind of theological nonsense discussion, I agree. So I make a few pertinent points. Characters are passed about as ints in standard C, partly so that EOF can be encoded as -1, enabling all 8 bits of a char to be used for data encoding. "char" is still the ASCII character type, and the term "character" can be used in several senses, one of which is the full word for "char". Hence "array of character type", meaning "array of chars or derived types". Of course the term "character" can also mean "8 bit value or EOF" as in "the function fgetc extracts a character from the file". It can also mean "a glyph", thus not a space, or it can mean "not a control code", or "any 8 bit value except zero". It all depends on context and to try to read anything more into the standard is a bit like the school of Biblical interpretation that puts great weight on the difference between "the first day" and "day one".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-03 10:33 -0700 |
| Message-ID | <87wo6wqxs5.fsf@nosuchdomain.example.com> |
| In reply to | #150983 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> It is a kind of theological nonsense discussion, I agree. So I make a
> few pertinent points.
>
> Characters are passed about as ints in standard C, partly so that EOF can
> be encoded as -1, enabling all 8 bits of a char to be used for data encoding.
> "char" is still the ASCII character type, and the term "character" can be
> used in several senses, one of which is the full word for "char". Hence
> "array of character type", meaning "array of chars or derived types".
What do you mean by "derived types"? In the C standard, that phrase
refers specifically to array, structure, union, function, pointer, and
atomic types. signed char and unsigned char, in particular, are not
derived types.
> Of course the term "character" can also mean "8 bit value or EOF" as in
> "the function fgetc extracts a character from the file". It can also
> mean "a glyph", thus not a space, or it can mean "not a control
> code", or "any 8 bit value except zero". It all depends on context and
> to try to read anything more into the standard is a bit like the school
> of Biblical interpretation that puts great weight on the difference between
> "the first day" and "day one".
As far as I know, there is no meaning of the word "character"
in C that excludes the space character, control characters, or zero.
--
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-03 11:14 -0700 |
| Message-ID | <0e384ac6-3115-466c-a2d6-45deb16dda63@googlegroups.com> |
| In reply to | #150986 |
On Friday, 3 April 2020 18:34:00 UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] > > It is a kind of theological nonsense discussion, I agree. So I make a > > few pertinent points. > > > > Characters are passed about as ints in standard C, partly so that EOF can > > be encoded as -1, enabling all 8 bits of a char to be used for data encoding. > > "char" is still the ASCII character type, and the term "character" can be > > used in several senses, one of which is the full word for "char". Hence > > "array of character type", meaning "array of chars or derived types". > > What do you mean by "derived types"? In the C standard, that phrase > refers specifically to array, structure, union, function, pointer, and > atomic types. signed char and unsigned char, in particular, are not > derived types. > I'm not writing a contribution to the C standard. "Derived" has its normal meaning, a type created by an addition of a symbol to another base type. > > > Of course the term "character" can also mean "8 bit value or EOF" as in > > "the function fgetc extracts a character from the file". It can also > > mean "a glyph", thus not a space, or it can mean "not a control > > code", or "any 8 bit value except zero". It all depends on context and > > to try to read anything more into the standard is a bit like the school > > of Biblical interpretation that puts great weight on the difference between > > "the first day" and "day one". > > As far as I know, there is no meaning of the word "character" > in C that excludes the space character, control characters, or zero. > The term "character" usually means a drawn symbol. A space is a bit like the null character, indicating the end of word condition. EOF, null, space, and the control characters all mean essentially the same thing, and are marginal cases. They have partial membership of the fuzzy set "characters", if you like.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-04-03 11:34 -0700 |
| Message-ID | <87o8s8quzf.fsf@nosuchdomain.example.com> |
| In reply to | #150987 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Friday, 3 April 2020 18:34:00 UTC+1, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>> > It is a kind of theological nonsense discussion, I agree. So I make a
>> > few pertinent points.
>> >
>> > Characters are passed about as ints in standard C, partly so that EOF can
>> > be encoded as -1, enabling all 8 bits of a char to be used for data encoding.
>> > "char" is still the ASCII character type, and the term "character" can be
>> > used in several senses, one of which is the full word for "char". Hence
>> > "array of character type", meaning "array of chars or derived types".
>>
>> What do you mean by "derived types"? In the C standard, that phrase
>> refers specifically to array, structure, union, function, pointer, and
>> atomic types. signed char and unsigned char, in particular, are not
>> derived types.
>>
> I'm not writing a contribution to the C standard. "Derived" has its
> normal meaning, a type created by an addition of a symbol to another
> base type.
You're writing in a newsgroup that discusses the language defined by
the C standard. If you're going to use terms that are defined by the
C standard, please either use them the way the C standard defines
them, use a different term, or *at least* explain what you mean.
Failing that, can you at least acknowledge that the standard has
its own definitions for terms like "derived type" and "character"?
You know that every time you recycle a defined term for your own
purposes, it leads to a reply like this one. You know how to
avoid that.
>> > Of course the term "character" can also mean "8 bit value or EOF" as in
>> > "the function fgetc extracts a character from the file". It can also
>> > mean "a glyph", thus not a space, or it can mean "not a control
>> > code", or "any 8 bit value except zero". It all depends on context and
>> > to try to read anything more into the standard is a bit like the school
>> > of Biblical interpretation that puts great weight on the difference between
>> > "the first day" and "day one".
>>
>> As far as I know, there is no meaning of the word "character"
>> in C that excludes the space character, control characters, or zero.
>>
> The term "character" usually means a drawn symbol. A space is a bit like
> the null character, indicating the end of word condition. EOF, null,
> space, and the control characters all mean essentially the same thing,
> and are marginal cases. They have partial membership of the fuzzy set
> "characters", if you like.
See above.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-03 14:48 -0400 |
| Message-ID | <r680ee$kdr$1@dont-email.me> |
| In reply to | #150986 |
On 4/3/20 1:33 PM, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] >> It is a kind of theological nonsense discussion, I agree. So I make a >> few pertinent points. >> >> Characters are passed about as ints in standard C, partly so that EOF can >> be encoded as -1, enabling all 8 bits of a char to be used for data encoding. EOF is allowed, but not required, to be -1. Characters are allowed, but not required, to have only 8 bits. An implementation of C could have INT_MIN == CHAR_MIN, in which case your argument wouldn't apply - but that wouldn't prevent such an implementation from fully conforming to the standard. >> "char" is still the ASCII character type, and the term "character" can be The encoding need not be ASCII, and even systems where it is a variant ASCII rather than ASCII itself are increasingly rare - UTF-8 is the most common, but EBCDIC hasn't entirely disappeared yet, either. >> used in several senses, one of which is the full word for "char". Hence It would be stupid to do that in any context where you want to be understood as referring specifically to "char", because you're likely to be misunderstood as referring generically to any member of the set of character types. >> "array of character type", meaning "array of chars or derived types". No, "character type" includes to "char", "signed char", or "unsigned char", each of which is a distinct type, none of them are derived from either of the other two. > What do you mean by "derived types"? In the C standard, that phrase > refers specifically to array, structure, union, function, pointer, and > atomic types. signed char and unsigned char, in particular, are not > derived types. Shall we add "Malcolm-derived type" to the list? >> Of course the term "character" can also mean "8 bit value or EOF" as in >> "the function fgetc extracts a character from the file". It can also >> mean "a glyph", thus not a space, or it can mean "not a control >> code", or "any 8 bit value except zero". It all depends on context and >> to try to read anything more into the standard is a bit like the school >> of Biblical interpretation that puts great weight on the difference between >> "the first day" and "day one". No one can know for certain what the original author meant when writing those phrases - he's long dead, and the earliest suriving commentaries were written long after he died. We can know what the committee meant - they're still alive and available for comment, and the committee occasionally issues official decisions about the meaning of the standard. It's a serious mistake to interpret what the standard says about characters using any definition of "character" other than one the two+ (3.7p1, 3.7.1p1) provided in the standard (any context where it makes a difference which of the two applies, and is not clear from context, constitutes a defect in the standard - such a situation would not justify using your own preferred definition for the term). Similarly, the standard defines many terms that include the word "character" (such as "multibyte character" or "source character set" or "decimal-point character"), and it's a serious mistake to use any definitions for any of those terms other than the ones provided by the standard, when interpreting what the standard means. That's the reason the standard provides such definitions.
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web