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 1 of 11 [1] 2 3 … 11 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 14:08 +0000 |
| Subject | Octal |
| Message-ID | <o3tsi4$es8$1@dont-email.me> |
I'm doing some work on C tokenising and this amusing quirk came up.
Octal literals are already an anachronism but here:
printf("%d\n", 0123 );
printf("%f\n", 0123.);
a leading zero to signify an octal number apparently doesn't stretch as
far as floating point. The output is:
83
123.000000
It's likely to bite in scenarios like this:
double A[]={123, 123., 0123, 0123.};
Spot the odd one out.
--
Bartc
[toc] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-27 06:19 -0800 |
| Message-ID | <9f751874-98cf-4208-b809-9e6424600ac6@googlegroups.com> |
| In reply to | #100318 |
CAlive prefers prefixes:
0x hexadecimal, 0x123abc
0y binary, 0y1000110
0o octal, 0o123567
0n##_ arbitrary base, 0n36_abcxyz123
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 14:58 +0000 |
| Message-ID | <o3tvf6$orj$1@dont-email.me> |
| In reply to | #100319 |
On 27/12/2016 14:19, Rick C. Hodgin wrote: > CAlive prefers prefixes: > > 0x hexadecimal, 0x123abc > 0y binary, 0y1000110 C commonly uses 0b and 0B; why not just got with that? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-27 07:07 -0800 |
| Message-ID | <e973caed-1397-4811-ad57-242b672edcd8@googlegroups.com> |
| In reply to | #100322 |
On Tuesday, December 27, 2016 at 9:58:15 AM UTC-5, Bart wrote: > On 27/12/2016 14:19, Rick C. Hodgin wrote: > > CAlive prefers prefixes: > > > > 0x hexadecimal, 0x123abc > > 0y binary, 0y1000110 > > C commonly uses 0b and 0B; why not just got with that? For one VERY good reason: I didn't know C allowed that. :-) In looking at it just now, I think seeing something like 0B10, it might be easily confused with something like 0x0B10 in developer's minds. I like the 0y because it really stands out as something unique. And when you only see 1s and 0s after it, I think it would be clear. But, with a "b" or "B" in there ... I can see that being interpreted as a hex address. Remember the old DOS days with 0b0000h addresses being used for the monochrome monitor starting data address? Nonetheless, now that I know of that feature's existence, CAlive will allow both. Feel free to point out any other areas where CAlive is missing something C supports. I genuinely desire to make a fully compatible C90 + C99 compiler at some point. And I want CAlive to be nearly 100% compatible in its native form (if you use C syntax, and not CAlive's new syntax). And in areas where my knowledge is insufficient, I welcome the assistance. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 15:22 +0000 |
| Message-ID | <o3u0t8$udg$1@dont-email.me> |
| In reply to | #100323 |
On 27/12/2016 15:07, Rick C. Hodgin wrote:
> On Tuesday, December 27, 2016 at 9:58:15 AM UTC-5, Bart wrote:
>> On 27/12/2016 14:19, Rick C. Hodgin wrote:
>>> CAlive prefers prefixes:
>>>
>>> 0x hexadecimal, 0x123abc
>>> 0y binary, 0y1000110
>>
>> C commonly uses 0b and 0B; why not just got with that?
>
> For one VERY good reason: I didn't know C allowed that. :-)
>
> In looking at it just now, I think seeing something like 0B10, it might
> be easily confused with something like 0x0B10 in developer's minds. I
> like the 0y because it really stands out as something unique.
You don't see a similarity between 0x and 0y? Especially as 0X and 0Y:
0X10110110101
0Y10110110101
0B10110110101
0X10110110101
0B10110110101
0Y10110110101
I think 0B has the edge on 0Y.
(I used 1001101B for years, now I use 2x1001101. If I used binary a lot
more then I'd have 0B too. I've already switched over from 7FFFH to 0x7FFF)
BTW in your 0n##_ format, you can get the same 'sameness' there:
0n2_10110110101
0n12_10110110101
0n22_10110110101
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-27 07:37 -0800 |
| Message-ID | <5de6cdd0-6a36-40da-9bd6-4387d43c7947@googlegroups.com> |
| In reply to | #100324 |
On Tuesday, December 27, 2016 at 10:22:48 AM UTC-5, Bart wrote: > On 27/12/2016 15:07, Rick C. Hodgin wrote: > > On Tuesday, December 27, 2016 at 9:58:15 AM UTC-5, Bart wrote: > >> On 27/12/2016 14:19, Rick C. Hodgin wrote: > >>> CAlive prefers prefixes: > >>> > >>> 0x hexadecimal, 0x123abc > >>> 0y binary, 0y1000110 > >> > >> C commonly uses 0b and 0B; why not just got with that? > > > > For one VERY good reason: I didn't know C allowed that. :-) > > > > In looking at it just now, I think seeing something like 0B10, it might > > be easily confused with something like 0x0B10 in developer's minds. I > > like the 0y because it really stands out as something unique. > > You don't see a similarity between 0x and 0y? Especially as 0X and 0Y: > > 0X10110110101 > 0Y10110110101 > 0B10110110101 > 0X10110110101 > 0B10110110101 > 0Y10110110101 I don't think I've ever used 0X (upper-case). > I think 0B has the edge on 0Y. I think 0B has an edge on 0Y, but I think 0y has an edge on 0b, and somewhat more so than the former. > (I used 1001101B for years, now I use 2x1001101. If I used binary a lot > more then I'd have 0B too. I've already switched over from 7FFFH to 0x7FFF) Ooh, I like that: 2x... I think I'll adopt that too. :-) > BTW in your 0n##_ format, you can get the same 'sameness' there: > > 0n2_10110110101 > 0n12_10110110101 > 0n22_10110110101 I think the number out front differentiates it enough. It provides a useful utility for arbitrary bases. Though I think your format might be more desirable: 2x10110110101, 12x10110110101, 22x10110110101. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 16:24 +0000 |
| Message-ID | <o3u4h0$c7m$1@dont-email.me> |
| In reply to | #100325 |
On 27/12/2016 15:37, Rick C. Hodgin wrote: > On Tuesday, December 27, 2016 at 10:22:48 AM UTC-5, Bart wrote: > Ooh, I like that: 2x... I think I'll adopt that too. :-) > I think the number out front differentiates it enough. It provides a > useful utility for arbitrary bases. Though I think your format might > be more desirable: 2x10110110101, 12x10110110101, 22x10110110101. Don't forget 8x377 for octal! (But I've only ever used it once. Note that for tokenising, the #x... scheme can slow things down, especially when the base goes into double figures. With C, only an initial 0 is a special case. But then that advantage is offset by the preprocessor...) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-27 08:30 -0800 |
| Message-ID | <1967226c-c6c3-4032-9f98-2fabe7781c56@googlegroups.com> |
| In reply to | #100329 |
On Tuesday, December 27, 2016 at 11:24:33 AM UTC-5, Bart wrote: > On 27/12/2016 15:37, Rick C. Hodgin wrote: > > On Tuesday, December 27, 2016 at 10:22:48 AM UTC-5, Bart wrote: > > > Ooh, I like that: 2x... I think I'll adopt that too. :-) > > > I think the number out front differentiates it enough. It provides a > > useful utility for arbitrary bases. Though I think your format might > > be more desirable: 2x10110110101, 12x10110110101, 22x10110110101. > > Don't forget 8x377 for octal! I think more generically I will allow ##x... and whatever the arbitrary base is there it will parse what follows in that way. > (But I've only ever used it once. Note that for tokenising, the #x... > scheme can slow things down, especially when the base goes into double > figures. With C, only an initial 0 is a special case. But then that > advantage is offset by the preprocessor...) My concerns aren't with compilation speed with CAlive. I plan an edit- and-continue continuous compiler that is working in the background as you are writing code in the IDE. It should only be recompiling little bits on-the-fly, and then when you go to run do the final linking. In addition, we are getting more and more cores on our CPUs these days, so I plan to simply go wider rather than taller (spawn more simultaneous compilation processes which may be slower, rather than fewer which may be faster). My goals with CAlive are to look at what we have in the 2010s and where we're headed in the 2020s. I plan to have CAlive compiling code in 2017, and working really well by 2020. I also want to have full C90 and C99 C compatibility support by the end of 2022. Plans are plans ... we'll see what comes of it (James 4:15). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-27 09:10 -0800 |
| Message-ID | <9cb7833a-8479-4e61-8398-690783c4d975@googlegroups.com> |
| In reply to | #100329 |
On Tuesday, December 27, 2016 at 10:24:33 AM UTC-6, Bart wrote: > (But I've only ever used it once. Note that for tokenising, the #x... > scheme can slow things down, especially when the base goes into double > figures. With C, only an initial 0 is a special case. But then that > advantage is offset by the preprocessor...) Is there any practical advantage to trying to distinguish the number type before the seeing the first period or other non-alphanumeric character, versus parsing the token and then examining it as a whole? The Standard- mandated interpretation of 0x123E+3 as a single token which will be a constraint violation if it survives the preprocessor may complicate things slightly, but I would think processing that as three tokens [0x123e + 3] would be more useful whether or not it is conforming.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 09:35 -0800 |
| Message-ID | <lnzijh6zrf.fsf@kst-u.example.com> |
| In reply to | #100332 |
supercat@casperkitty.com writes:
> On Tuesday, December 27, 2016 at 10:24:33 AM UTC-6, Bart wrote:
>> (But I've only ever used it once. Note that for tokenising, the #x...
>> scheme can slow things down, especially when the base goes into double
>> figures. With C, only an initial 0 is a special case. But then that
>> advantage is offset by the preprocessor...)
>
> Is there any practical advantage to trying to distinguish the number type
> before the seeing the first period or other non-alphanumeric character,
> versus parsing the token and then examining it as a whole? The Standard-
> mandated interpretation of 0x123E+3 as a single token which will be a
> constraint violation if it survives the preprocessor may complicate things
> slightly, but I would think processing that as three tokens [0x123e + 3]
> would be more useful whether or not it is conforming.
How would it be more useful? Getting an error message encourages you to
change 0x123e+3 to 0x123e + 3, which is much more legible.
--
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 | 2016-12-27 10:47 -0800 |
| Message-ID | <20280aee-5f78-47fa-ae22-c7bc852e3efb@googlegroups.com> |
| In reply to | #100334 |
On Tuesday, December 27, 2016 at 11:35:32 AM UTC-6, Keith Thompson wrote: > supercat writes: > > On Tuesday, December 27, 2016 at 10:24:33 AM UTC-6, Bart wrote: > > Is there any practical advantage to trying to distinguish the number type > > before the seeing the first period or other non-alphanumeric character, > > versus parsing the token and then examining it as a whole? The Standard- > > mandated interpretation of 0x123E+3 as a single token which will be a > > constraint violation if it survives the preprocessor may complicate things > > slightly, but I would think processing that as three tokens [0x123e + 3] > > would be more useful whether or not it is conforming. > > How would it be more useful? Getting an error message encourages you to > change 0x123e+3 to 0x123e + 3, which is much more legible. If spaces after hex constants and operators that follow them are a good thing, does it make sense to allow code to omit them in all cases other than when the last digit happens to be "E" and the operator is a "+" or "-"? Is there any reason that 0x123E+5 would be less legible for a human than 0x123F+5 or 0x123E*16?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 12:03 -0800 |
| Message-ID | <lnvau56sxg.fsf@kst-u.example.com> |
| In reply to | #100344 |
supercat@casperkitty.com writes:
> On Tuesday, December 27, 2016 at 11:35:32 AM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > On Tuesday, December 27, 2016 at 10:24:33 AM UTC-6, Bart wrote:
>> > Is there any practical advantage to trying to distinguish the number type
>> > before the seeing the first period or other non-alphanumeric character,
>> > versus parsing the token and then examining it as a whole? The Standard-
>> > mandated interpretation of 0x123E+3 as a single token which will be a
>> > constraint violation if it survives the preprocessor may complicate things
>> > slightly, but I would think processing that as three tokens [0x123e + 3]
>> > would be more useful whether or not it is conforming.
>>
>> How would it be more useful? Getting an error message encourages you to
>> change 0x123e+3 to 0x123e + 3, which is much more legible.
>
> If spaces after hex constants and operators that follow them are a good
> thing, does it make sense to allow code to omit them in all cases other
> than when the last digit happens to be "E" and the operator is a "+" or
> "-"? Is there any reason that 0x123E+5 would be less legible for a human
> than 0x123F+5 or 0x123E*16?
The syntax of a preprocessing number is, as I understand it, designed
to make the preprocessor's job a bit easier, leaving more detailed
analysis (determining the type and value of a constant and rejecting
some that are syntax errors) for translation phase 7.
If the language were being designed today, I suspect that the
distinction would not be made, and that the preprocessor would
use the same syntax for numeric constants that's used in phase 7.
(Take note of this if you design a new language with a C-like
separate preprocessor phase.)
It's not specifically intended to encourage legible code.
That's just an accidental side effect in this particular case.
You suggest that treating 0x123e+3 as three tokens rather than one
would be "more useful". The only effect of such a change (apart from
changing the syntax of preprocessor numbers and possibly breaking
existing code, depending on how the new syntax is defined) would
be to change some obscure constructs from being both invalid and
difficult to read, to being valid and difficult to read.
The fact that 0x123F+3 is allowed (meaning 0x123F + 3) and 0x123E+5
is not (because it's a single preprocessing number) is an odd little
glitch in the language. To the extent that it's a problem, it can
be neatly avoided with judicious use of spaces. It absolutely is
not, in my opinion, worth "fixing". Most programmers will never run
into it. Have you?
--
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 | 2016-12-27 12:27 -0800 |
| Message-ID | <f1ba350a-71c0-44cf-a57f-aace35f6f2f2@googlegroups.com> |
| In reply to | #100348 |
On Tuesday, December 27, 2016 at 2:02:18 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> The fact that 0x123F+3 is allowed (meaning 0x123F + 3) and 0x123E+5
> is not (because it's a single preprocessing number) is an odd little
> glitch in the language. To the extent that it's a problem, it can
> be neatly avoided with judicious use of spaces. It absolutely is
> not, in my opinion, worth "fixing". Most programmers will never run
> into it. Have you?
As a matter of fact, a coworker of mine did run into it a little while ago
when trying to tweak some code which made heavy use of hex constants, some
of which needed to be bumped up slightly. Rather than editing the constants
directly, he appended "+1", "+2", etc. I was able to help him with the
syntax error that resulted when one of the constants happened to end with
an E, but he didn't think he would have been able to figure out what was
going on if I hadn't explained it.
As for whether adding spaces improves legibility, that depends upon what else
is on the lines in question. If one has a table of values that all need to
be one larger than specified, appending +1 to every value will make all the
entries two characters longer, but if entries had been separated by a space
as well as a comma, the increase could be limited to one character. If one
character will fit the editor/printer line width without wrapping or (for
the editor only) scrolling, but two won't, having to add an extra space may
make the table harder to inspect.
A simple way to address the issue would be to say that compilers may at
their option process 0x1E+1 as three tokens 0x1E + 1, or may issue a
diagnostic. There are already many situations where some compilers will
silently accept code for which others would issue a diagnostic (e.g.
int q[256u*256u];
so I don't see anything to be gained by insisting that one compiler's
inability to handle a construct should justify compelling all compilers to
regard it as a constraint violation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 12:44 -0800 |
| Message-ID | <lneg0t6r1f.fsf@kst-u.example.com> |
| In reply to | #100355 |
supercat@casperkitty.com writes:
> On Tuesday, December 27, 2016 at 2:02:18 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> The fact that 0x123F+3 is allowed (meaning 0x123F + 3) and 0x123E+5
>> is not (because it's a single preprocessing number) is an odd little
>> glitch in the language. To the extent that it's a problem, it can
>> be neatly avoided with judicious use of spaces. It absolutely is
>> not, in my opinion, worth "fixing". Most programmers will never run
>> into it. Have you?
>
> As a matter of fact, a coworker of mine did run into it a little while ago
> when trying to tweak some code which made heavy use of hex constants, some
> of which needed to be bumped up slightly. Rather than editing the constants
> directly, he appended "+1", "+2", etc. I was able to help him with the
> syntax error that resulted when one of the constants happened to end with
> an E, but he didn't think he would have been able to figure out what was
> going on if I hadn't explained it.
Interesting.
> As for whether adding spaces improves legibility, that depends upon what else
> is on the lines in question. If one has a table of values that all need to
> be one larger than specified, appending +1 to every value will make all the
> entries two characters longer, but if entries had been separated by a space
> as well as a comma, the increase could be limited to one character. If one
> character will fit the editor/printer line width without wrapping or (for
> the editor only) scrolling, but two won't, having to add an extra space may
> make the table harder to inspect.
Ok, but I'm still not convinced it's worth changing the language
definition so you can avoid a little line wrapping.
You've shown one case of someone running into the issue. In that one
case, did adding spaces actually cause line width problems, or is that
just a theoretical issue? (If so, prepending "1+" rather than appending
"+1" would have been a workaround. Taking the time to modify the
constants, perhaps using a script, might have been even better.)
> A simple way to address the issue would be to say that compilers may at
> their option process 0x1E+1 as three tokens 0x1E + 1, or may issue a
> diagnostic. There are already many situations where some compilers will
> silently accept code for which others would issue a diagnostic (e.g.
>
> int q[256u*256u];
256u*256u clearly doesn't require a diagnostic. Compilers are permitted
to warn about anything they like.
> so I don't see anything to be gained by insisting that one compiler's
> inability to handle a construct should justify compelling all compilers to
> regard it as a constraint violation.
(It's a syntax error, not a constraint violation.)
Ok, so let's say the standard is updated to say that a conforming
compiler may, but need not, treat 0x1E+1 as three tokens --
and if it does so it needn't warn about it. You happen to use
that construct in your code, without being aware of the issue.
Years later you port the code to another compiler that rejects it.
But hey, at least you were *temporarily* able to save two whole
columns in one line of your C source file.
--
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 | 2016-12-27 13:37 -0800 |
| Message-ID | <26119487-8644-4352-82bc-f1f1b6d7bb30@googlegroups.com> |
| In reply to | #100356 |
On Tuesday, December 27, 2016 at 2:44:15 PM UTC-6, Keith Thompson wrote: > supercat writes: > You've shown one case of someone running into the issue. In that one > case, did adding spaces actually cause line width problems, or is that > just a theoretical issue? (If so, prepending "1+" rather than appending > "+1" would have been a workaround. Taking the time to modify the > constants, perhaps using a script, might have been even better.) I don't know that adding spaces would have caused line-width problems in that particular case, but I've certainly had other cases where a need to add extra spaces to tables would cause line-width issues. > > A simple way to address the issue would be to say that compilers may at > > their option process 0x1E+1 as three tokens 0x1E + 1, or may issue a > > diagnostic. There are already many situations where some compilers will > > silently accept code for which others would issue a diagnostic (e.g. > > > > int q[256u*256u]; > > 256u*256u clearly doesn't require a diagnostic. Compilers are permitted > to warn about anything they like. What is the value of 256u*256u on systems where UINT_MAX is 65535? Why would a diagnostic not be required on all such systems? Certainly that particular example is contrived, but a lot of code expects that "int" will have a certain minimum size and will fail on systems where it doesn't. I didn't want to get into the details of when an integer overflow that is detected at compile time would require a diagnostic versus silently producing code with arbitrary behavior, so the example was contrived to make the requirement for the diagnostic unambiguous. > Ok, so let's say the standard is updated to say that a conforming > compiler may, but need not, treat 0x1E+1 as three tokens -- > and if it does so it needn't warn about it. You happen to use > that construct in your code, without being aware of the issue. > Years later you port the code to another compiler that rejects it. > But hey, at least you were *temporarily* able to save two whole > columns in one line of your C source file. I would expect that compilers would quickly evolve to accept the new syntax without complaint if allowed to do so. Perhaps there's some non-contrived way of writing a scanner where it's easier to regard "E+" and "E-" as special within any number, than to regard an "E" as special only when processing a decimal literal, but I would think using single-character look-ahead would be easier than using multi-character. Is there some reason you think compiler writers would want to stick with extra complexity whose primary purpose is to produce syntax errors from code which would otherwise be unambiguous, rather than remove the weird cases from their scanner and replace them with something simpler?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 16:38 -0800 |
| Message-ID | <ln7f6k7ur5.fsf@kst-u.example.com> |
| In reply to | #100361 |
supercat@casperkitty.com writes:
> On Tuesday, December 27, 2016 at 2:44:15 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> You've shown one case of someone running into the issue. In that one
>> case, did adding spaces actually cause line width problems, or is that
>> just a theoretical issue? (If so, prepending "1+" rather than appending
>> "+1" would have been a workaround. Taking the time to modify the
>> constants, perhaps using a script, might have been even better.)
>
> I don't know that adding spaces would have caused line-width problems in
> that particular case, but I've certainly had other cases where a need to
> add extra spaces to tables would cause line-width issues.
>
>> > A simple way to address the issue would be to say that compilers may at
>> > their option process 0x1E+1 as three tokens 0x1E + 1, or may issue a
>> > diagnostic. There are already many situations where some compilers will
>> > silently accept code for which others would issue a diagnostic (e.g.
>> >
>> > int q[256u*256u];
>>
>> 256u*256u clearly doesn't require a diagnostic. Compilers are permitted
>> to warn about anything they like.
>
> What is the value of 256u*256u on systems where UINT_MAX is 65535? Why
> would a diagnostic not be required on all such systems?
The value of 256u*256u on such a system is 0u. A diagnostic is required
because a zero-length array is a constraint violation. A diagnostic is
not required on systems with UINT_MAX > 65535 because on such systems no
constraint is violated. This is irrelevant to the topic of this thread.
Start a new thread and I might consider discussing it further.
[...]
>> Ok, so let's say the standard is updated to say that a conforming
>> compiler may, but need not, treat 0x1E+1 as three tokens --
>> and if it does so it needn't warn about it. You happen to use
>> that construct in your code, without being aware of the issue.
>> Years later you port the code to another compiler that rejects it.
>> But hey, at least you were *temporarily* able to save two whole
>> columns in one line of your C source file.
>
> I would expect that compilers would quickly evolve to accept the new syntax
> without complaint if allowed to do so. Perhaps there's some non-contrived
> way of writing a scanner where it's easier to regard "E+" and "E-" as special
> within any number, than to regard an "E" as special only when processing a
> decimal literal, but I would think using single-character look-ahead would
> be easier than using multi-character.
>
> Is there some reason you think compiler writers would want to stick with
> extra complexity whose primary purpose is to produce syntax errors from code
> which would otherwise be unambiguous, rather than remove the weird cases
> from their scanner and replace them with something simpler?
What "extra complexity"? Have you read section 6.4.8 of the standard,
describing preprocessing numbers?
Again, suppose such a change is made. How long do you think it would
take before C programmers can reliably assume that 0x1E+1 will *always*
be treated as 3 tokens?
--
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 | 2016-12-27 17:53 -0800 |
| Message-ID | <a8cf4377-915d-4226-90db-e672b7daa130@googlegroups.com> |
| In reply to | #100380 |
On Tuesday, December 27, 2016 at 6:38:43 PM UTC-6, Keith Thompson wrote: > supercat writes: > > Is there some reason you think compiler writers would want to stick with > > extra complexity whose primary purpose is to produce syntax errors from code > > which would otherwise be unambiguous, rather than remove the weird cases > > from their scanner and replace them with something simpler? > > What "extra complexity"? Have you read section 6.4.8 of the standard, > describing preprocessing numbers? How many useful programs' behavior would be affected by a compiler which did not start by grouping the pp-number terms as described but instead either used a grammar that processed the different kinds of numeric literals directly or else started by initially recognizing three kinds of chunks of code: 1. Runs of whitespace. 2. Runs of characters that are legal in identifiers, including digits 3. Other characters, individually and then later worried about recognizing constructs like [1-9][0-9]* . [0-9*][eE] [+-] [0-9][0-9]* as floating-point literals?? Would anything else render the as-if rule inapplicable as justification for such a parsing approach if a compiler had special logic to diagnose constructs where a + or - was preceded by an alphanumeric run that ended with E but contained other non-numeric characters? > Again, suppose such a change is made. How long do you think it would > take before C programmers can reliably assume that 0x1E+1 will *always* > be treated as 3 tokens? Probably not terribly long, in many venues. Many compilers accept the notation without complaint because it's trivially easy to do so. I am not sure if it's possible to write a strictly-conforming program whose behavior would be affected by the change, and I doubt such a change would affect the behavior of any useful program which was not deliberately contrived to be affected by it. If none of a compiler writers' customers ever complain about the lack of a feature, the compiler writer would not need to waste time worrying about it; if a compiler writers' customers complain about the lack of a feature, such complaints would suggest that people found it useful.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-27 20:26 -0600 |
| Message-ID | <gf866ctadftuueojd7kni4i0s3sdaplrmt@4ax.com> |
| In reply to | #100388 |
On Tue, 27 Dec 2016 17:53:16 -0800 (PST), supercat@casperkitty.com wrote: >> Again, suppose such a change is made. How long do you think it would >> take before C programmers can reliably assume that 0x1E+1 will *always* >> be treated as 3 tokens? > >Probably not terribly long, in many venues. Many compilers accept the >notation without complaint because it's trivially easy to do so. I am >not sure if it's possible to write a strictly-conforming program whose >behavior would be affected by the change, It would potentially impact the interpretation of (valid) arguments to macros. You couldn't do too much useful *with* such a parameter, except stringize it. >and I doubt such a change would >affect the behavior of any useful program which was not deliberately >contrived to be affected by it. Likely the set of such programs is pretty small.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-27 18:48 -0800 |
| Message-ID | <ad061454-043d-4847-aa99-47c664237b47@googlegroups.com> |
| In reply to | #100390 |
On Tuesday, December 27, 2016 at 8:26:34 PM UTC-6, robert...@yahoo.com wrote: > On Tue, 27 Dec 2016 17:53:16 -0800 (PST), supercat wrote: > >Probably not terribly long, in many venues. Many compilers accept the > >notation without complaint because it's trivially easy to do so. I am > >not sure if it's possible to write a strictly-conforming program whose > >behavior would be affected by the change, > > It would potentially impact the interpretation of (valid) arguments to > macros. You couldn't do too much useful *with* such a parameter, > except stringize it. Can you formulate any examples which would compile with a strict interpretation of the rules, and which would yield different behavior if any + sign which followed a 0x without an intervening decimal point would be regarded as a token boundary?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-27 22:20 -0600 |
| Message-ID | <73e66c14ilsrvupar3s6k9uavi1mf5j8gv@4ax.com> |
| In reply to | #100393 |
On Tue, 27 Dec 2016 18:48:43 -0800 (PST), supercat@casperkitty.com wrote: >On Tuesday, December 27, 2016 at 8:26:34 PM UTC-6, robert...@yahoo.com wrote: >> On Tue, 27 Dec 2016 17:53:16 -0800 (PST), supercat wrote: >> >Probably not terribly long, in many venues. Many compilers accept the >> >notation without complaint because it's trivially easy to do so. I am >> >not sure if it's possible to write a strictly-conforming program whose >> >behavior would be affected by the change, >> >> It would potentially impact the interpretation of (valid) arguments to >> macros. You couldn't do too much useful *with* such a parameter, >> except stringize it. > >Can you formulate any examples which would compile with a strict >interpretation of the rules, and which would yield different behavior >if any + sign which followed a 0x without an intervening decimal point >would be regarded as a token boundary? Sorry, the case I was thinking about was not correct.
[toc] | [prev] | [next] | [standalone]
Page 1 of 11 [1] 2 3 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web