Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #147711 > unrolled thread

curiosity about compiler phases

Back to article view | Back to comp.lang.c

Contents

  curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-07 05:28 -0800
    Re: curiosity about compiler phases Nick Bowler <nbowler@draconx.ca> - 2019-11-22 19:25 +0000
    Re: curiosity about compiler phases "A. K." <minforth@arcor.de> - 2019-11-22 12:19 -0800
    Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-22 22:22 +0000
      Typo? (Was: curiosity about compiler phases) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-22 22:34 +0000
        Re: Typo? (Was: curiosity about compiler phases) Bart <bc@freeuk.com> - 2019-11-22 23:49 +0000
          Re: Typo? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-22 19:26 -0700
      Re: curiosity about compiler phases scott@slp53.sl.home (Scott Lurndal) - 2019-11-22 23:12 +0000
        Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 00:06 +0000
          Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-22 20:34 -0500
          Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-23 01:47 +0000
            Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-22 21:21 -0500
              Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-24 03:26 +0000
                Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-24 11:29 +0000
                  Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-24 16:49 +0000
            Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 12:21 +0000
              Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-23 10:08 -0500
              Re: curiosity about compiler phases scott@slp53.sl.home (Scott Lurndal) - 2019-11-23 15:49 +0000
                Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 16:21 +0000
                  Re: curiosity about compiler phases Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-24 03:37 +0000
                    Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-24 11:25 +0000
                      Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-25 14:06 +0000
      Re: curiosity about compiler phases Keith Thompson <kst-u@mib.org> - 2019-11-22 21:25 -0800
        Beyond our pay grade (Was: curiosity about compiler phases) gazelle@shell.xmission.com (Kenny McCormack) - 2019-11-23 07:43 +0000
      Re: curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-23 06:28 -0800
        Re: curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-23 06:39 -0800
        Re: curiosity about compiler phases Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2019-11-23 09:46 -0500
          Re: curiosity about compiler phases Richard Damon <Richard@Damon-Family.org> - 2019-11-23 10:16 -0500
        Re: curiosity about compiler phases Bart <bc@freeuk.com> - 2019-11-23 16:13 +0000
          Re: curiosity about compiler phases Thiago Adams <thiago.adams@gmail.com> - 2019-11-25 03:24 -0800
    Re: curiosity about compiler phases Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-23 08:43 +0100

Page 1 of 2  [1] 2  Next page →

#147711 — curiosity about compiler phases

I am doing some review in my lexer and I found the following 
curiosity when I was experimenting compiler explorer online.

When I print the preprocessor output -E of this code:

in\
t i =09;

using x86-64 gcc 4.4.7, it prints:
int i =09;

using x86-64 gcc 4.6.4, it prints:
int
  i =09;

after version 4.6.4 it is printing a new line.

The standard says: 
"Each instance of a backslash character (\) immediately followed 
by a new-line character is deleted, splicing physical source lines 
to form logical source lines."

clang and msvc outputs without new line.

others like 6502 cc65 2.17 prints an space.

I also did this test to see if the compiler would see the macro
ABC

#define ABC "abc"


int main()
{
  printf("%s", AB\
C);

}

it worked in gcc.
the -E output in gcc for this is:

int main()
{
  printf("%s", "abc"
 );

}
clang and others put ) at the same line.

the other thing I was trying to see is if the error where reported 
from physical lines or logical lines.

Then I tried:

int i = 0\
1\
2\
9;

and the compilers report physical lines, or in other words, the line
where your cursor is when you edit.
<4:1> error: invalid digit '9' in octal constant


This is another curiosity

   //test \
   a
in this case a is part of the comment, unless you put an
extra space after \


clang has:
warning: backslash and newline separated by space [-Wbackslash-newline-escape]

The other curiosity I found reading (implementing) lexical part
is about hexadecimal floating constant and binary-exponent-part.
Why someone would use this?


 

[toc] | [next] | [standalone]

#148122

On Thu, 07 Nov 2019 05:28:48 -0800, Thiago Adams wrote:
> I am doing some review in my lexer and I found the following 
> curiosity when I was experimenting compiler explorer online.
> 
> When I print the preprocessor output -E of this code:
> 
> in\
> t i =09;
> 
> using x86-64 gcc 4.4.7, it prints:
> int i =09;
> 
> using x86-64 gcc 4.6.4, it prints:
> int
>   i =09;
> 
> after version 4.6.4 it is printing a new line.
> 
> The standard says: 
> "Each instance of a backslash character (\) immediately followed 
> by a new-line character is deleted, splicing physical source lines 
> to form logical source lines."

The standard has nothing to say about the output of operating modes
like gcc -E.  It only describes complete implementations which include
all the translation phases and the execution environment.

I suspect gcc does it this way so that line and column numbers are
preserved to the greatest extent possible in the output.  This is
important for the purposes of diagnostic messages when the gcc -E
output is passed back into gcc.  Since the int token was correctly
formed as if the backspace and the newline were deleted we can expect
the complete implementation will behave as required by the standard.

I notice that (as you observe) older gcc does not emit a newline in the
middle of the declaration but what it does do is emit blank lines after
the deleted newlines.  So when feeding gcc -E output back into gcc, it
is likely that these old versions will have worse diagnostics for issues
generated by the declaration itself but everything after that will be OK.

[toc] | [prev] | [next] | [standalone]

#148123

Am Donnerstag, 7. November 2019 14:28:59 UTC+1 schrieb Thiago Adams:
> 
> The other curiosity I found reading (implementing) lexical part
> is about hexadecimal floating constant and binary-exponent-part.
> Why someone would use this?

Decimal floating-point number representations are only approximations
(in most cases) of what is actually stored in 64 bits (for doubles).
Try to figure out how the number 0.3 is actually stored in memory.

Hex or binary representations map memory content exactly. This is
sometimes desired, f.ex. when working with boxed data types. 

[toc] | [prev] | [next] | [standalone]

#148124

On 07/11/2019 13:28, Thiago Adams wrote:
> I am doing some review in my lexer and I found the following
> curiosity when I was experimenting compiler explorer online.
> 
> When I print the preprocessor output -E of this code:
> 
> in\
> t i =09;
> 
> using x86-64 gcc 4.4.7, it prints:
> int i =09;
> 
> using x86-64 gcc 4.6.4, it prints:
> int
>    i =09;

Every so often you come across crazy things that C allows in its 
preprocessor; this is one of them. Not just being able to split up lines 
between tokens, but even in the middle of tokens!

So you could in theory write C programs one character per line, or write 
numbers like this:

   a = 1\
000\
000;

giving it numeric separators. Another one is being able to use macros as 
part of #include lines. But the way it does that is staggeringly crass:

  #define STAT  <sys/stat.h>
  #include STAT

This works (some compilers allow spaces around / etc), but is done by 
concatenating tokens "sys", "/", "stat", "." and "h". Here:

  #include FILE <A123.456.789>
  #include FILE

The filename is formed (with bcc anyway) with the three tokens A123, 
.456 and .789, the last two floating point constants.


With the line continuation in the middle of tokens, I simply took the 
decision that is was too ridiculous to implement. The fewer compilers 
that pander to it, the less likely it is that any programs will come to 
depend on it.

[toc] | [prev] | [next] | [standalone]

#148125 — Typo? (Was: curiosity about compiler phases)

In article <FcZBF.211$rX6.122@fx22.am4>, Bart  <bc@freeuk.com> wrote:
...
>
>  #include FILE <A123.456.789>

Did you mean #define ?

>  #include FILE

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/God

[toc] | [prev] | [next] | [standalone]

#148127 — Re: Typo? (Was: curiosity about compiler phases)

On 22/11/2019 22:34, Kenny McCormack wrote:
> In article <FcZBF.211$rX6.122@fx22.am4>, Bart  <bc@freeuk.com> wrote:
> ...
>>
>>   #include FILE <A123.456.789>
> 
> Did you mean #define ?

Yes. All my examples are tested but I don't always bother to copy and paste.

[toc] | [prev] | [next] | [standalone]

#148132 — Re: Typo?

Bart <bc@freeuk.com> writes:

> On 22/11/2019 22:34, Kenny McCormack wrote:
>> In article <FcZBF.211$rX6.122@fx22.am4>, Bart  <bc@freeuk.com> wrote:
>> ...
>>>
>>>   #include FILE <A123.456.789>
>>
>> Did you mean #define ?
>
> Yes. All my examples are tested but I don't always bother to copy and paste.

So your examples, as presented, are not always tested.

[toc] | [prev] | [next] | [standalone]

#148126

Bart <bc@freeuk.com> writes:
>On 07/11/2019 13:28, Thiago Adams wrote:
>> I am doing some review in my lexer and I found the following
>> curiosity when I was experimenting compiler explorer online.
>> 
>> When I print the preprocessor output -E of this code:
>> 
>> in\
>> t i =09;
>> 
>> using x86-64 gcc 4.4.7, it prints:
>> int i =09;
>> 
>> using x86-64 gcc 4.6.4, it prints:
>> int
>>    i =09;
>
>Every so often you come across crazy things that C allows in its 
>preprocessor; this is one of them. Not just being able to split up lines 
>between tokens, but even in the middle of tokens!

Not all crazy.  Simply unix standard line continuation.

[toc] | [prev] | [next] | [standalone]

#148128

On 22/11/2019 23:12, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 07/11/2019 13:28, Thiago Adams wrote:
>>> I am doing some review in my lexer and I found the following
>>> curiosity when I was experimenting compiler explorer online.
>>>
>>> When I print the preprocessor output -E of this code:
>>>
>>> in\
>>> t i =09;
>>>
>>> using x86-64 gcc 4.4.7, it prints:
>>> int i =09;
>>>
>>> using x86-64 gcc 4.6.4, it prints:
>>> int
>>>     i =09;
>>
>> Every so often you come across crazy things that C allows in its
>> preprocessor; this is one of them. Not just being able to split up lines
>> between tokens, but even in the middle of tokens!
> 
> Not all crazy.  Simply unix standard line continuation.
> 

That figures. C and Unix share a few crazy things.

Where a language has line continuation to split source across multiple 
lines, then it is highly unusual to allow that split in the middle of a 
token.

What is the purpose other than it was just a side effect of the way the 
first C preprocessor happened to be thrown together? I've never come 
across any programs that rely on it.

The 3 syntax highlighting editors I've just tried don't support it either.

It would also be a very poor program that relies on code such as the 
following:

prin\
t

prin\
t

     prin\
t

(One of these has an extra space between 'n' and 't'.)

Line continuation is hardly needed in C anyway, because lines naturally 
continue (only needed inside macro defs). So it is really token 
continuation for keywords, identifiers and numeric constants too long to 
comfortable fit on one line.

In other words, it's a 'feature' that deserves to be taken out and shot.

[toc] | [prev] | [next] | [standalone]

#148130

On 11/22/19 7:06 PM, Bart wrote:
> On 22/11/2019 23:12, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 07/11/2019 13:28, Thiago Adams wrote:
>>>> I am doing some review in my lexer and I found the following
>>>> curiosity when I was experimenting compiler explorer online.
>>>>
>>>> When I print the preprocessor output -E of this code:
>>>>
>>>> in\
>>>> t i =09;
>>>>
>>>> using x86-64 gcc 4.4.7, it prints:
>>>> int i =09;
>>>>
>>>> using x86-64 gcc 4.6.4, it prints:
>>>> int
>>>>     i =09;
>>>
>>> Every so often you come across crazy things that C allows in its
>>> preprocessor; this is one of them. Not just being able to split up lines
>>> between tokens, but even in the middle of tokens!
>>
>> Not all crazy.  Simply unix standard line continuation.
>>
> 
> That figures. C and Unix share a few crazy things.
> 
> Where a language has line continuation to split source across multiple
> lines, then it is highly unusual to allow that split in the middle of a
> token.
> 
> What is the purpose other than it was just a side effect of the way the
> first C preprocessor happened to be thrown together? I've never come
> across any programs that rely on it.
> 
> The 3 syntax highlighting editors I've just tried don't support it either.
> 
> It would also be a very poor program that relies on code such as the
> following:
> 
> prin\
> t
> 
> prin\
> t
> 
>     prin\
> t
> 
> (One of these has an extra space between 'n' and 't'.)
> 
> Line continuation is hardly needed in C anyway, because lines naturally
> continue (only needed inside macro defs). So it is really token
> continuation for keywords, identifiers and numeric constants too long to
> comfortable fit on one line.
> 
> In other words, it's a 'feature' that deserves to be taken out and shot.
> 

I would think you would understand the use of it, it is primarily for
machine generated code, perhaps with a fixed record length for the
lines. If the C code generate approached the line limit, it just needed
to output the \ then a new line, and not worry about needing to buffer
stuff so it could go back to the last token break to insert the line
continuation. (and if it did that, it generally wouldn't need to use the
line continuation code as the end of line doesn't become an end of
statement.

Also, I don't believe early C had automatic string concatination, where
you can go "string" " more string" tg be the same as
"string more string", so long string constants needed this ability, as
well as for long macro definitions.

[toc] | [prev] | [next] | [standalone]

#148131

Bart <bc@freeuk.com> writes:

> Where a language has line continuation to split source across multiple
> lines, then it is highly unusual to allow that split in the middle of
> a token.

It's a comparatively rare feature altogether, but I don't think the
balance between the two ways of doing it it quite as dramatic as you
suggest.  In C, C++ and Fortran, line continuations are simply literal
line pasting, but what languages don't do it that way?  I think Python
and Visual Basic are two, but are there lots more?

In my view, if you are going to do it, doing it simply and entirely
literally makes it both easy to document and the more broadly useful.

> What is the purpose

It was useful whenever C was used in line-length limited contexts.  I've
seen it used when transmitting C over some early messaging systems, and
I imagine it was (any maybe still is) useful where file systems impose
fixed-length records.  The line breaking and reconstruction can be done
without any knowledge of tokens.

> other than it was just a side effect of the way the first C
> preprocessor happened to be thrown together?

Unlikely, since the mechanism you've been talking about was not in early
C.  I think it was first standardised (in the form that bothers you), by
ANSI C.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148133

On 11/22/19 8:47 PM, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> Where a language has line continuation to split source across multiple
>> lines, then it is highly unusual to allow that split in the middle of
>> a token.
> 
> It's a comparatively rare feature altogether, but I don't think the
> balance between the two ways of doing it it quite as dramatic as you
> suggest.  In C, C++ and Fortran, line continuations are simply literal
> line pasting, but what languages don't do it that way?  I think Python
> and Visual Basic are two, but are there lots more?
> 
> In my view, if you are going to do it, doing it simply and entirely
> literally makes it both easy to document and the more broadly useful.
> 
>> What is the purpose
> 
> It was useful whenever C was used in line-length limited contexts.  I've
> seen it used when transmitting C over some early messaging systems, and
> I imagine it was (any maybe still is) useful where file systems impose
> fixed-length records.  The line breaking and reconstruction can be done
> without any knowledge of tokens.
> 
>> other than it was just a side effect of the way the first C
>> preprocessor happened to be thrown together?
> 
> Unlikely, since the mechanism you've been talking about was not in early
> C.  I think it was first standardised (in the form that bothers you), by
> ANSI C.
> 

My memory was that K&R vintage had the continuation for strings and
macros, but did not have had it for mid-token.

I think its use mid-token just happens to fall out of the phases of
translation that was the method used to describe the language in the
standard. The second step (after character mapping) is line splicing.
This is needed to handle the old style long string handling, which to
make it work right requires just removing them (and not adding a white
space), which yields the ability to continue a token on the next line.

It would be more complicated to prevent this from happening, it would
require tokenizing before line splicing, but also you would then need
something more complicated to describe how to tokenize, as strings
tokens now might include a line break that has been escaped by the
backslash.

[toc] | [prev] | [next] | [standalone]

#148147

Richard Damon <Richard@Damon-Family.org> writes:

> On 11/22/19 8:47 PM, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> Where a language has line continuation to split source across multiple
>>> lines, then it is highly unusual to allow that split in the middle of
>>> a token.
>> 
>> It's a comparatively rare feature altogether, but I don't think the
>> balance between the two ways of doing it it quite as dramatic as you
>> suggest.  In C, C++ and Fortran, line continuations are simply literal
>> line pasting, but what languages don't do it that way?  I think Python
>> and Visual Basic are two, but are there lots more?
>> 
>> In my view, if you are going to do it, doing it simply and entirely
>> literally makes it both easy to document and the more broadly useful.
>> 
>>> What is the purpose
>> 
>> It was useful whenever C was used in line-length limited contexts.  I've
>> seen it used when transmitting C over some early messaging systems, and
>> I imagine it was (any maybe still is) useful where file systems impose
>> fixed-length records.  The line breaking and reconstruction can be done
>> without any knowledge of tokens.
>> 
>>> other than it was just a side effect of the way the first C
>>> preprocessor happened to be thrown together?
>> 
>> Unlikely, since the mechanism you've been talking about was not in early
>> C.  I think it was first standardised (in the form that bothers you), by
>> ANSI C.
>
> My memory was that K&R vintage had the continuation for strings and
> macros, but did not have had it for mid-token.

Yes, that's my impression too.  (You can, if you like, consider the
string case to be quite different.  It's really just another escape
sequence.  While \n maps to a newline, \<newline> maps to nothing.)

> I think its use mid-token just happens to fall out of the phases of
> translation that was the method used to describe the language in the
> standard.

It does, but I would be surprised if it had not been more deliberate
that you make it sound!

> The second step (after character mapping) is line splicing.
> This is needed to handle the old style long string handling, which to
> make it work right requires just removing them (and not adding a white
> space), which yields the ability to continue a token on the next line.
>
> It would be more complicated to prevent this from happening, it would
> require tokenizing before line splicing, but also you would then need
> something more complicated to describe how to tokenize, as strings
> tokens now might include a line break that has been escaped by the
> backslash.

I don't think the string case is complicated.  Strings need to have
escape sequences mapped anyway.

-- 
Ben.
 

[toc] | [prev] | [next] | [standalone]

#148149

On 24/11/2019 03:26, Ben Bacarisse wrote:
> Richard Damon <Richard@Damon-Family.org> writes:

>> It would be more complicated to prevent this from happening, it would
>> require tokenizing before line splicing, but also you would then need
>> something more complicated to describe how to tokenize, as strings
>> tokens now might include a line break that has been escaped by the
>> backslash.
> 
> I don't think the string case is complicated.  Strings need to have
> escape sequences mapped anyway.

It's more complicated because you have to deal with this:

   ABC\\*\*nDEF

where * represents an actual newline (eg. lf or cr, lf). So nested escapes.

(Although it's possible that that wasn't supported; maybe you couldn't 
have a line break in the middle of an escape sequence.)

[toc] | [prev] | [next] | [standalone]

#148151

Bart <bc@freeuk.com> writes:

> On 24/11/2019 03:26, Ben Bacarisse wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>
>>> It would be more complicated to prevent this from happening, it would
>>> require tokenizing before line splicing, but also you would then need
>>> something more complicated to describe how to tokenize, as strings
>>> tokens now might include a line break that has been escaped by the
>>> backslash.
>>
>> I don't think the string case is complicated.  Strings need to have
>> escape sequences mapped anyway.
>
> It's more complicated because you have to deal with this:
>
>   ABC\\*\*nDEF
>
> where * represents an actual newline (eg. lf or cr, lf). So nested
> escapes.

No, as a string ("ABC\\
\
nDEF") is not valid in K&R C.

> (Although it's possible that that wasn't supported; maybe you couldn't
> have a line break in the middle of an escape sequence.)

Quite.  It wasn't.  A \ before a newline in a string continues the
string, but the \\ in your example gives an actual \ in the resulting
string.  To continue it, you'd need to write "ABC\\\
\
nDEF" and you'd end up with a string that could have been written as
"ABC\\nDEF".  It really was simple to process and a special case
designed for strings.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148137

On 23/11/2019 01:47, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
> 
>> Where a language has line continuation to split source across multiple
>> lines, then it is highly unusual to allow that split in the middle of
>> a token.
> 
> It's a comparatively rare feature altogether, but I don't think the
> balance between the two ways of doing it it quite as dramatic as you
> suggest.  In C, C++ and Fortran, line continuations are simply literal
> line pasting,

I couldn't get that behaviour using the & line-continuation of modern 
Fortran; I couldn't use it to split a keyword.

  but what languages don't do it that way?  I think Python
> and Visual Basic are two, but are there lots more?

Python uses \ that can't split names. Ruby is another, according to my 
brief test.

> In my view, if you are going to do it, doing it simply and entirely
> literally makes it both easy to document and the more broadly useful.

It creates complications. You are forced to either have a separate pass 
just to combine lines (ie. replace \crlf or \lf sequences with nothing, 
meaning copying lots text).

Or having to deal with \crlf and \lf in the middle of every kind of 
token. And not just that, but also \whitespace or \anything else.

My tidy loop for scanning the remainder of a C identifier (here 
expressed as untested C):

     while (alphamap[c = *lxsptr++] } hsum = (hsum<<4) + c;

is no longer going to be that tidy. Or you have to use other approaches 
such as a getnextchar() function (which now relies on inlining to keep 
it efficient).

It creates difficulties for tools such as those three editors I 
mentioned that couldn't properly highlight such split keywords.

It also causes that problem with // comments:

   // try c:\texts\
   fopen(file);

where the following line is silently commented out (although editors 
seem to be wise to that one).

And this example:

     printf("Hello\\
nWorld!");

is not handled properly by tcc (others, apart from bcc, are OK).

(I would have expected this feature to go in hand with allowing /*...*/ 
comments in the middle of a token, but that's not allowed.)

>> What is the purpose
> 
> It was useful whenever C was used in line-length limited contexts.  I've
> seen it used when transmitting C over some early messaging systems, and
> I imagine it was (any maybe still is) useful where file systems impose
> fixed-length records.  The line breaking and reconstruction can be done
> without any knowledge of tokens.

Actually I would find that useful for MSVC which has problems with my 
long string constants, if I could literally split them anywhere 
including in the middle of an escape sequence like the example above.

But I couldn't do that (even if I'd known about it) because it seems 
like such a naff way of dealing with that problem. Also because it 
wouldn't work with tcc and bcc.

Primarily though because I feel the solution here is NOT to have some 
silly arbitrary limit on string lengths - fix the compiler not the program.

[toc] | [prev] | [next] | [standalone]

#148141

On 11/23/19 7:21 AM, Bart wrote:
> 
> (I would have expected this feature to go in hand with allowing /*...*/
> comments in the middle of a token, but that's not allowed.)

The issue here is that /*   */ is defined as replacing the comment with
'whitespace' so you get two tokens.

There was a period, before C89, when some implementations did do
something like this

#define FOO foo
#define BAR bar


   FOO/* */BAR = 1;

would be the same as

    foobar = 1;


This got replaced with ## in the Standard.

[toc] | [prev] | [next] | [standalone]

#148143

Bart <bc@freeuk.com> writes:
>On 23/11/2019 01:47, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> Where a language has line continuation to split source across multiple
>>> lines, then it is highly unusual to allow that split in the middle of
>>> a token.
>> 
>> It's a comparatively rare feature altogether, but I don't think the
>> balance between the two ways of doing it it quite as dramatic as you
>> suggest.  In C, C++ and Fortran, line continuations are simply literal
>> line pasting,
>
>I couldn't get that behaviour using the & line-continuation of modern 
>Fortran; I couldn't use it to split a keyword.

There are well over 100 different fortran compilers historically.  And
you checked one.  On a windows box.   From that you draw a conclusion.

Do you see the flaw in your logic?

[toc] | [prev] | [next] | [standalone]

#148145

On 23/11/2019 15:49, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 23/11/2019 01:47, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> Where a language has line continuation to split source across multiple
>>>> lines, then it is highly unusual to allow that split in the middle of
>>>> a token.
>>>
>>> It's a comparatively rare feature altogether, but I don't think the
>>> balance between the two ways of doing it it quite as dramatic as you
>>> suggest.  In C, C++ and Fortran, line continuations are simply literal
>>> line pasting,
>>
>> I couldn't get that behaviour using the & line-continuation of modern
>> Fortran; I couldn't use it to split a keyword.
> 
> There are well over 100 different fortran compilers historically.  And
> you checked one.  On a windows box.   From that you draw a conclusion.
> 
> Do you see the flaw in your logic?

How many have you tried that use &, zero?

The one I used was gfortran compiled with gcc, running on rextester.com 
so probably not Windows. This program didn't compile (4-space 
indentation added):

     !gfortran, gcc version 5.4.0 20160609

     program hello
         pri&
     nt *, "Hello World!"
     end program hello

Probably, an older Fortran that is strictly column-based would work, 
with a continuation character in column 6, but I don't have such a 
version to try.

[toc] | [prev] | [next] | [standalone]

#148146

Bart <bc@freeuk.com> writes:

> The one I used was gfortran compiled with gcc, running on
> rextester.com so probably not Windows. This program didn't compile
> (4-space indentation added):
>
>     !gfortran, gcc version 5.4.0 20160609
>
>     program hello
>         pri&
>     nt *, "Hello World!"

You need

      &nt *, "Hello World!"
      
>     end program hello
>
> Probably, an older Fortran that is strictly column-based would work,

Yes it does.  That's the form I was talking about.

> with a continuation character in column 6, but I don't have such a
> version to try.

I think you probably do: gfortran -ffixed-form

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web