Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77503 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2015-12-01 12:52 +0000 |
| Last post | 2015-12-01 12:24 -0800 |
| Articles | 20 on this page of 151 — 24 participants |
Back to article view | Back to comp.lang.c
// comments and \ BartC <bc@freeuk.com> - 2015-12-01 12:52 +0000
Re: // comments and \ me <self@example.org> - 2015-12-01 13:08 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 08:20 -0500
Re: // comments and \ me <self@example.org> - 2015-12-01 13:36 +0000
Re: // comments and \ Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-01 09:03 -0500
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 14:14 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 07:40 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 08:55 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 17:15 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 09:58 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:11 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 10:18 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 18:20 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 11:07 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-01 11:39 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 12:33 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:05 +0000
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:30 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 20:59 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-01 15:22 -0500
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:37 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 14:56 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 22:11 +0100
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:01 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 00:45 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 15:19 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 08:29 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:35 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 09:21 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 16:41 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 10:15 -0700
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:24 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:43 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:05 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-02 11:40 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:29 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 19:11 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 20:43 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 21:04 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-01 21:16 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 03:12 -0800
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 11:52 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 04:40 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 13:55 +0100
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-02 13:56 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 15:24 +0100
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 06:54 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-02 16:40 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 18:24 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-02 20:27 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 23:22 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 00:57 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:44 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-03 21:17 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 00:43 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:32 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 16:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:10 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:18 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-06 14:26 -0600
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 12:45 +0100
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:45 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-04 04:20 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:20 +0100
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 10:05 -0500
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 17:31 +0100
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 17:24 -0600
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-04 18:50 -0500
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:34 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-10 20:40 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-04 09:36 -0800
Re: // comments and \ Richard Damon <Richard@Damon-Family.org> - 2015-12-05 09:05 -0500
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 17:42 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-06 22:23 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-07 21:59 +0000
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 15:50 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-05 18:17 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:01 +0000
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 03:05 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 04:07 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 04:37 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 05:05 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:19 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 13:59 +0000
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 06:09 -0800
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-06 07:30 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 18:55 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:23 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-06 12:22 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 21:06 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-05 13:14 -0600
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-06 10:09 +0000
Re: // comments and \ mark.bluemel@gmail.com - 2015-12-03 06:15 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-02 08:28 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 09:01 -0800
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-02 21:52 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 16:55 -0800
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-03 13:11 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-03 23:21 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 11:22 +0100
Re: // comments and \ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:12 +0000
Re: // comments and \ Les Cargill <lcargill99@comcast.com> - 2015-12-04 20:39 -0600
Re: // comments and \ raltbos@xs4all.nl (Richard Bos) - 2015-12-04 11:14 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-04 12:25 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-04 14:23 +0100
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:00 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:46 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 20:36 +0000
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 20:37 -0700
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:26 +0000
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 14:32 +0000
Re: // comments and \ BartC <bc@freeuk.com> - 2015-12-01 14:52 +0000
Re: // comments and \ David Brown <david.brown@hesbynett.no> - 2015-12-01 16:15 +0100
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 15:28 +0000
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 01:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:12 -0800
Re: // comments and \ Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-01 19:17 +0000
Re: // comments and \ Robert Wessel <robertwessel2@yahoo.com> - 2015-12-01 12:32 -0600
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 00:01 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 07:08 -0800
Re: // comments and \ Nobody <nobody@nowhere.invalid> - 2015-12-02 21:05 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-02 14:22 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 14:48 -0800
Re: // comments and \ glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-02 23:37 +0000
Re: // comments and \ supercat@casperkitty.com - 2015-12-02 17:10 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-02 19:24 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-03 04:10 +0000
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:49 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-03 07:28 -0700
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 09:12 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 06:53 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 15:41 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 15:56 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 16:44 -0800
Re: // comments and \ Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-03 17:29 -0800
Re: // comments and \ supercat@casperkitty.com - 2015-12-03 19:10 -0800
Re: // comments and \ Philip Lantz <prl@canterey.us> - 2015-12-02 21:59 -0800
Re: // comments and \ Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-12-01 07:52 -0700
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 09:21 -0800
Re: // comments and \ Richard Heathfield <rjh@cpax.org.uk> - 2015-12-01 17:26 +0000
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:50 -0800
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-01 10:49 -0800
Re: // comments and \ Geoff <geoff@invalid.invalid> - 2015-12-01 11:34 -0800
Re: // comments and \ David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:44 -0500
Re: // comments and \ "Charles Richmond" <numerist@aquaporin4.com> - 2015-12-23 14:35 -0600
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 13:00 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:58 -0500
Re: // comments and \ Keith Thompson <kst-u@mib.org> - 2015-12-23 14:21 -0800
Re: // comments and \ James Kuyper <jameskuyper@verizon.net> - 2015-12-23 16:55 -0500
Re: // comments and \ Öö Tiib <ootiib@hot.ee> - 2015-12-01 12:24 -0800
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-01 12:52 +0000 |
| Subject | // comments and \ |
| Message-ID | <n3k52h$cjq$1@dont-email.me> |
This is a problem I came across with an assembler, which caused me some
trouble to sort out.
Then I thought I'd try it with C, convinced it couldn't be as silly, but
apparently it was!
Here:
// this is a comment ... \
puts("Hi!");
the continuation character at the end of the comment means the following
line isn't compiled (which can give puzzling results as you can imagine).
But, is there any reason for it to behave this way?
A // comment you would expect to ignore everything to the end of the
line, especially when it occupies the whole line. Where there are
statements at the start, then the \ is best placed before the // comment
IMO as it is part of the actual code.
(You shouldn't have to be aware of the content of a comment. Maybe
someone else wrote it. Maybe the end of it extends beyond the right edge
of the screen and you can't see the \ without scrolling; why would you?
In my case, the comment was automatically placed and it happened to have
\ at the end.)
--
Bartc
[toc] | [next] | [standalone]
| From | me <self@example.org> |
|---|---|
| Date | 2015-12-01 13:08 +0000 |
| Message-ID | <n3k651$c53$1@speranza.aioe.org> |
| In reply to | #77503 |
On 2015-12-01, BartC <bc@freeuk.com> wrote:
> // this is a comment ... \
> puts("Hi!");
>
> the continuation character at the end of the comment means the following
> line isn't compiled (which can give puzzling results as you can imagine).
I never head of this. What compiler are you using?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-12-01 08:20 -0500 |
| Message-ID | <n3k6n9$jgt$1@dont-email.me> |
| In reply to | #77504 |
On 12/1/2015 8:08 AM, me wrote:
> On 2015-12-01, BartC <bc@freeuk.com> wrote:
>> // this is a comment ... \
>> puts("Hi!");
>>
>> the continuation character at the end of the comment means the following
>> line isn't compiled (which can give puzzling results as you can imagine).
>
> I never head of this. What compiler are you using?
One that follows the C Standard, in this regard at least.
Line-splicing happens in translation phase 2; recognition of
comments in phase 3 (5.1.1.2p1, points 2 and 3). It has been
this way for over a quarter-century.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | me <self@example.org> |
|---|---|
| Date | 2015-12-01 13:36 +0000 |
| Message-ID | <n3k7or$gaf$1@speranza.aioe.org> |
| In reply to | #77506 |
On 2015-12-01, Eric Sosman <esosman@comcast-dot-net.invalid> wrote: >> I never head of this. What compiler are you using? > One that follows the C Standard, in this regard at least. Crazy! I never heard of this. But I believe you! I guess that's kind of an unusual way of commenting. You don't see it often. Thanks for sharing, pals.
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-12-01 09:03 -0500 |
| Message-ID | <n3k97s$svh$1@dont-email.me> |
| In reply to | #77507 |
On 12/1/2015 8:36 AM, me wrote:
> On 2015-12-01, Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>> I never head of this. What compiler are you using?
>> One that follows the C Standard, in this regard at least.
>
> Crazy! I never heard of this. But I believe you! I guess that's kind of an
> unusual way of commenting. You don't see it often.
(Context: // comment line ending with \ is "continued.")
You see line-splicing quite a lot in preprocessor directives,
where line boundaries have more importance than in most other
situations. Macro definitions, in particular, frequently occupy
many physical source lines but need to be combined into a single
logical line for the preprocessor's benefit.
Note that there's really no such thing as a "comment line"
in the C language: There are comments, yes, and there may even
be lines containing nothing but comments, but the comments are
not "lines" in and of themselves: They're just white space in
whatever line happens to carry them:
// This is a comment line.
int foo = 42; // Is this a "comment line?"
int bar = /* from Pub. 2214-1990 Rev. B */ 24; // This?
So, it's not a matter of having a strange continuation for "comment
lines," it's just that there's a continuation convention for *all*
lines, and comments within those lines get carried along.
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-01 14:14 +0000 |
| Message-ID | <87fuzmdznb.fsf@bsb.me.uk> |
| In reply to | #77507 |
me <self@example.org> writes: > On 2015-12-01, Eric Sosman <esosman@comcast-dot-net.invalid> wrote: >>> I never head of this. What compiler are you using? >> One that follows the C Standard, in this regard at least. > > Crazy! I never heard of this. But I believe you! I guess that's kind of an > unusual way of commenting. You don't see it often. With luck you will never see it! You should never come across it as a way of commenting something, but it helps to know the rules in case you find it by accident. It's a consequence of adding // comments into C in 1999 along with the principle of least surprise. Ever since ANSI C in 1989 (and probably earlier in some implementations) a newline preceded by a \ are ignored. This was always permitted in C #define lines, but ANSI C made it a general line-continuation mechanism to be performed before almost anything else, and just before comment removal. Thus, when // comments were added, the current behaviour was the least surprising -- certainly the behaviour that needed the fewest special-case changes to the existing words. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-01 07:40 -0800 |
| Message-ID | <63922dcf-c5cb-4aae-a271-d1fe0b450603@googlegroups.com> |
| In reply to | #77509 |
On Tuesday, December 1, 2015 at 8:14:46 AM UTC-6, Ben Bacarisse wrote: > It's a consequence of adding // comments into C in 1999 along with the > principle of least surprise. Ever since ANSI C in 1989 (and probably > earlier in some implementations) a newline preceded by a \ are ignored. > This was always permitted in C #define lines, but ANSI C made it a > general line-continuation mechanism to be performed before almost > anything else, and just before comment removal. Thus, when // comments > were added, the current behaviour was the least surprising -- certainly > the behaviour that needed the fewest special-case changes to the > existing words. I don't know about that--since "//" comments are an entirely new concept, they could just as well have been defined as being handled before anything else. If anything, doing that would have made it easier to adapt existing compiler systems, since all one would need to do is filter the source files through a utility that strips "//" comments and feed the result into an existing compiler, rather than having to handle "//" between pre-processing steps.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 08:55 -0800 |
| Message-ID | <lnvb8iun05.fsf@kst-u.example.com> |
| In reply to | #77523 |
supercat@casperkitty.com writes:
> On Tuesday, December 1, 2015 at 8:14:46 AM UTC-6, Ben Bacarisse wrote:
>> It's a consequence of adding // comments into C in 1999 along with the
>> principle of least surprise. Ever since ANSI C in 1989 (and probably
>> earlier in some implementations) a newline preceded by a \ are ignored.
>> This was always permitted in C #define lines, but ANSI C made it a
>> general line-continuation mechanism to be performed before almost
>> anything else, and just before comment removal. Thus, when // comments
>> were added, the current behaviour was the least surprising -- certainly
>> the behaviour that needed the fewest special-case changes to the
>> existing words.
>
> I don't know about that--since "//" comments are an entirely new concept,
> they could just as well have been defined as being handled before anything
> else. If anything, doing that would have made it easier to adapt existing
> compiler systems, since all one would need to do is filter the source files
> through a utility that strips "//" comments and feed the result into an
> existing compiler, rather than having to handle "//" between pre-processing
> steps.
"//" comments were not an entirely new concept. BCPL had them.
Aside from that, "//" commments have to be handled *after* string
literals and character constants are identified:
puts("// This is not a comment");
It might be possible to rearrange the translation phases (see
N1570 5.1.2.2) so that line-splicing and "//" comments interact
differently, but it would be difficult, and it would probably mean
that "//" comments and "/*...*/" comments would be processed in
different phases. The current line-splicing of "//" comments is a
problem, but a minor one, and it's likely the cure would be worse
than the disease.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-01 17:15 +0000 |
| Message-ID | <87y4deccp1.fsf@bsb.me.uk> |
| In reply to | #77523 |
supercat@casperkitty.com writes: > On Tuesday, December 1, 2015 at 8:14:46 AM UTC-6, Ben Bacarisse wrote: >> It's a consequence of adding // comments into C in 1999 along with the >> principle of least surprise. Ever since ANSI C in 1989 (and probably >> earlier in some implementations) a newline preceded by a \ are ignored. >> This was always permitted in C #define lines, but ANSI C made it a >> general line-continuation mechanism to be performed before almost >> anything else, and just before comment removal. Thus, when // comments >> were added, the current behaviour was the least surprising -- certainly >> the behaviour that needed the fewest special-case changes to the >> existing words. > > I don't know about that--since "//" comments are an entirely new concept, > they could just as well have been defined as being handled before anything > else. // comments could have been special-cased (indeed I said that) but then people who knew the existing behaviour would be surprised. If you want to avoid breaking existing code, the special cases would be non-trivial to specify. By the way, handling them before anything else sounds unwise to me since you'd interfere with trigraphs and the implementation-defined translation to the source character set. I think you mean they would be done in a new translation phase between 1 and 2. Even so, some existing conforming code would be broken. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-01 09:58 -0800 |
| Message-ID | <463ed1ae-80d5-4718-8cb9-6e0d95e3a005@googlegroups.com> |
| In reply to | #77532 |
On Tuesday, December 1, 2015 at 11:15:51 AM UTC-6, Ben Bacarisse wrote: > By the way, handling them before anything else sounds unwise to me since > you'd interfere with trigraphs and the implementation-defined > translation to the source character set. I think you mean they would be > done in a new translation phase between 1 and 2. Even so, some existing > conforming code would be broken. Actually, I meant before phase 1. A stand-alone utility which feeds each line through a simple state machine and echoes everything as it goes along unless it reaches a "strip remainder" state. As for trigraphs, I consider them a bit of silliness which from what I understand have basically never been used for production code anywhere, and any useful purpose which trigraphs might serve could be accomplished better by a utility which goes before phase 1. While there are occasions where someone might need to write C code on a system which doesn't have all the normal characters available, I don't see any need for the Standard to worry about that. Instead, have anyone who needs to work on anyone else's C code run it through a translator which turns problematic characters into whatever characters work best on *their* system, and then when working on C code (theirs or someone else's) put a pre-pre-processor in the build pipeline. If they want to share the resulting code with others, have the preprocessor apply character translations but leave // comments.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-01 18:11 +0000 |
| Message-ID | <n3knnb$oer$1@dont-email.me> |
| In reply to | #77538 |
On 01/12/15 17:58, supercat@casperkitty.com wrote: <snip> > As for trigraphs, I consider > them a bit of silliness which from what I understand have basically never > been used for production code anywhere, That has not been my experience, alas. Trigraphs are not uncommon in the mainframe world. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-12-01 10:18 -0800 |
| Message-ID | <0f4025d6-cee8-4aa9-a272-31ea09d10597@googlegroups.com> |
| In reply to | #77539 |
On Tuesday, December 1, 2015 at 12:11:21 PM UTC-6, Richard Heathfield wrote: > That has not been my experience, alas. Trigraphs are not uncommon in the > mainframe world. Any idea why? The only situation in which I could see any such thing making any sense would be if a machine didn't have backslash, and had no characters outside the C character set that could proxy for it. When I used ASCII equipment to write PL/I, the "not" character showed up on the terminal as "^" but that was far less of a hardship than writing ??- or some other such sequence would have been. I see no reason why platforms without \ shouldn't simply substitute some other character for that purpose, with the choice of substitution being based upon whatever is most convenient. Any missing characters other than \ could be handled as digraphs using \ in the same fashion as \n, \t, etc.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-01 18:20 +0000 |
| Message-ID | <n3ko9r$qrl$1@dont-email.me> |
| In reply to | #77541 |
On 01/12/15 18:18, supercat@casperkitty.com wrote: > On Tuesday, December 1, 2015 at 12:11:21 PM UTC-6, Richard Heathfield wrote: >> That has not been my experience, alas. Trigraphs are not uncommon in the >> mainframe world. > > Any idea why? I outlined one of the reasons in an earlier reply - mainframe C code is very often written and tested on PCs and then transferred over to the mainframe, but file transfer utilities don't always get the ASCII-to-EBCDIC conversion right for characters such as square brackets, so many sites use trigraphs as the obvious workaround. There is a slightly less obvious workaround, for which I refer you to that earlier reply. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 11:07 -0800 |
| Message-ID | <ln37vmugvl.fsf@kst-u.example.com> |
| In reply to | #77538 |
supercat@casperkitty.com writes:
> On Tuesday, December 1, 2015 at 11:15:51 AM UTC-6, Ben Bacarisse wrote:
>> By the way, handling them before anything else sounds unwise to me since
>> you'd interfere with trigraphs and the implementation-defined
>> translation to the source character set. I think you mean they would be
>> done in a new translation phase between 1 and 2. Even so, some existing
>> conforming code would be broken.
>
> Actually, I meant before phase 1. A stand-alone utility which feeds each
> line through a simple state machine and echoes everything as it goes along
> unless it reaches a "strip remainder" state.
[...]
To be clear, you're suggesting handling // comments before phase 1.
Phase 1 is:
Physical source file multibyte characters are mapped, in an
implementation-defined manner, to the source character set
(introducing new-line characters for end-of-line indicators)
if necessary. Trigraph sequences are replaced by corresponding
single-character internal representations.
Before phase 1, the input isn't even necessarily in the source character
set. String literals and character constants aren't identified until
phase 3, so to handle:
puts("// This is not a comment");
you'd have to recognize string literals and character constants in
phases 0 *and* 3. Phase 0 would also have to recognize trigraphs.
Would your phase 0 handle both "//" and "/*...*/" comments? It would at
least have to *recognize* "/*...*/" comments:
/* This // is a valid comment */
puts("This is not a comment");
Here's an alternative suggestion to solve the (IMHO minor) problem
of line-spliced "//" comments:
Currently, in phase 2 a backslash immediately followed by a newline
is deleted.
Proposal: Do the same thing for a backslash followed by whitespace
followed by a newline.
Proposal: Each backslash-whitespace-newline sequence, rather than
simply being deleted, is replaced by a special marker (which could be
implemented by the compiler remembering where the deletion occurred).
In phase 3, any occurrence of that marker within a // comment is
a syntax error. The marker may appear in the middle of a token,
and is otherwise ignored in this and all following phases.
The changes in behavior from the current standard would be:
1. Invisible trailing whitespace doesn't affect line splicing
(gcc and clang already behave this way).
2. Line splicing within a // comment is an unambiguous error.
It's likely such a change would affect some existing code -- but most
such code is likely incorrect anyway. The most common case is probably
Windows-style file paths at the end of // comments.
--
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 | 2015-12-01 11:39 -0800 |
| Message-ID | <eb422b03-1a96-47c3-9ccc-4e3fe2b52cd5@googlegroups.com> |
| In reply to | #77547 |
On Tuesday, December 1, 2015 at 1:08:22 PM UTC-6, Keith Thompson wrote: > To be clear, you're suggesting handling // comments before phase 1. > > Phase 1 is: > Physical source file multibyte characters are mapped, in an > implementation-defined manner, to the source character set > (introducing new-line characters for end-of-line indicators) > if necessary. Trigraph sequences are replaced by corresponding > single-character internal representations. Yup. Some compilers make it difficult to insert translation steps between other compilation phases, so allowing "//" processing to precede phase 1 would have allowed files containing such comments to be supported on such systems. That wouldn't imply that all systems would have to add an extra step--merely that the rules should be consistent with such an approach. It doesn't take much of a state machine to recognize string or character literals or /* */ comments. While I like your idea of replacing the backslash-newline with a special marker character, I'd add an additional rule which would say that use of a backslash-newline in contexts where whitespace would be significant should be deprecated.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 12:33 -0800 |
| Message-ID | <lntwo1ucwm.fsf@kst-u.example.com> |
| In reply to | #77553 |
supercat@casperkitty.com writes:
> On Tuesday, December 1, 2015 at 1:08:22 PM UTC-6, Keith Thompson wrote:
>> To be clear, you're suggesting handling // comments before phase 1.
>>
>> Phase 1 is:
>> Physical source file multibyte characters are mapped, in an
>> implementation-defined manner, to the source character set
>> (introducing new-line characters for end-of-line indicators)
>> if necessary. Trigraph sequences are replaced by corresponding
>> single-character internal representations.
>
> Yup. Some compilers make it difficult to insert translation steps between
> other compilation phases, so allowing "//" processing to precede phase 1
> would have allowed files containing such comments to be supported on such
> systems. That wouldn't imply that all systems would have to add an extra
> step--merely that the rules should be consistent with such an approach.
>
> It doesn't take much of a state machine to recognize string or character
> literals or /* */ comments. While I like your idea of replacing the
> backslash-newline with a special marker character, I'd add an additional
> rule which would say that use of a backslash-newline in contexts where
> whitespace would be significant should be deprecated.
Existing compilers don't even agree on the interpretation of the
current rules. You propose adding a whole new layer of complexity.
You would separate the procesing of "//" and "/*...*/" comments
into two different translation phases, which I find badly
counterintuitive. Among other problems, it would introduce a
whole new set of opportunities for misinterpretation of the rules.
I don't know what odd corner cases your proposal would introduce.
And your proposal breaks, or at least seriously bends, the
translation phase model, requiring certain lexical elements to be
recognized in two or more different phases.
I don't see much benefit from your proposal, except *maybe* that
some obscure constructs (that probably shouldn't appear in source
code in the first place) might be rejected.
The problem could be mostly solved by compilers issuing warnings
for certain corner cases. Clang already warns about "backslash
and newline separated by space"; other compilers could do so as well.
I proposed a different solution, changing the behavior of phases
2 and 3. I don't actually think that's necessarily a good idea;
it's just a cleaner way of handling the corner case.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-12-02 01:05 +0000 |
| Message-ID | <n3lg4j$mta$1@speranza.aioe.org> |
| In reply to | #77547 |
Keith Thompson <kst-u@mib.org> wrote: > supercat@casperkitty.com writes: >> On Tuesday, December 1, 2015 at 11:15:51 AM UTC-6, Ben Bacarisse wrote: >>> By the way, handling them before anything else sounds unwise to me since >>> you'd interfere with trigraphs and the implementation-defined (snip) > Currently, in phase 2 a backslash immediately followed by a newline > is deleted. > Proposal: Do the same thing for a backslash followed by whitespace > followed by a newline. As with trigraphs and mainframes, this is more likely useful in the mainframe world. IBM mainframe systems still often use fixed length records, such that records are blank padded to some length. If you convert files to/from fixed length records, trailing blanks are added or removed. > Proposal: Each backslash-whitespace-newline sequence, rather than > simply being deleted, is replaced by a special marker (which could be > implemented by the compiler remembering where the deletion occurred). Which we be needed if all bit patters are allowable characters. > In phase 3, any occurrence of that marker within a // comment is > a syntax error. The marker may appear in the middle of a token, > and is otherwise ignored in this and all following phases. > The changes in behavior from the current standard would be: > 1. Invisible trailing whitespace doesn't affect line splicing > (gcc and clang already behave this way). I haven't tried lately, but did they always do that? It is certainly convenient when editing with screen editors (or line editors) that don't show where the end of the line is. Also, I have used editors that remove trailing blanks on lines. > 2. Line splicing within a // comment is an unambiguous error. > It's likely such a change would affect some existing code -- but most > such code is likely incorrect anyway. The most common case is probably > Windows-style file paths at the end of // comments. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-12-01 19:30 +0000 |
| Message-ID | <87mvtuc6fi.fsf@bsb.me.uk> |
| In reply to | #77538 |
supercat@casperkitty.com writes: > On Tuesday, December 1, 2015 at 11:15:51 AM UTC-6, Ben Bacarisse wrote: >> By the way, handling them before anything else sounds unwise to me since >> you'd interfere with trigraphs and the implementation-defined >> translation to the source character set. I think you mean they would be >> done in a new translation phase between 1 and 2. Even so, some existing >> conforming code would be broken. > > Actually, I meant before phase 1. Sorry, I was being polite. I knew you meant before anything else. I was just saying that that's a bad idea. > A stand-alone utility which feeds each > line through a simple state machine and echoes everything as it goes along > unless it reaches a "strip remainder" state. But since you have to deal with multi-byte characters and trigraphs, you are not really doing that "before phase 1" you are simply duplicating the work of translation phase 1. You also have to duplicate some of the work of the lexer so that // is ignored in characters, strings and block comments and that takes you into translation phase 3. If you don't take all these thongs into account, you break existing code. All in all, even if you want to do it first (an in time -- and you certainly can), // comments belongs where there were put, in phase 3. > As for trigraphs, I consider > them a bit of silliness which from what I understand have basically never > been used for production code anywhere, I wish! Anyway, silliness or not, the committee does not have the luxury of ignoring previous language standards. Existing code has to be taken into account. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-12-01 20:59 +0100 |
| Message-ID | <n3ku2e$jn3$1@dont-email.me> |
| In reply to | #77523 |
On 01/12/15 16:40, supercat@casperkitty.com wrote:
> On Tuesday, December 1, 2015 at 8:14:46 AM UTC-6, Ben Bacarisse wrote:
>> It's a consequence of adding // comments into C in 1999 along with the
>> principle of least surprise. Ever since ANSI C in 1989 (and probably
>> earlier in some implementations) a newline preceded by a \ are ignored.
>> This was always permitted in C #define lines, but ANSI C made it a
>> general line-continuation mechanism to be performed before almost
>> anything else, and just before comment removal. Thus, when // comments
>> were added, the current behaviour was the least surprising -- certainly
>> the behaviour that needed the fewest special-case changes to the
>> existing words.
>
> I don't know about that--since "//" comments are an entirely new concept,
> they could just as well have been defined as being handled before anything
> else. If anything, doing that would have made it easier to adapt existing
> compiler systems, since all one would need to do is filter the source files
> through a utility that strips "//" comments and feed the result into an
> existing compiler, rather than having to handle "//" between pre-processing
> steps.
>
// comments were not "an entirely new concept" when introduced to C.
They were copied directly from C++, and it would have been insane to do
so in a manner that was inconsistent with C++ unless there were truly
exceptional reasons for the difference.
But the matter is simple anyway. Backslash line splicing is part of the
pre-processor, while comments ("//" and "/* */") are part of the C
language itself - obviously the backslash line splicing comes first.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-01 15:22 -0500 |
| Message-ID | <n3kve1$pt0$1@dont-email.me> |
| In reply to | #77555 |
On 12/01/2015 02:59 PM, David Brown wrote:
...
> But the matter is simple anyway. Backslash line splicing is part of the
> pre-processor, while comments ("//" and "/* */") are part of the C
> language itself - obviously the backslash line splicing comes first.
The standard never talks about the preprocessor as such, though it does
talk about pre-processing. What it mainly talks about is 8 sequential
translation phases (5.1.1.2). It does not require that those phases
occur in the specified sequence, but only that the same result be
achieved as if they were executed in that sequence.
Backslash line splicing occurs during translation phase 2.
Recognition of comments and their replacement by a single space
character occurs during translation phase 3.
Preprocessing directives are executed during translation phase 4.
If you're trying to make a distinction between the C language itself and
the preprocessing language, there's some support for that in the fact
that the standard defines two different grammars: the Lexical Grammar
which describes what is processed during translation phase 4, and the
Phrase Structure Grammar which describes what is processed during phase 8.
You could justify saying that what is implemented during phase 8 is the
language itself, but you'd have a hard time justifying distinguishing
that from preprocessing, which occurs during translation phase 4, while
including things that happen during phase 3.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web