hagerman@ece.cmu.edu (John Hagerman) (11/08/90)
Why didn't // ... newline comments make it into ANSI C? - John -- hagerman@ece.cmu.edu
gwyn@smoke.brl.mil (Doug Gwyn) (11/09/90)
In article <HAGERMAN.90Nov7193212@rx7.ece.cmu.edu> hagerman@ece.cmu.edu (John Hagerman) writes: >Why didn't // ... newline comments make it into ANSI C? They weren't in the base document, and one style of comment was deemed to be sufficient. (Note: I once added support for this feature to the Ritchie PDP-11 compiler that I maintained, and when a new non-PDP-11 computer was acquired just after I left, the staff at that company was tasked with either hacking support for // comments into the new compiler and indeed, into every future compiler they might have to use, or else converting all the sources into normal C comment style. Fortunately I had left them with a utility for automatically performing such conversion, based on an FSA. (It was non-trivial, due to \, ', and " handling.) Thus, you know that I must like // comments, but on the other hand I learned a lesson.)
rex@aussie.COM (Rex Jaeschke) (11/10/90)
> In article <HAGERMAN.90Nov7193212@rx7.ece.cmu.edu> hagerman@ece.cmu.edu (John Hagerman) writes: > >Why didn't // ... newline comments make it into ANSI C? > Let me suggest that you CANNOT add // comments to an ANSI C compiler WITHOUT some hacking. Consider the following example: int i; // this comment ends in a backslash \ int j; f() { i = j; /* error: j is not declared */ } ANSI's phases of translation require that backslash/new-lines be processed BEFORE comments. In this case the 2 declaration lines would become: int i; // this comment ends in a backslash int j; and the declaration of j would be treated as part of the comment. So, for a future version of ANSI C to adopt //, they would have to either rearrange the phases of translation (unlikely since that would no longer be backwards compatible) or to treat // and /**/ comments differently and add a new phase for //. Rex ---------------------------------------------------------------------------- Rex Jaeschke | Journal of C Language Translation | C Users Journal (703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal ---------------------------------------------------------------------------- Convener of the Numerical C Extensions Group (NCEG) ----------------------------------------------------------------------------
henry@zoo.toronto.edu (Henry Spencer) (11/14/90)
In article <48.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes: >Let me suggest that you CANNOT add // comments to an ANSI C compiler >WITHOUT some hacking. Consider the following example: > >int i; // this comment ends in a backslash \ >int j; > ... >So, for a future version of ANSI C to adopt //, they would have to >either rearrange the phases of translation (unlikely since that would >no longer be backwards compatible) or to treat // and /**/ comments >differently and add a new phase for //. Um, why? In ANSI C, this program fragment is illegal -- a syntax error -- and the standard does not constrain responses to syntax errors. If // comments were added, some programs that are now syntactically erroneous would become legal, but that is true of many types of extension. I don't see the problem. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
wald@theory.lcs.mit.edu (David Wald) (11/14/90)
In article <48.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes: >> In article <HAGERMAN.90Nov7193212@rx7.ece.cmu.edu> hagerman@ece.cmu.edu (John Hagerman) writes: >> >Why didn't // ... newline comments make it into ANSI C? >> > >Let me suggest that you CANNOT add // comments to an ANSI C compiler >WITHOUT some hacking. Consider the following example: > >int i; // this comment ends in a backslash \ >int j; > >f() >{ > i = j; /* error: j is not declared */ >} > >ANSI's phases of translation require that backslash/new-lines be >processed BEFORE comments. In this case the 2 declaration lines would >become: > >int i; // this comment ends in a backslash int j; How much of a problem would this be? It would mean that \\\n behaves the same in comments as outside them, but that is already the case. What do BCPL or C++ do with a comment like this? -David -- ============================================================================ David Wald wald@theory.lcs.mit.edu ============================================================================
lewine@cheshirecat.rtp.dg.com (Donald Lewine) (11/14/90)
In article <48.UUL1.3#5077@aussie.COM>, rex@aussie.COM (Rex Jaeschke) writes: |> |> So, for a future version of ANSI C to adopt //, they would have to |> either rearrange the phases of translation (unlikely since that would |> no longer be backwards compatible) or to treat // and /**/ comments |> differently and add a new phase for //. Or say, "// comments may be continued using \, as in // This is a comment \ and so it this. I am not saying that continuing // comments is a good idea, merely that it is possible without out major rework to the structure of the compiler. -------------------------------------------------------------------- Donald A. Lewine (508) 870-9008 Voice Data General Corporation (508) 366-0750 FAX 4400 Computer Drive. MS D112A Westboro, MA 01580 U.S.A. uucp: uunet!dg!lewine Internet: lewine@cheshirecat.webo.dg.com
peter@ficc.ferranti.com (Peter da Silva) (11/16/90)
In article <48.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes: > ANSI's phases of translation require that backslash/new-lines be > processed BEFORE comments. Why? Makes sense for me for comment processing to come first, before anything else. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
bright@nazgul.UUCP (Walter Bright) (11/16/90)
In article <48.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes:
/int i; // this comment ends in a backslash \
/int j;
/ANSI's phases of translation require that backslash/new-lines be
/processed BEFORE comments. In this case the 2 declaration lines would
/become:
/int i; // this comment ends in a backslash int j;
/So, for a future version of ANSI C to adopt //, they would have to
/either rearrange the phases of translation (unlikely since that would
/no longer be backwards compatible) or to treat // and /**/ comments
/differently and add a new phase for //.
There was some debate about this on BIX a while back. The consensus seemed
to be that the phases of translation were not modified to support //
comments. If you had a // comment that ended in a \, then the line got
spliced and the next line became part of the comment.
This is not a very onerous burden, if it really bugs someone they could always
use /* */ comments (in macros is where this problem crops up).flaps@dgp.toronto.edu (Alan J Rosenthal) (11/16/90)
>In article <48.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes: >> ANSI's phases of translation require that backslash/new-lines be >> processed BEFORE comments. peter@ficc.ferranti.com (Peter da Silva) writes: >Why? > >Makes sense for me for comment processing to come first, before >anything else. What about /\ * this, which is a comment? */ Backslash-newline removal must come first.
henry@zoo.toronto.edu (Henry Spencer) (11/17/90)
In article <I4=67D4@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> ANSI's phases of translation require that backslash/new-lines be >> processed BEFORE comments. > >Why? >Makes sense for me for comment processing to come first, before >anything else. The intent is that it be possible to split lines mechanically, e.g. to deal with machines with stupid line-length limits, and hence it is desirable to have backslash-newline processing first so that you don't have to tokenize the source to decide where line breaks are safe. -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
bhoughto@cmdnfs.intel.com (Blair P. Houghton) (11/17/90)
In article <I4=67D4@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <48.UUL1.3#5077@aussie.COM> rex@aussie.COM (Rex Jaeschke) writes: >> ANSI's phases of translation require that backslash/new-lines be >> processed BEFORE comments. > >Why? >Makes sense for me for comment processing to come first, before >anything else. Okay, then. Who wants to through all my system header files and remove all the comments? --Blair "#realize"
gwyn@smoke.brl.mil (Doug Gwyn) (11/17/90)
In article <1015@inews.intel.com> bhoughto@cmdnfs.intel.com (Blair P. Houghton) writes: >In article <I4=67D4@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >>Makes sense for me for comment processing to come first, before >>anything else. >Okay, then. Who wants to through all my system header files and >remove all the comments? What in the world does your use of comments look like that it would run afoul of the standard phases of translation?
steve@taumet.com (Stephen Clamage) (11/18/90)
wald@theory.lcs.mit.edu (David Wald) writes: >How much of a problem would this be? It would mean that \\\n behaves >the same in comments as outside them, but that is already the case. >What do BCPL or C++ do with a comment like this? We don't have an actual standard for C++ yet, but E&S specifies (16.1) that trigraphs and escaped newlines are processed before comments. This is the same as in ANSI C, except that C++ also has the //-style comment. If ANSI C were to adopt //-style comments, I assume it would use the same rule, since anything else would violate the existing phases of translation. The idea is to allow machine-generated code to fold at any convenient point on systems with line-length limitations, and not have to parse the code to figure out where was a safe place. -- Steve Clamage, TauMetric Corp, steve@taumet.com
peter@ficc.ferranti.com (Peter da Silva) (11/20/90)
In article <1990Nov16.172018.19638@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > The intent is that it be possible to split lines mechanically, e.g. to deal > with machines with stupid line-length limits, and hence it is desirable to > have backslash-newline processing first so that you don't have to tokenize > the source to decide where line breaks are safe. Ok, that makes sense. Well in that case what's the problem with // .... .... \ .... ... being a comment? If /\ * ... .... ... */ is accepted, anything goes... -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com