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 | 11 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 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-01 17:26 +0000 |
| Message-ID | <n3kl4d$dhn$2@dont-email.me> |
| In reply to | #77533 |
On 01/12/15 17:21, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> 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).
> [...]
>
> It's actually a bit worse than that. Consider this program:
>
> #include <stdio.h>
> int main(void) {
> // \
> puts("This is a comment");
> puts("This is not a comment");
> }
>
> You can't see it, but there's a space after the backslash on line 3
> (assuming it's not stripped by somebody's news software). Because the
> line doesn't end with a backslash, it's not a continuation line, so the
> output *should* be:
>
> This is not a comment
It looks to me like it should be:
This is a comment
This is not a comment
Am I missing something, or did you get your logic gates in a twist?
<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 10:50 -0800 |
| Message-ID | <ln7fkyuhos.fsf@kst-u.example.com> |
| In reply to | #77535 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> It looks to me like it should be:
>
> This is a comment
> This is not a comment
>
> Am I missing something, or did you get your logic gates in a twist?
>
> <snip>
You're right, my logic gates were indeed twisted. I've posted a
correction elsethread.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-01 10:49 -0800 |
| Message-ID | <lnbnaauhpv.fsf@kst-u.example.com> |
| In reply to | #77533 |
Keith Thompson <kst-u@mib.org> writes:
> BartC <bc@freeuk.com> writes:
>> 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).
> [...]
>
> It's actually a bit worse than that. Consider this program:
>
> #include <stdio.h>
> int main(void) {
> // \
> puts("This is a comment");
> puts("This is not a comment");
> }
>
> You can't see it, but there's a space after the backslash on line 3
> (assuming it's not stripped by somebody's news software). Because the
> line doesn't end with a backslash, it's not a continuation line, so the
> output *should* be:
>
> This is not a comment
OOPS!
> tcc produces that output, but both gcc and clang ignore the trailing
> blank and produce this output:
>
> This is a comment
> This is not a comment
OOPS!
> (clang warns about the trailing space.)
>
> I prefer the gcc/clang behavior, but it's not consistent with the
> standard -- though I suppose you could argue that the trailing blanks
> could be removed in translation phase 1.
Sorry, I got that backwards. The output (if my reading of the standard
is correct) *should* be:
This is a comment
This is not a comment
When compiled with gcc or clang, the output is:
This is not a comment
> In any case, the solution is straightforward: Don't Do That.
I shouldn't post before I've had enough coffee. I expect I'll have had
enough coffee in another ten years or so.
--
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 | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-12-01 11:34 -0800 |
| Message-ID | <1ctr5btpt3aeedalgiilsvni273pmoq83d@4ax.com> |
| In reply to | #77545 |
On Tue, 01 Dec 2015 10:49:48 -0800, Keith Thompson <kst-u@mib.org>
wrote:
>Keith Thompson <kst-u@mib.org> writes:
>> BartC <bc@freeuk.com> writes:
>>> 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).
>> [...]
>>
>> It's actually a bit worse than that. Consider this program:
>>
>> #include <stdio.h>
>> int main(void) {
>> // \
>> puts("This is a comment");
>> puts("This is not a comment");
>> }
>>
>> You can't see it, but there's a space after the backslash on line 3
>> (assuming it's not stripped by somebody's news software). Because the
>> line doesn't end with a backslash, it's not a continuation line, so the
>> output *should* be:
>>
>> This is not a comment
>
>OOPS!
>
>> tcc produces that output, but both gcc and clang ignore the trailing
>> blank and produce this output:
>>
>> This is a comment
>> This is not a comment
>
>OOPS!
>
>> (clang warns about the trailing space.)
>>
>> I prefer the gcc/clang behavior, but it's not consistent with the
>> standard -- though I suppose you could argue that the trailing blanks
>> could be removed in translation phase 1.
>
>Sorry, I got that backwards. The output (if my reading of the standard
>is correct) *should* be:
>
> This is a comment
> This is not a comment
>
>When compiled with gcc or clang, the output is:
>
> This is not a comment
>
>> In any case, the solution is straightforward: Don't Do That.
>
>I shouldn't post before I've had enough coffee. I expect I'll have had
>enough coffee in another ten years or so.
FWIW, VS2010 correctly syntax colors and compiles the line
non-continuation as described above and when the space is removed the
line continuation makes the first puts call a comment with appropriate
coloring. Furthermore, the compiler emits C4010: single-line comment
contains line-continuation character when compiled at /W4.
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-12-22 06:44 -0500 |
| Message-ID | <undi7b5ct823427h92k2epmh9j1ppshvfq@4ax.com> |
| In reply to | #77533 |
On Tue, 01 Dec 2015 09:21:12 -0800, Keith Thompson <kst-u@mib.org>
wrote:
> It's actually a bit worse than that. Consider this program:
>
> #include <stdio.h>
> int main(void) {
> // \
> puts("This is a comment");
> puts("This is not a comment");
> }
>
> You can't see it, but there's a space after the backslash on line 3
> (assuming it's not stripped by somebody's news software).
<snip: compilers inconsistent; wrong description corrected later>
C90 7.9.2 and successors (all) say that for a text stream, which is
inherently at runtime in a hosted implementation, whether trailing
spaces 'appear' (or are lost/stripped) is I-D.
Nothing says C source files must be C text files. But their content is
remarkably* text-like, and except for crosscompiler or freestanding,
given that you must implement runtime text files anyway, using them
also for source files isn't obviously insane.
(* to quote Emporer Gregor of Bujold's Vorkosigan series, I don't
remember just where, "It is remarkable. I have remarked on it.")
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| Date | 2015-12-23 14:35 -0600 |
| Message-ID | <n5f0df$lfs$1@dont-email.me> |
| In reply to | #79126 |
"David Thompson" <dave.thompson2@verizon.net> wrote in message
news:undi7b5ct823427h92k2epmh9j1ppshvfq@4ax.com...
> On Tue, 01 Dec 2015 09:21:12 -0800, Keith Thompson <kst-u@mib.org>
> wrote:
>
>> It's actually a bit worse than that. Consider this program:
>>
>> #include <stdio.h>
>> int main(void) {
>> // \
>> puts("This is a comment");
>> puts("This is not a comment");
>> }
>>
>> You can't see it, but there's a space after the backslash on line 3
>> (assuming it's not stripped by somebody's news software).
>
> <snip: compilers inconsistent; wrong description corrected later>
>
> C90 7.9.2 and successors (all) say that for a text stream, which is
> inherently at runtime in a hosted implementation, whether trailing
> spaces 'appear' (or are lost/stripped) is I-D.
>
> Nothing says C source files must be C text files. But their content is
> remarkably* text-like, and except for crosscompiler or freestanding,
> given that you must implement runtime text files anyway, using them
> also for source files isn't obviously insane.
>
ISTM that the C standard (maybe all of them) allowed certain control
characters in C source files. In the past, people I know have embedded
control-L to cause a form feed when the source is printed out. I think
there are a few other control characters allowed.
This might still be considered a text file I suppose.
--
numerist at aquaporin4 dot com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-23 13:00 -0800 |
| Message-ID | <lnfuys519l.fsf@kst-u.example.com> |
| In reply to | #79169 |
"Charles Richmond" <numerist@aquaporin4.com> writes:
> "David Thompson" <dave.thompson2@verizon.net> wrote in message
> news:undi7b5ct823427h92k2epmh9j1ppshvfq@4ax.com...
>> On Tue, 01 Dec 2015 09:21:12 -0800, Keith Thompson <kst-u@mib.org>
>> wrote:
>>> It's actually a bit worse than that. Consider this program:
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> // \
>>> puts("This is a comment");
>>> puts("This is not a comment");
>>> }
>>>
>>> You can't see it, but there's a space after the backslash on line 3
>>> (assuming it's not stripped by somebody's news software).
>>
>> <snip: compilers inconsistent; wrong description corrected later>
>>
>> C90 7.9.2 and successors (all) say that for a text stream, which is
>> inherently at runtime in a hosted implementation, whether trailing
>> spaces 'appear' (or are lost/stripped) is I-D.
>>
>> Nothing says C source files must be C text files. But their content is
>> remarkably* text-like, and except for crosscompiler or freestanding,
>> given that you must implement runtime text files anyway, using them
>> also for source files isn't obviously insane.
>
> ISTM that the C standard (maybe all of them) allowed certain control
> characters in C source files. In the past, people I know have embedded
> control-L to cause a form feed when the source is printed out. I think
> there are a few other control characters allowed.
>
> This might still be considered a text file I suppose.
The characters allowed in a C source file are the members of the
*source character set*, which includes the *basic source character
set* as a subset. The basic source character set includes the
horizontal tab, vertical tab, and form feed control characters,
all of which are white space characters.
Members of the source character set outside the basic source
character set are implementation-defined, and might include
additional control characters. In addition, physical source
characters are mapped to the source character set in an
implementation-defined manner in translation phase 1.
This is described in N1570 section 5.2.1 and 5.1.1.2.
None of this is necessarily relevant to the issue being discussed.
Possibly translation phase 1 *might* remove trailing spaces, but
it's not entirely clear that it's allowed to do so. The standard
says that physical source characters are "mapped" to the source
character set; I'm not sure what that mapping is permitted to do.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-23 16:58 -0500 |
| Message-ID | <567B191B.4060408@verizon.net> |
| In reply to | #79170 |
On 12/23/2015 04:00 PM, Keith Thompson wrote: ... > ... The standard > says that physical source characters are "mapped" to the source > character set; I'm not sure what that mapping is permitted to do. The only relevant requirement I could identify is that it must be implementation-defined (5.1.1.2p1).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-23 14:21 -0800 |
| Message-ID | <ln8u4k4xi3.fsf@kst-u.example.com> |
| In reply to | #79172 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 12/23/2015 04:00 PM, Keith Thompson wrote:
> ...
>> ... The standard
>> says that physical source characters are "mapped" to the source
>> character set; I'm not sure what that mapping is permitted to do.
>
> The only relevant requirement I could identify is that it must be
> implementation-defined (5.1.1.2p1).
It also says they're "mapped".
If an implementation removes trailing spaces following a backslash in
translation phase 1, is that a "mapping"?
Here's the requirement (N1570 5.1.1.2p1):
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.
One plausible interpretation of that is that each multibyte character
is replaced by a specific member of the source character set.
There could be a function that takes (some representation of) a
multibyte character as an argument, and returns a source character,
with that function being applied to each input character. Such an
interpretation would not permit mapping spaces to spaces in most
contexts, but mapping spaces to nothing at the end of a line.
I'm not saying that's the only correct interpretation.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-12-23 16:55 -0500 |
| Message-ID | <567B1854.3030006@verizon.net> |
| In reply to | #79169 |
On 12/23/2015 03:35 PM, Charles Richmond wrote: > > "David Thompson" <dave.thompson2@verizon.net> wrote in message > news:undi7b5ct823427h92k2epmh9j1ppshvfq@4ax.com... >> C90 7.9.2 and successors (all) say that for a text stream, which is >> inherently at runtime in a hosted implementation, whether trailing >> spaces 'appear' (or are lost/stripped) is I-D. >> >> Nothing says C source files must be C text files. But their content is >> remarkably* text-like, and except for crosscompiler or freestanding, >> given that you must implement runtime text files anyway, using them >> also for source files isn't obviously insane. >> > > ISTM that the C standard (maybe all of them) allowed certain control > characters in C source files. In the past, people I know have embedded > control-L to cause a form feed when the source is printed out. I think > there are a few other control characters allowed. "... the basic source ... character set shall have the following members: ... control characters representing horizontal tab, vertical tab, and form feed. ... If any other characters are encountered in a source file (except in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token), the behavior is undefined." (5.2.1p3) Note in particular that "In the basic execution character set, there shall be control characters representing alert, backspace, carriage return, and new line." (5.2.1p3), and none of those characters are part of the basic source character set. Their presence in any construct other than the listed exceptions would therefore have undefined behavior. Whether they are allowed in identifiers is implementation-defined (6.4.2.1p3), but any control character that is in the extended source character set may be used inside any of the other exceptions. > This might still be considered a text file I suppose. The standard uses the term "text file" in many contexts, but never defines the term. It does define "text stream" in 7.21.2p1 and says that "A stream is associated with an external file" in 7.21.3p1, so a text file is presumably the file associated with a text stream. The standard imposes no requirements on the contents of a text file. However, it makes a promise about text streams: "Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character." (7.21.2p2) Comparing these things requires that there be a correspondence between the source character set referred to in 5.2.1p3, and the execution character set referred to in 7.21.2p2. "Each source character set member and escape sequence in character constants and string literals is converted to the corresponding member of the execution character set; if there is no corresponding member, it is converted to an implementation-defined member other than the null (wide) character." (5.1.1.2p5). My comments below comparing the meaning of those two clauses are to be understood in terms of that conversion. Note that this comparison cannot be meaningfully applied to any source code character for which the last clause of 5.1.1.2p5 applies. Source code files that avoid the undefined behavior mentioned in 5.2.1p3 are similar to files that meet the requirements for the guarantee provided by 7.21.2p2, but a detailed comparison shows some key differences: A file with a space character immediately preceding a newline violates the requirement for 7.21.2p2, but doesn't make the behavior undefined for a source code file. Source code files containing printable characters from the extended character set make the behavior undefined, but as text files, the guarantee provided by 7.21.2p2 still applies. Source code files can contain members of the source character set not listed in 5.2.1p3 without having undefined behavior, so long as they occur only in one of the exceptions listed in that clause. However, unless those characters are printable, they violate the requirements for 7.21.2p2. You didn't expect this to be simple, I hope? :-}
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2015-12-01 12:24 -0800 |
| Message-ID | <3b2e86dc-14ea-487a-80d5-a68111d7c1a3@googlegroups.com> |
| In reply to | #77503 |
On Tuesday, 1 December 2015 14:53:03 UTC+2, Bart wrote:
> 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!");
More classical example of it is with trigraph:
// Why next line does nothing???/
puts("Hi!");
[toc] | [prev] | [standalone]
Page 8 of 8 — ← Prev page 1 2 3 4 5 6 7 [8]
Back to top | Article view | comp.lang.c
csiph-web