Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100318 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-12-27 14:08 +0000 |
| Last post | 2016-12-27 11:42 -0600 |
| Articles | 20 on this page of 202 — 18 participants |
Back to article view | Back to comp.lang.c
Octal BartC <bc@freeuk.com> - 2016-12-27 14:08 +0000
Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 06:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 14:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:07 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 15:22 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:37 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 16:24 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:30 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 09:10 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 09:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 10:47 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:03 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 12:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:44 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 13:37 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:38 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 17:53 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:26 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:48 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 22:20 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 18:41 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 19:19 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:52 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 18:41 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:54 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 17:44 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 22:39 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:49 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 23:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 12:32 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:51 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 14:00 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 01:13 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:04 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:45 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-29 14:49 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 15:33 -0800
Re: Octal supercat@casperkitty.com - 2016-12-30 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:19 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:32 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:35 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:51 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:25 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 06:21 -0800
Re: Octal supercat@casperkitty.com - 2017-01-14 14:00 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:08 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:02 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:52 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:46 -0800
Re: Octal supercat@casperkitty.com - 2017-01-16 01:46 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:33 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:19 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 09:39 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:02 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:13 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:41 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:31 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:39 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:05 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:05 +0000
Re: Octal asetofsymbols@gmail.com - 2016-12-28 11:20 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:01 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 12:30 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:51 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 16:26 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:40 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:41 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 18:04 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 19:36 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:42 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 00:34 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 11:04 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:09 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:46 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:56 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:52 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:27 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:09 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:02 +0000
Re: Octal Ike Naar <ike@iceland.freeshell.org> - 2016-12-28 17:25 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:45 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:21 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 09:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:23 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 11:18 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:54 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 12:57 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:01 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:44 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 17:32 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:03 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:26 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:31 +1300
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:58 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:59 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:00 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:21 +0100
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 11:52 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:10 +0000
Re: Octal supercat@casperkitty.com - 2016-12-29 05:52 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 19:51 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 21:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:15 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:53 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 12:07 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 13:04 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 05:31 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 15:00 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 15:55 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:00 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 08:33 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:02 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:38 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:59 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-01 14:24 -0800
Re: Octal supercat@casperkitty.com - 2017-01-01 15:51 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 13:09 +1300
Re: Octal supercat@casperkitty.com - 2017-01-01 16:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:24 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-02 01:53 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:15 +1300
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 06:24 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 17:53 +0000
Re: Octal luser droog <luser.droog@gmail.com> - 2016-12-30 10:01 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 09:57 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 13:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 11:09 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 14:46 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:28 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 16:01 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 14:48 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:51 +0000
Re: Octal supercat@casperkitty.com - 2016-12-30 15:20 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:34 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 23:40 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:12 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 21:38 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 12:04 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 13:42 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:59 +1300
Re: Octal supercat@casperkitty.com - 2016-12-29 12:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:56 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 22:09 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:27 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 21:18 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:46 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 20:55 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 14:54 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:44 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:39 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:04 -0600
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:52 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 09:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 18:02 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 16:17 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:09 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:02 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:32 -0800
Re: Octal Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 13:45 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:16 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:26 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-02 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:22 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:45 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:59 -0800
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 09:45 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 17:14 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 10:37 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 03:07 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:25 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 11:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 04:35 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:31 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 09:38 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:12 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:20 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 13:39 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:29 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:20 +0100
Re: Octal Noob <root@127.0.0.1> - 2016-12-28 13:02 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:30 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 13:25 +0000
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 15:19 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 08:37 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:43 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:07 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:21 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 15:28 +0100
Re: Octal BGB <cr88192@hotmail.com> - 2016-12-27 11:42 -0600
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-13 15:19 -0800 |
| Message-ID | <kfnlguepmyu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100546 |
supercat@casperkitty.com writes: > On Thursday, December 29, 2016 at 3:35:25 PM UTC-6, Tim Rentsch wrote: >> supercat writes: >>> The only thing that erroneously regards 0x123E+4 as a combination of >>> floating and integer constants is a sloppily-written standard. [...] >> >> Ahh, good old supercat.. never one to let facts stand in the way >> of an unwarranted accusation. > > The rationale for the Standard recognizes that the grammar as > written will reject constructs like 0x1E+2, and offers no real > justification beyond [a concern of the authors that ...] None of that matters to your charge that the standard is the way it is here because it was sloppily written. Obviously it wasn't. Incidentally, let me remind you _again_ that putting a hyphen between an adverb and a following adjective, like "sloppily" and "written", is bad usage. Your writing is bad enough, don't make it worse by having it be ungrammatical.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 15:32 -0800 |
| Message-ID | <lneg06lemy.fsf@kst-u.example.com> |
| In reply to | #101681 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
>>> supercat writes:
>>>> The only thing that erroneously regards 0x123E+4 as a combination of
>>>> floating and integer constants is a sloppily-written standard. [...]
[...]
> Incidentally, let me remind you _again_ that putting a hyphen
> between an adverb and a following adjective, like "sloppily" and
> "written", is bad usage. Your writing is bad enough, don't
> make it worse by having it be ungrammatical.
This web page
http://www.grammarbook.com/punctuation/hyphens.asp
disagrees, as do I. In my opinion, in this particular case, it's ok
with or without the hyphen. Also in my opinion, criticizing English
grammar is not constructive.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-01-14 12:35 +1300 |
| Message-ID | <edt6i6F4adeU6@mid.individual.net> |
| In reply to | #101683 |
On 01/14/17 12:32 PM, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >>>> supercat writes: >>>>> The only thing that erroneously regards 0x123E+4 as a combination of >>>>> floating and integer constants is a sloppily-written standard. [...] > [...] >> Incidentally, let me remind you _again_ that putting a hyphen >> between an adverb and a following adjective, like "sloppily" and >> "written", is bad usage. Your writing is bad enough, don't >> make it worse by having it be ungrammatical. > > This web page > > http://www.grammarbook.com/punctuation/hyphens.asp > > disagrees, as do I. In my opinion, in this particular case, it's ok > with or without the hyphen. Also in my opinion, criticizing English > grammar is not constructive. Rule 3? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-01-13 15:51 -0800 |
| Message-ID | <lna8auldrf.fsf@kst-u.example.com> |
| In reply to | #101685 |
Ian Collins <ian-news@hotmail.com> writes:
> On 01/14/17 12:32 PM, Keith Thompson wrote:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>>>> supercat writes:
>>>>>> The only thing that erroneously regards 0x123E+4 as a combination of
>>>>>> floating and integer constants is a sloppily-written standard. [...]
>> [...]
>>> Incidentally, let me remind you _again_ that putting a hyphen
>>> between an adverb and a following adjective, like "sloppily" and
>>> "written", is bad usage. Your writing is bad enough, don't
>>> make it worse by having it be ungrammatical.
>>
>> This web page
>>
>> http://www.grammarbook.com/punctuation/hyphens.asp
>>
>> disagrees, as do I. In my opinion, in this particular case, it's ok
>> with or without the hyphen. Also in my opinion, criticizing English
>> grammar is not constructive.
>
> Rule 3?
I was thinking of rule 1; I didn't read the entire page.
In any case, my point was that the hyphen in "sloppily-written standard"
is not, in my opinion, sufficiently wrong to be worth commenting on.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-13 18:25 -0800 |
| Message-ID | <357f5ff6-b456-4cb0-8208-fb98f9ad869a@googlegroups.com> |
| In reply to | #101688 |
On Friday, January 13, 2017 at 5:50:47 PM UTC-6, Keith Thompson wrote:
> In any case, my point was that the hyphen in "sloppily-written standard"
> is not, in my opinion, sufficiently wrong to be worth commenting on.
In some environments, it is more important that different peoples'
writings be indistinguishable from each other than they they be as
clear as possible. The linked web site didn't state any basis for
its rules, but such rules are generally used to eliminate situations
where writers might make different judgments based upon their own
perception of what is clearer.
Consider the following sentences:
The students had hastily scrawled notes in their pockets.
The students had hastily-scrawled notes in their pockets.
I would regard the meaning of the second as unambiguous. Would you say
the same about the former?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2017-01-14 06:21 -0800 |
| Message-ID | <2ba81664-8c6a-49ae-bf7e-bbdfceeedded@googlegroups.com> |
| In reply to | #101716 |
On Saturday, January 14, 2017 at 2:25:51 AM UTC, supe...@casperkitty.com wrote: > > Consider the following sentences: > > The students had hastily scrawled notes in their pockets. > > The students had hastily-scrawled notes in their pockets. > > I would regard the meaning of the second as unambiguous. Would you say > the same about the former? > English is parsed by meaning and context as well as by what is thought of as "grammar" rules. (We had a long discussion about this a while back, "grammar" distinguishes allowed from disallowed productions). Anyway. The students had hastily scrawled notes in their notebooks, so they had a crib for the exam. Obviously the students scrawled the notes, scrawled is the main verb of the first part of the sentence. The students had hastily scrawled notes in their pockets. Probably the students themselves scrawled the notes, but not necessarily, and they certainly didn't scrawl the notes whilst they were in their pockets. So "had" in the sense of "owned" is the main verb.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-14 14:00 -0800 |
| Message-ID | <45795411-e1dc-425a-8547-bbfd81a2d6de@googlegroups.com> |
| In reply to | #101760 |
On Saturday, January 14, 2017 at 8:21:45 AM UTC-6, Malcolm McLean wrote: > On Saturday, January 14, 2017 at 2:25:51 AM UTC, supe...@casperkitty.com wrote: > > > > Consider the following sentences: > > > > The students had hastily scrawled notes in their pockets. > > > > The students had hastily-scrawled notes in their pockets. > > > > I would regard the meaning of the second as unambiguous. Would you say > > the same about the former? > > > English is parsed by meaning and context as well as by what is thought > of as "grammar" rules. (We had a long discussion about this a while back, > "grammar" distinguishes allowed from disallowed productions). > > Anyway. > > The students had hastily scrawled notes in their notebooks, so they > had a crib for the exam. > > Obviously the students scrawled the notes, scrawled is the main verb > of the first part of the sentence. > > The students had hastily scrawled notes in their pockets. > > Probably the students themselves scrawled the notes, but not necessarily, > and they certainly didn't scrawl the notes whilst they were in their > pockets. So "had" in the sense of "owned" is the main verb. Those would be the most natural interpretations, though the version without the hyphen could be interpreted the same as the version with. The fact that one version could have either meaning, while the other could only have one, means that copy editors will have an easier job if they compel the use of the ambiguous version. If an editorial style would use hyphens in cases that would otherwise be potentially ambiguous, but writers don't always use that style, copy editors will sometimes have to guess at what writers meant. If the sentence above was supposed to have the former meaning you suggested, having a copy editor add a hyphen would totally break the meaning. By contrast, if the latter meaning was intended, omitting the hyphen might make the sentence unclear, but surrounding context would usually suffice to let readers figure out the correct meaning. Similar issues arise in typography. While the rise of Linotype sentence spacing may have originally been a result of the Linotype's physical limitations, its continued prevalence is a result of editorial convenience. Consider the following paragraphs and how they are spaced: Bob and his friends go to the theater district to see some shows. Joe watches Avenue Q. Randall and James Donovan enjoy Evita. Fred listens to some songs by George M. Cohan and his brother listens to some marches by John Philip Sousa. Bob and his friends go to the theater district to see some shows. Joe watches Avenue Q. Randall and James Donovan enjoy Evita. Fred listens to some songs by George M. Cohan and his brother listens to some marches by John Philip Sousa. Which version is easier to parse? If a publication favored one style but got a submission in the other, which conversion path would be easier? If a publication needs to impose a uniform style upon the output of many writers, such a job will be greatly facilitated if homogeneity can be given priority over clarity.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-15 23:08 -0800 |
| Message-ID | <kfny3ybiisj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101716 |
supercat@casperkitty.com writes: > On Friday, January 13, 2017 at 5:50:47 PM UTC-6, Keith Thompson wrote: >> In any case, my point was that the hyphen in "sloppily-written standard" >> is not, in my opinion, sufficiently wrong to be worth commenting on. > > In some environments, it is more important that different peoples' > writings be indistinguishable from each other than they they be as > clear as possible. The linked web site didn't state any basis for > its rules, but such rules are generally used to eliminate situations > where writers might make different judgments based upon their own > perception of what is clearer. > > Consider the following sentences: > > The students had hastily scrawled notes in their pockets. > > The students had hastily-scrawled notes in their pockets. > > I would regard the meaning of the second as unambiguous. Would you say > the same about the former? One morning I shot an elephant in my pyjamas. How he got into my pyjamas I'll never know English is full of sentences whose meaning is potentially ambiguous. The path most often advised (and most often taken) to remove the ambiguities is to re-write the sentence so it is no longer ambiguous.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-15 23:02 -0800 |
| Message-ID | <kfn37gjjxlw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101688 |
Keith Thompson <kst-u@mib.org> writes: > Ian Collins <ian-news@hotmail.com> writes: >> On 01/14/17 12:32 PM, Keith Thompson wrote: >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> [...] >>>>>> supercat writes: >>>>>>> The only thing that erroneously regards 0x123E+4 as a combination of >>>>>>> floating and integer constants is a sloppily-written standard. [...] >>> >>> [...] >>> >>>> Incidentally, let me remind you _again_ that putting a hyphen >>>> between an adverb and a following adjective, like "sloppily" and >>>> "written", is bad usage. Your writing is bad enough, don't >>>> make it worse by having it be ungrammatical. >>> >>> This web page >>> >>> http://www.grammarbook.com/punctuation/hyphens.asp >>> >>> disagrees, as do I. In my opinion, in this particular case, it's ok >>> with or without the hyphen. Also in my opinion, criticizing English >>> grammar is not constructive. >> >> Rule 3? > > I was thinking of rule 1; I didn't read the entire page. > > In any case, my point was that the hyphen in "sloppily-written standard" > is not, in my opinion, sufficiently wrong to be worth commenting on. If it weren't symptomatic of a larger issue I would probably agree with you. Unfortunately, all the evidence available indicates it very likely is symptomatic of a larger issue.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-13 18:52 -0800 |
| Message-ID | <edb960f8-e7c2-418f-883a-7a3cbe41d196@googlegroups.com> |
| In reply to | #101681 |
On Friday, January 13, 2017 at 5:19:27 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > The rationale for the Standard recognizes that the grammar as > > written will reject constructs like 0x1E+2, and offers no real > > justification beyond [a concern of the authors that ...] > > None of that matters to your charge that the standard is the > way it is here because it was sloppily written. Obviously it > wasn't. You and I seem to have different interpretations of the Standard writers' conduct. The authors of the Standard made no effort to demonstrate that any useful purpose would be served by having compilers reject 0x1E-1 beyond the fact that they didn't want to bother trying to formulate rules that would allow such a construct. I would regard such failure as prima facie evidence of sloppiness. You apparently think otherwise.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-15 23:46 -0800 |
| Message-ID | <kfntw8zigzz.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101719 |
supercat@casperkitty.com writes: > On Friday, January 13, 2017 at 5:19:27 PM UTC-6, Tim Rentsch wrote: >> supercat writes: >>> The rationale for the Standard recognizes that the grammar as >>> written will reject constructs like 0x1E+2, and offers no real >>> justification beyond [a concern of the authors that ...] >> >> None of that matters to your charge that the standard is the >> way it is here because it was sloppily written. Obviously it >> wasn't. > > You and I seem to have different interpretations of the Standard > writers' conduct. The authors of the Standard made no effort to > demonstrate that any useful purpose would be served by having > compilers reject 0x1E-1 beyond the fact that they didn't want to > bother trying to formulate rules that would allow such a construct. > [...] A typical example of your slipshod logic and flawed reasoning (and very likely deliberately obfuscational). First, the Rationale document merely states or summarizes the thinking that went into a decision; it has no need to "demonstrate" anything. Second, your phrase "beyond the fact that they didn't want to bother ..." is simply a lie: that is not a fact, it is your interpretation of a passage in the Rationale document, which says nothing like what you say is a "fact". (For those who want to check this assertion, the passage is 6.4.8 on page 57 (ie, page 64 as reported by my PDF viewer). Third, whatever their reasoning and how good or bad it was, all the indications are that it was a deliberate and conscious decision that produced the result, not sloppy writing. In fact one need only look at the writing in question to see that it clearly and precisely describes a set of character strings that is consistent with other parts of the Standard and with the comments in the Rationale document. Whatever else the writing may be, it is not sloppy, which pretty severely undercuts the idea that how the rules turned out was caused by a sloppily written standard. > I would regard such failure as prima facie evidence of > sloppiness. You apparently think otherwise. You think what you like. I invite anyone who is interested to read the relevant passages in the Standard (essentially unchanged since C90), and in the Rationale document, and draw their own conclusions. I stand by my statements.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-01-16 01:46 -0800 |
| Message-ID | <e351b912-5aae-4cf8-a9f5-73735f412320@googlegroups.com> |
| In reply to | #101928 |
On Monday, January 16, 2017 at 1:47:01 AM UTC-6, Tim Rentsch wrote:
> You think what you like. I invite anyone who is interested to
> read the relevant passages in the Standard (essentially unchanged
> since C90), and in the Rationale document, and draw their own
> conclusions. I stand by my statements.
The claimed purpose of the C89 Standard was to describe a language which
was already in use.
In cases where a specification is supposed to model the behavior of
things that already exist, but differs from the pre-existing behaviors,
it's generally for one of a few reasons:
1. The specification writers' perception of what was being described
didn't match the reality, leading to a defective specification.
2. The specification writers recognized that the actual product had
nuances that would be difficult to describe, but would result
naturally from a straightforward implementation of the spec.
3. The specification writers decided that some aspect of the design
should be changed, called attention to the fact that other devices
(programs in this case) meant to work with the design would no
longer do so, and provided sound justification for breaking them.
4. The specification writers decided that some aspect of the design
should be changed in such a fashion that other devices meant to
work with the design would no longer do so, but accidentally failed
to call attention to that.
5. The specification writers decided that some aspect of the design
should be changed, called attention to the fact that other devices
meant to work with the design would no longer do so, but cited
justifications which would not withstand any reasonable scrutiny.
6. The specification writers decided that some aspect of the design
should be changed in such a fashion that other devices meant to
work with the design would no longer do so, but accidentally failed
to call attention to that for fear that people would be opposed to
breaking the other devices.
Given how few programmers would have any clue as to why 0x1E-2 would not
equal 28, I don't think the Standard writers did a good job of calling
attention to the fact that the rules marked a significant change from
what existing compilers were doing.
In some places where the Standard deliberately broke existing code, it
made very clear its intention to do so. Look, for example, at the
rationale for making short unsigned values promote as signed. The authors
of the Standard noted that it would cause some problems, but expected that
the number of cases where it causes problems would diminish as more and
more systems adopted silent-wraparound two's-complement semantics.
By contrast, while it might have been reasonable to allow that existing
implementations which handle things in a way that couldn't handle 0x1E-2
could continue to do so, the authors of the Standard offered no reason
why better compilers which weren't tripped up by such expressions should
be required to add code to reject them.
The fact that some existing simple implementations handled 0x1E-2 just
fine before the Standard was written refutes the claimed justification
that recognizing such constructs would be overly difficult. The fact
that existing compilers did NOT accept i+++++j means that such a construct
is not analogous to the 0x1E-2 which existing compllers accepted. I
therefore claim interpretation #3 above is not tenable.
Which of the others would you consider most plausible, or did I miss one?
Given a choice between saying the authors of the Standard were sloppy in
some spots versus saying they were jerks, I'd prefer to believe the fomrer.
Can you offer some alternative?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-01-31 08:33 -0800 |
| Message-ID | <kfntw8fdwaj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #101942 |
supercat@casperkitty.com writes: > On Monday, January 16, 2017 at 1:47:01 AM UTC-6, Tim Rentsch wrote: >> You think what you like. I invite anyone who is interested to >> read the relevant passages in the Standard (essentially unchanged >> since C90), and in the Rationale document, and draw their own >> conclusions. I stand by my statements. > > The claimed purpose of the C89 Standard was to describe a language which > was already in use. > > In cases where a specification is supposed to model the behavior of > things that already exist, but differs from the pre-existing behaviors, > it's generally for one of a few reasons: > > 1. The specification writers' perception of what was being described > didn't match the reality, leading to a defective specification. > > 2. The specification writers recognized that the actual product had > nuances that would be difficult to describe, but would result > naturally from a straightforward implementation of the spec. > > 3. The specification writers decided that some aspect of the design > should be changed, called attention to the fact that other devices > (programs in this case) meant to work with the design would no > longer do so, and provided sound justification for breaking them. > > 4. The specification writers decided that some aspect of the design > should be changed in such a fashion that other devices meant to > work with the design would no longer do so, but accidentally failed > to call attention to that. > > 5. The specification writers decided that some aspect of the design > should be changed, called attention to the fact that other devices > meant to work with the design would no longer do so, but cited > justifications which would not withstand any reasonable scrutiny. > > 6. The specification writers decided that some aspect of the design > should be changed in such a fashion that other devices meant to > work with the design would no longer do so, but accidentally failed > to call attention to that for fear that people would be opposed to > breaking the other devices. > > Given how few programmers would have any clue as to why 0x1E-2 would not > equal 28, I don't think the Standard writers did a good job of calling > attention to the fact that the rules marked a significant change from > what existing compilers were doing. > > In some places where the Standard deliberately broke existing code, it > made very clear its intention to do so. Look, for example, at the > rationale for making short unsigned values promote as signed. The authors > of the Standard noted that it would cause some problems, but expected that > the number of cases where it causes problems would diminish as more and > more systems adopted silent-wraparound two's-complement semantics. > > By contrast, while it might have been reasonable to allow that existing > implementations which handle things in a way that couldn't handle 0x1E-2 > could continue to do so, the authors of the Standard offered no reason > why better compilers which weren't tripped up by such expressions should > be required to add code to reject them. > > The fact that some existing simple implementations handled 0x1E-2 just > fine before the Standard was written refutes the claimed justification > that recognizing such constructs would be overly difficult. The fact > that existing compilers did NOT accept i+++++j means that such a construct > is not analogous to the 0x1E-2 which existing compllers accepted. I > therefore claim interpretation #3 above is not tenable. > > Which of the others would you consider most plausible, or did I miss one? > Given a choice between saying the authors of the Standard were sloppy in > some spots versus saying they were jerks, I'd prefer to believe the fomrer. > Can you offer some alternative? I see you are up to your old tricks, oversnipping and deliberate obfuscation so you can shift to a different question. The question here is this: Are the rules for preprocessing numbers a consequence of sloppy writing or of a deliberate conscious decision on the part of the standardization committee? If you want to think it's a consequence of sloppy writing, that's fine with me. I believe it was a deliberate decision of the committee, and I expect anyone _other than you_ would reach the same conclusion after reading through the relevant parts of the Standard and Rationale documents.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 17:19 -0800 |
| Message-ID | <lny3z06ea6.fsf@kst-u.example.com> |
| In reply to | #100375 |
Ian Collins <ian-news@hotmail.com> writes:
> On 12/28/16 12:09 PM, BartC wrote:
>> On 27/12/2016 22:49, Ian Collins wrote:
>>> On 12/28/16 11:39 AM, BartC wrote:
>>>> On 27/12/2016 20:17, Keith Thompson wrote:
>>>>> BartC <bc@freeuk.com> writes:
>>>>> [...]
>>>>>> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the
>>>>>> +3 now meaning a binary exponent.)
>>>>>
>>>>> Yes.
>>>>>
>>>>> The preprocessor treats 0x123E+3 as a single preprocessing number
>>>>> (see N1570 6.4.8). Since it's neither a valid integer constant nor
>>>>> a valid floating-point constant, it's treated as a syntax error in
>>>>> translation phase 7.
>>>>>
>>>>> On the other hand, 0x123F+3 is treated by the preprocessor as three
>>>>> tokens (because it uses F rather than E): the preprocessing number
>>>>> 0x123f (which becomes an integer constant in phase 7), the symbol
>>>>> "=", and the constant 3.
>>>>
>>>> I'm confused now. I thought 0x123E+3 was illegal because it looked like
>>>> an attempt to write a floating point literal in hex, but hex uses 'E'
>>>> for a digit.
>>>>
>>>> Now I can see that it should be parsed as 0x123E followed by +3. But
>>>> some compilers do that (lccwin and DMC), and some don't.
>>
>>> Which ones?
>>
>> printf("%x\n",0x123E+3);
>>
>> Output
>>
>> Pelles C Compiler error
>> lccwin 1241
>> Digital Mars 1241
>> gcc/TDM Compiler error
>> Tiny C Compiler error
>> MSVC 1241
>
>
> Compiler error or Compile error?
I'm not sure what distinction you're making. Presumably it's a
compile-time error message. For example, gcc and clang print:
error: invalid suffix "+3" on integer constant
and tcc prints:
error: invalid number
> Isn't 1241 an windows linker error?
0x1241 is the value of 0x123E + 3. (Using "0x%x" rather than "%x" would
have made the output clearer.) Apparently those compilers
(incorrectly, I believe) treat 0x123E+3 as a sequence of 3 tokens.
N1570 5.1.1.2: In translation phase 3, the source file is decomposed
into preprocessing tokens. In phase 7, "Each preprocessing token is
converted into a token." Tokens and preprocessing tokens are defined in
6.4 (Lexical elements). A "pp-number", defined in 6.8.4, is a kind of
preprocessing token, and a "constant" (which includes integer and
floating constants) is a kind of token. Conclusion: 0x123E+3 is a
single preprocessing token, and it cannot legally be converted into more
than one token. Since it isn't a valid token, it's a syntax error.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-28 09:39 +0000 |
| Message-ID | <586387da.716953@news.xs4all.nl> |
| In reply to | #100374 |
BartC <bc@freeuk.com> wrote:
> On 27/12/2016 22:49, Ian Collins wrote:
> > On 12/28/16 11:39 AM, BartC wrote:
> >> Now I can see that it should be parsed as 0x123E followed by +3. But
> >> some compilers do that (lccwin and DMC), and some don't.
>
> > Which ones?
>
> printf("%x\n",0x123E+3);
>
> Output
>
> Pelles C Compiler error
> lccwin 1241
Interesting that Pelles C gets it right and lccwin gets it wrong;
they're both built on lcc. One for you, jacob.
> gcc/TDM Compiler error
I'll add that both Dev-C++ and Code::Blocks get it right, but they're
both built on gcc + MinGW, so that was more or less (! given the above)
expected.
Richard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 11:02 +0000 |
| Message-ID | <o4062a$976$1@dont-email.me> |
| In reply to | #100402 |
On 28/12/2016 09:39, Richard Bos wrote:
> BartC <bc@freeuk.com> wrote:
>
>> On 27/12/2016 22:49, Ian Collins wrote:
>>> On 12/28/16 11:39 AM, BartC wrote:
>
>>>> Now I can see that it should be parsed as 0x123E followed by +3. But
>>>> some compilers do that (lccwin and DMC), and some don't.
>>
>>> Which ones?
>>
>> printf("%x\n",0x123E+3);
>>
>> Output
>>
>> Pelles C Compiler error
>> lccwin 1241
>
> Interesting that Pelles C gets it right and lccwin gets it wrong;
> they're both built on lcc. One for you, jacob.
Maybe Pelles was just slavishly following the behaviour of gcc, rather
than doing what makes sense and what users might reasonably expect.
What are the consequences of doing it lccwin's (and DMC's and MSVC's)
way? Other than not diagnosing an error in a program that will later be
compiled with gcc (which is the user's responsibility to verify anyway).
Will it cause any programs that compile on both to give different results?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 12:13 +0100 |
| Message-ID | <o406lc$b3e$1@dont-email.me> |
| In reply to | #100405 |
On 28/12/16 12:02, BartC wrote:
> On 28/12/2016 09:39, Richard Bos wrote:
>> BartC <bc@freeuk.com> wrote:
>>
>>> On 27/12/2016 22:49, Ian Collins wrote:
>>>> On 12/28/16 11:39 AM, BartC wrote:
>>
>>>>> Now I can see that it should be parsed as 0x123E followed by +3. But
>>>>> some compilers do that (lccwin and DMC), and some don't.
>>>
>>>> Which ones?
>>>
>>> printf("%x\n",0x123E+3);
>>>
>>> Output
>>>
>>> Pelles C Compiler error
>>> lccwin 1241
>>
>> Interesting that Pelles C gets it right and lccwin gets it wrong;
>> they're both built on lcc. One for you, jacob.
>
> Maybe Pelles was just slavishly following the behaviour of gcc, rather
> than doing what makes sense and what users might reasonably expect.
>
> What are the consequences of doing it lccwin's (and DMC's and MSVC's)
> way? Other than not diagnosing an error in a program that will later be
> compiled with gcc (which is the user's responsibility to verify anyway).
>
> Will it cause any programs that compile on both to give different results?
>
If someone writes 0x123e+3, it is not clear whether they intended to
write 0x123e + 3, or 0x123p+3. I think it is better that the compiler
give an error, than for it to guess - sometimes it will be correct, and
sometimes it will silently misinterpret the developer's mistake.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 11:41 +0000 |
| Message-ID | <o408am$fuc$1@dont-email.me> |
| In reply to | #100408 |
On 28/12/2016 11:13, David Brown wrote: > On 28/12/16 12:02, BartC wrote: >> Will it cause any programs that compile on both to give different results? > > If someone writes 0x123e+3, it is not clear whether they intended to > write 0x123e + 3, or 0x123p+3. I think it is better that the compiler > give an error, than for it to guess - sometimes it will be correct, and > sometimes it will silently misinterpret the developer's mistake. That would be a warning then, not an error, as nothing is actually wrong. How many people use hex floating point anyway? But if a compiler is going to think up ways that a programmer may have written numbers wrongly then what about: 0x123E3 Maybe /this/ should have been written as 0x123p3! Or 123E3, which was supposed to be 0x123E3 but the the "0x" was left out. Or 0123E3, when the "x" is left out. Why is the compiler not giving errors in these cases? Surely they must count as pp-numbers too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 09:31 -0800 |
| Message-ID | <ln60m455ab.fsf@kst-u.example.com> |
| In reply to | #100411 |
BartC <bc@freeuk.com> writes:
[...]
> But if a compiler is going to think up ways that a programmer may have
> written numbers wrongly then what about:
>
> 0x123E3
>
> Maybe /this/ should have been written as 0x123p3!
>
> Or 123E3, which was supposed to be 0x123E3 but the the "0x" was left
> out. Or 0123E3, when the "x" is left out.
>
> Why is the compiler not giving errors in these cases? Surely they must
> count as pp-numbers too.
0x123E3 is a perfectly valid hexadecimal integer constant. 123E3 is a
perfectly valid floating constant. Yes, they're valid pp-numbers, and
they're converted to valid constants in translation phase 7. That's why
compilers don't print error messages for them -- because they're not
errors.
I've already explained why 0x123e+3 is a syntax error. I understand
that you don't like that fact; I'm not entirely pleased about it myself.
But it is what it is.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 17:39 +0000 |
| Message-ID | <o40ta0$j5t$1@dont-email.me> |
| In reply to | #100442 |
On 28/12/2016 17:31, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> But if a compiler is going to think up ways that a programmer may have >> written numbers wrongly then what about: >> >> 0x123E3 >> >> Maybe /this/ should have been written as 0x123p3! >> >> Or 123E3, which was supposed to be 0x123E3 but the the "0x" was left >> out. Or 0123E3, when the "x" is left out. >> >> Why is the compiler not giving errors in these cases? Surely they must >> count as pp-numbers too. > > 0x123E3 is a perfectly valid hexadecimal integer constant. 123E3 is a > perfectly valid floating constant. Yes, they're valid pp-numbers, and > they're converted to valid constants in translation phase 7. That's why > compilers don't print error messages for them -- because they're not > errors. > > I've already explained why 0x123e+3 is a syntax error. I understand > that you don't like that fact; I'm not entirely pleased about it myself. > But it is what it is. David Brown suggested the compiler messages were given because 0x123E+3 was ambiguous (possible user-error). In which case I gave other such examples that don't generate an error. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web