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

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

deprecate backslash-newline (line continuation) ?

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

Contents

  deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 05:19 -0700
    Re: deprecate backslash-newline (line continuation) ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-05-22 16:30 +0100
      Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 11:14 -0700
        Re: deprecate backslash-newline (line continuation) ? David Brown <david.brown@hesbynett.no> - 2023-05-22 21:46 +0200
          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 13:06 -0700
        Re: deprecate backslash-newline (line continuation) ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-05-22 22:15 +0100
          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 15:10 -0700
            Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 15:56 -0700
              Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 17:45 -0700
                Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 17:47 -0700
                  Re: deprecate backslash-newline (line continuation) ? Öö Tiib <ootiib@hot.ee> - 2023-05-23 01:24 -0700
                    Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 03:59 -0700
                      Re: deprecate backslash-newline (line continuation) ? Bart <bc@freeuk.com> - 2023-05-23 16:51 +0100
                        Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 10:40 -0700
                          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 11:07 -0700
                      Re: deprecate backslash-newline (line continuation) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-05-23 13:31 -0700
      Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 11:29 -0700
        Re: deprecate backslash-newline (line continuation) ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-05-22 22:18 +0100
          Re: deprecate backslash-newline (line continuation) ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-07-20 09:14 -0700
    Re: deprecate backslash-newline (line continuation) ? David Brown <david.brown@hesbynett.no> - 2023-05-22 17:31 +0200
      Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 11:17 -0700
        Re: deprecate backslash-newline (line continuation) ? David Brown <david.brown@hesbynett.no> - 2023-05-22 21:52 +0200
    Re: deprecate backslash-newline (line continuation) ? Öö Tiib <ootiib@hot.ee> - 2023-05-22 09:10 -0700
    Re: deprecate backslash-newline (line continuation) ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-22 19:10 +0000
      Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 12:25 -0700
        Re: deprecate backslash-newline (line continuation) ? David Brown <david.brown@hesbynett.no> - 2023-05-22 21:58 +0200
          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-22 13:21 -0700
        Re: deprecate backslash-newline (line continuation) ? scott@slp53.sl.home (Scott Lurndal) - 2023-05-22 20:15 +0000
    Re: deprecate backslash-newline (line continuation) ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-05-22 15:12 -0700
      Re: deprecate backslash-newline (line continuation) ? Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-23 06:57 +0000
        Re: deprecate backslash-newline (line continuation) ? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-05-23 00:13 -0700
    Re: deprecate backslash-newline (line continuation) ? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-05-23 20:40 -0400
      Re: deprecate backslash-newline (line continuation) ? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-05-24 02:05 +0100
        Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 19:07 -0700
          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 19:09 -0700
            Re: deprecate backslash-newline (line continuation) ? Richard Damon <Richard@Damon-Family.org> - 2023-05-24 12:07 -0400
          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 19:34 -0700
        Re: deprecate backslash-newline (line continuation) ? Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-05-23 22:32 -0400
          Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 19:44 -0700
      Re: deprecate backslash-newline (line continuation) ? Thiago Adams <thiago.adams@gmail.com> - 2023-05-23 19:08 -0700

Page 2 of 2 — ← Prev page 1 [2]

#170314

On Monday, May 22, 2023 at 12:33:37 PM UTC-3, David Brown wrote:
> On 22/05/2023 14:19, Thiago Adams wrote: 
> > In C, the line continuation works as if deleted in the first stages 
> > of compilation. 
> > So in C it can be in ANY position. 
> > For instance 
> > 
> > #define M\ 
> > ACRO 1 
> > MACRO 1 
> > 
> > // a b \ 
> > c 
> > 
> > I think this should be removed from C! 
> > The only reason to use line continuation is at end of macros. 
> > 
> > #define A 1,\2,\ 
> > 3 
> > 
> > To implement this is C we can make backslash-newline 
> > a token. This token will naturally not be allowed in many places. 
> > And at preprocessor, inside 
> > #define (maybe also #if) it is considered as blank token. 
> > 
> > 
> > What do you think? 
> > Do you know any other usage of line continuation other 
> > than macro? 
> >
> I think your suggestion is quite reasonable, but I don't think it is 
> ever going to change - there simply isn't enough reason to change the 
> existing handling of backslash line continuation. 
> 
> I have seen people use line continuation unnecessarily in contexts other 
> than macros, such as calling a function with parameters stretching over 
> several lines. The line continuation backslash is pointless in such 
> cases, but does no harm either (except perhaps to confuse people). But 
> I can't think of a situation other than with macros that I have seen it 
> usefully used, and not in the middle of a pre-processing token. In 
> theory, people who stick to very short line lengths might find it 
> helpful for long "#if" conditionals or "#includes" with long pathnames, 
> but I don't think I have seen such a thing in practice. 
> 
> However, the C standards committee don't remove a feature without very 
> good reason. And I don't see a good reason to do so here - it would be 
> sufficient for any given implementation to add a warning for 
> questionable use of line continuation. Changing it might affect some 
> code. And removal of phase 2 from the translation phases would make a 
> mess of section 5.1.1.2 and anything that refers to it. 
> 
> (It could also been an issue for other uses of the C pre-processor, 
> other than for C.)

Let's take this sample

#de\ 
fine M\ 
ACRO 1 

// line comment \ 
MACRO 

int main() { 
    int a\ 
b; 
   ab = MACRO; 
} 

The complication starts with the editor. 
Many if not all editors may have problems with the syntax color of #define or line comment. 
They may be fixed. But it's worth? 
Imagine refactoring tool that does rename having to deal with the identifier ab. 
The standard also needs a phase (2) to describe the backlash-newline behavior.
GCC have a warning when backlash-newline is used in line comments and
 MISRA C (maybe others) have a rule for it.

Removing backlash-newline is a simplification and modernization of the language and 
makes the language safer and tools simpler.

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

#170319

On 22/05/2023 20:17, Thiago Adams wrote:
> On Monday, May 22, 2023 at 12:33:37 PM UTC-3, David Brown wrote:
>> On 22/05/2023 14:19, Thiago Adams wrote:
>>> In C, the line continuation works as if deleted in the first stages
>>> of compilation.
>>> So in C it can be in ANY position.
>>> For instance
>>>
>>> #define M\
>>> ACRO 1
>>> MACRO 1
>>>
>>> // a b \
>>> c
>>>
>>> I think this should be removed from C!
>>> The only reason to use line continuation is at end of macros.
>>>
>>> #define A 1,\2,\
>>> 3
>>>
>>> To implement this is C we can make backslash-newline
>>> a token. This token will naturally not be allowed in many places.
>>> And at preprocessor, inside
>>> #define (maybe also #if) it is considered as blank token.
>>>
>>>
>>> What do you think?
>>> Do you know any other usage of line continuation other
>>> than macro?
>>>
>> I think your suggestion is quite reasonable, but I don't think it is
>> ever going to change - there simply isn't enough reason to change the
>> existing handling of backslash line continuation.
>>
>> I have seen people use line continuation unnecessarily in contexts other
>> than macros, such as calling a function with parameters stretching over
>> several lines. The line continuation backslash is pointless in such
>> cases, but does no harm either (except perhaps to confuse people). But
>> I can't think of a situation other than with macros that I have seen it
>> usefully used, and not in the middle of a pre-processing token. In
>> theory, people who stick to very short line lengths might find it
>> helpful for long "#if" conditionals or "#includes" with long pathnames,
>> but I don't think I have seen such a thing in practice.
>>
>> However, the C standards committee don't remove a feature without very
>> good reason. And I don't see a good reason to do so here - it would be
>> sufficient for any given implementation to add a warning for
>> questionable use of line continuation. Changing it might affect some
>> code. And removal of phase 2 from the translation phases would make a
>> mess of section 5.1.1.2 and anything that refers to it.
>>
>> (It could also been an issue for other uses of the C pre-processor,
>> other than for C.)
> 
> Let's take this sample
> 
> #de\
> fine M\
> ACRO 1
> 
> // line comment \
> MACRO
> 
> int main() {
>      int a\
> b;
>     ab = MACRO;
> }
> 
> The complication starts with the editor.
> Many if not all editors may have problems with the syntax color of #define or line comment.
> They may be fixed. But it's worth?
> Imagine refactoring tool that does rename having to deal with the identifier ab.
> The standard also needs a phase (2) to describe the backlash-newline behavior.
> GCC have a warning when backlash-newline is used in line comments and
>   MISRA C (maybe others) have a rule for it.
> 
> Removing backlash-newline is a simplification and modernization of the language and
> makes the language safer and tools simpler.
> 

You'll get nowhere by arguing that the current behaviour allows silly or 
hard to read code - it will /always/ allow that.  You can't legislate 
against stupidity.

If you can provide a reasonable argument that the current behaviour 
makes it easy to make mistakes that are hard to spot (by human readers 
or by automated tools), /then/ you have justification for changing the 
behaviour.  It is not enough to say "a modern language would be 
different", and certainly not enough to say "it makes writing an editor 
harder".

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

#170312

On Monday, 22 May 2023 at 15:19:10 UTC+3, Thiago Adams wrote:
> In C, the line continuation works as if deleted in the first stages 
> of compilation. 
> So in C it can be in ANY position. 
> For instance 
> 
> #define M\ 
> ACRO 1 
> MACRO 1 
> 
> // a b \ 
> c 
> 
> I think this should be removed from C! 
> The only reason to use line continuation is at end of macros. 
> 
> #define A 1,\2,\ 
> 3 
> 
> To implement this is C we can make backslash-newline 
> a token. This token will naturally not be allowed in many places. 
> And at preprocessor, inside 
> #define (maybe also #if) it is considered as blank token. 
> 
> 
> What do you think? 
> Do you know any other usage of line continuation other 
> than macro?

Even if that line continuation is indeed badly and not intuitively
designed, I do not think that blunt not allowing is correct to do.

Many will be rightfully against changing of whatever feature
just because it is not ideal. So what? It is there, code using it was
written and works, tools that support that feature are also available
etc. How to force people to maintain and then retest and re-release
everything without any value added? 

Problems with the feature IMHO are that:
* line continuation can cause (avoidable) illusions and confusion; 
* multi-line macros aren't part of language;
* macros are inconvenient to comment;
* macros are inconvenient to debug.

So I would like alternative token/scheme for multi-line macros
that allows better commenting, debugging etc of macros.

If such is implemented then backslash-newline may be
deprecated outside of macros or whatsoever (but I'm unsure
what benefits it gives).

However if such alternative is not present then ... no way.
Better write restrictions about backslash-newline to coding
standard, and embed automatic diagnosing, refactoring and
reformatting tools (that enforce your coding standard) into
toolchain.

  

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

#170316

On 2023-05-22, Thiago Adams <thiago.adams@gmail.com> wrote:
> In C, the line continuation works as if deleted in the first stages 
> of compilation.
> So in C it can be in ANY position.

This property of the backslash continuation is essential. It means that
a very simple program can take a C source and split into shorter lines
with with backslash continuations, without having to tokenize anything.

Same in the reverse direction; a simple program can remove backslash
continuations, so that logical lines correspond to physical lines.

Changing how this works risks breaking unknown amounts of code, possibly
silently so.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#170317

On Monday, May 22, 2023 at 4:12:34 PM UTC-3, Kaz Kylheku wrote:
> On 2023-05-22, Thiago Adams <thiago...@gmail.com> wrote: 
> > In C, the line continuation works as if deleted in the first stages 
> > of compilation. 
> > So in C it can be in ANY position.
> This property of the backslash continuation is essential. 


Does anyone knows sample of languages where new line is part 
of the syntax? (and in this case may require a line continuation?)

I think VB have some parts where newline is used. VB also have
_ line continuation but requires a white space before the _.

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

#170320

On 22/05/2023 21:25, Thiago Adams wrote:
> On Monday, May 22, 2023 at 4:12:34 PM UTC-3, Kaz Kylheku wrote:
>> On 2023-05-22, Thiago Adams <thiago...@gmail.com> wrote:
>>> In C, the line continuation works as if deleted in the first stages
>>> of compilation.
>>> So in C it can be in ANY position.
>> This property of the backslash continuation is essential.
> 
> 
> Does anyone knows sample of languages where new line is part
> of the syntax? (and in this case may require a line continuation?)
> 
> I think VB have some parts where newline is used. VB also have
> _ line continuation but requires a white space before the _.
> 

There are countless languages that consider a newline to be the end of a 
statement, at least in some circumstances.

<https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)#Statements>

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

#170323

On Monday, May 22, 2023 at 5:00:56 PM UTC-3, David Brown wrote:
> On 22/05/2023 21:25, Thiago Adams wrote: 
> > On Monday, May 22, 2023 at 4:12:34 PM UTC-3, Kaz Kylheku wrote: 
> >> On 2023-05-22, Thiago Adams <thiago...@gmail.com> wrote: 
> >>> In C, the line continuation works as if deleted in the first stages 
> >>> of compilation. 
> >>> So in C it can be in ANY position. 
> >> This property of the backslash continuation is essential. 
> > 
> > 
> > Does anyone knows sample of languages where new line is part 
> > of the syntax? (and in this case may require a line continuation?) 
> > 
> > I think VB have some parts where newline is used. VB also have 
> > _ line continuation but requires a white space before the _. 
> >
> There are countless languages that consider a newline to be the end of a 
> statement, at least in some circumstances. 
> 
> <https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(syntax)#Statements>

After some experiments like requiring  a white-space before line 
backslash-newline and compiling windows headers to see what happens
I am dropping the idea. It's hard to separate good usages from bad ones.

Something not difficult to do is a warning if after join lines
results in a identifier.

A\
B
warning result AB

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

#170322

Thiago Adams <thiago.adams@gmail.com> writes:
>On Monday, May 22, 2023 at 4:12:34=E2=80=AFPM UTC-3, Kaz Kylheku wrote:
>> On 2023-05-22, Thiago Adams <thiago...@gmail.com> wrote:=20
>> > In C, the line continuation works as if deleted in the first stages=20
>> > of compilation.=20
>> > So in C it can be in ANY position.
>> This property of the backslash continuation is essential.=20
>
>
>Does anyone knows sample of languages where new line is part=20
>of the syntax? (and in this case may require a line continuation?)

Fortran. COBOL.  Basic.  Focal.

The first two reserved a column on the input record
for a continuation indictor.

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

#170327

Thiago Adams <thiago.adams@gmail.com> writes:
> In C, the line continuation works as if deleted in the first stages 
> of compilation.
> So in C it can be in ANY position.
> For instance
>
> #define M\
> ACRO 1
> MACRO 1
>
> // a b \
> c
>
> I think this should be removed from C!
> The only reason to use line continuation is at end of macros.
>
> #define A 1,\2,\
> 3
>
> To implement this is C we can make backslash-newline
> a token. This token will naturally not be allowed in many places.
> And at preprocessor, inside 
> #define (maybe also #if) it is considered as blank token.
>
>
> What do you think?
> Do you know any other usage of line continuation other 
> than macro?

I would oppose this change.  It would break *way* too much existing
code.  Kaz points out that C code can be transformed to limit line
length by a simple filter.

Before C89/C90 introduced string literal concatenation, line splicing
was commonly used for long string literals.  There's probably still
code that does that.

One change I'd support is to specify that a backslash at the end
of a line may optionally be followed by whitespace.  Currently,
in translation phase 2:

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

So if a line ends with a backslash followed by a space, it's *not*
spliced (in principle), though the line appears identical to one without
the trailing space.  (gcc and clang perform the line splice even if
there's trailing whitespace, which is IMHO reasonable but not
conforming.)

A new feature that I wouldn't mind seeing is a way to define a
multi-line macro without need for line splicing, for example:

#defmacro FOO(n)
    ((n) + 1)
#endmacro

But I'm not convinced this would be worth the effort.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#170333

On 2023-05-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> A new feature that I wouldn't mind seeing is a way to define a
> multi-line macro without need for line splicing, for example:
>
> #defmacro FOO(n)
>     ((n) + 1)
> #endmacro
>
> But I'm not convinced this would be worth the effort.

Even if you were convinced it's worth the effort now, you might change
your mind after getting no replies in the GCC patch list for a year.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#170334

On 5/22/2023 11:57 PM, Kaz Kylheku wrote:
> On 2023-05-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> A new feature that I wouldn't mind seeing is a way to define a
>> multi-line macro without need for line splicing, for example:
>>
>> #defmacro FOO(n)
>>      ((n) + 1)
>> #endmacro
>>
>> But I'm not convinced this would be worth the effort.
> 
> Even if you were convinced it's worth the effort now, you might change
> your mind after getting no replies in the GCC patch list for a year.
> 

Humm... Anybody remember the Chaos PP lib? Iirc, that is what is was 
called...

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

#170342

On 5/22/23 08:19, Thiago Adams wrote:
> In C, the line continuation works as if deleted in the first stages
> of compilation.
> So in C it can be in ANY position.
> For instance
> 
> #define M\
> ACRO 1
> MACRO 1
> 
> // a b \
> c
> 
> I think this should be removed from C!
> The only reason to use line continuation is at end of macros.
> 
> <snip/>
> 
> 
> 
> 

​The reason it's only ever used in macros is because that's the only 
place it _needs_ to be used; the preprocessor is the only thing in the C 
language that's newline-sensitive.  Deprecation would be _bad idea_.

-- 
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't 
have shit in Thunderbird 😩

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

#170343

Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:

> On 5/22/23 08:19, Thiago Adams wrote:
>> In C, the line continuation works as if deleted in the first stages
>> of compilation.
>> So in C it can be in ANY position.
>> For instance
>> #define M\
>> ACRO 1
>> MACRO 1
>> // a b \
>> c
>> I think this should be removed from C!
>> The only reason to use line continuation is at end of macros.
>> <snip/>
>> 
>
> ​The reason it's only ever used in macros is because that's the only place
> it _needs_ to be used; the preprocessor is the only thing in the C language
> that's newline-sensitive.

// comments are also line newline-sensitive in that, like macros, they
end on one.  In a different way, string and character literals are also
newline-sensitive in the newlines are not permitted inside them.

-- 
Ben.

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

#170344

On Tuesday, May 23, 2023 at 10:05:26 PM UTC-3, Ben Bacarisse wrote:
> Blue-Maned_Hawk <bluema...@gmail.com> writes: 
> 
> > On 5/22/23 08:19, Thiago Adams wrote: 
> >> In C, the line continuation works as if deleted in the first stages 
> >> of compilation. 
> >> So in C it can be in ANY position. 
> >> For instance 
> >> #define M\ 
> >> ACRO 1 
> >> MACRO 1 
> >> // a b \ 
> >> c 
> >> I think this should be removed from C! 
> >> The only reason to use line continuation is at end of macros. 
> >> <snip/> 
> >> 
> > 
> > ​The reason it's only ever used in macros is because that's the only place 
> > it _needs_ to be used; the preprocessor is the only thing in the C language 
> > that's newline-sensitive.
> // comments are also line newline-sensitive in that, like macros, they 
> end on one. In a different way, string and character literals are also 
> newline-sensitive in the newlines are not permitted inside them. 

I update the document with the proposal.
https://github.com/thradams/cake/blob/main/removing_phase_2.md

I found 4 usages

-  preprocessor directives
- line comments
- inside comments
- literal strings.


to remove phase 2 and move the grammar, we can allow it
inside line comments, comments and literal strings tokens.
and make it blank inside preprocessor directives.

the only breaking change is

#define A B\
C

result B C instead of BC

I search for patter word + \ new line + word and didnt find this problematic pattern
but we can check for line continuation inside identifiers and emit an error
if present.

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

#170346

forgot to say that C++23 apparently is allowing spaces after \ 


https://en.cppreference.com/w/cpp/language/translation_phases

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

#170353

On 5/23/23 10:09 PM, Thiago Adams wrote:
> forgot to say that C++23 apparently is allowing spaces after \
> 
> 
> https://en.cppreference.com/w/cpp/language/translation_phases

As I remember, previous version allowed the ignoring of white space 
after the final ], but didn't require ignoring it. (They just needed to 
define the "end of line" to optionally include spaces before it. This 
became a very gray area.

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

#170348

On Tuesday, May 23, 2023 at 11:07:20 PM UTC-3, Thiago Adams wrote:
...> https://github.com/thradams/cake/blob/main/removing_phase_2.md 

I also started to collect usage to create similar grammar rules but to remove
phase  4, preprocessor. The moving it for compilation phases.

https://github.com/thradams/cake/blob/main/removing_phase_4.md

preprocessor directives like #define #if etc.. 
 - where declarations can occurs (file scope, inside structs, function scope
-?
#define/undef is uncommon inside structs or function arguments
#ifdef can be used in any place but logical groups make more sense


macro expansion
 - keywords INLINE
 - expressions (constants, function like)
 - declarations (DECLARE_X)
 - statements (IF_ERROR_RETURN);
- ??

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

#170347

On 5/23/23 21:05, Ben Bacarisse wrote:
> Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
> 
>> On 5/22/23 08:19, Thiago Adams wrote:
>>> In C, the line continuation works as if deleted in the first stages
>>> of compilation.
>>> So in C it can be in ANY position.
>>> For instance
>>> #define M\
>>> ACRO 1
>>> MACRO 1
>>> // a b \
>>> c
>>> I think this should be removed from C!
>>> The only reason to use line continuation is at end of macros.
>>> <snip/>
>>>
>>
>> ​The reason it's only ever used in macros is because that's the only place
>> it _needs_ to be used; the preprocessor is the only thing in the C language
>> that's newline-sensitive.
> 
> // comments are also line newline-sensitive in that, like macros, they
> end on one.  In a different way, string and character literals are also
> newline-sensitive in the newlines are not permitted inside them.
> 

​Those do not _need_ whitespace; // comments can be rewritten to /* */ 
comments and serve the exact same purpose, and string literals can be 
spread across multiple lines by taking advantage of the preprocessor 
concatenating adjacent string literals.

-- 
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Bitches stole my whole ass ␔🭖᷿᪳𝼗᷍⏧𒒫𐻾ࣛ↉�⃣ quoted-printable, can't 
have shit in Thunderbird 😩

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

#170349

On Tuesday, May 23, 2023 at 11:35:04 PM UTC-3, Blue-Maned_Hawk wrote:
> On 5/23/23 21:05, Ben Bacarisse wrote: 
> > Blue-Maned_Hawk <bluema...@gmail.com> writes: 
> > 
> >> On 5/22/23 08:19, Thiago Adams wrote: 
> >>> In C, the line continuation works as if deleted in the first stages 
> >>> of compilation. 
> >>> So in C it can be in ANY position. 
> >>> For instance 
> >>> #define M\ 
> >>> ACRO 1 
> >>> MACRO 1 
> >>> // a b \ 
> >>> c 
> >>> I think this should be removed from C! 
> >>> The only reason to use line continuation is at end of macros. 
> >>> <snip/> 
> >>> 
> >> 
> >> ​The reason it's only ever used in macros is because that's the only place 
> >> it _needs_ to be used; the preprocessor is the only thing in the C language 
> >> that's newline-sensitive. 
> > 
> > // comments are also line newline-sensitive in that, like macros, they 
> > end on one. In a different way, string and character literals are also 
> > newline-sensitive in the newlines are not permitted inside them. 
> >
> ​Those do not _need_ whitespace; // comments can be rewritten to /* */ 
> comments and serve the exact same purpose, and string literals can be 
> spread across multiple lines by taking advantage of the preprocessor 
> concatenating adjacent string literals.

exactly.
Then what to do with the equivalent grammar rule for these items can be defined to 
emit a deprecation message  for instance.
"this will be removed in the future"

the most problematic one is inside line comments. gcc have a warning for it.

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

#170345

On Tuesday, May 23, 2023 at 9:43:08 PM UTC-3, Blue-Maned_Hawk wrote:
> On 5/22/23 08:19, Thiago Adams wrote: 
> > In C, the line continuation works as if deleted in the first stages 
> > of compilation. 
> > So in C it can be in ANY position. 
> > For instance 
> > 
> > #define M\ 
> > ACRO 1 
> > MACRO 1 
> > 
> > // a b \ 
> > c 
> > 
> > I think this should be removed from C!
> > The only reason to use line continuation is at end of macros. 
> >
> > <snip/> 
> > 
> > 
> > 
> > 
> 
> ​The reason it's only ever used in macros is because that's the only 
> place it _needs_ to be used; the preprocessor is the only thing in the C 
> language that's newline-sensitive. Deprecation would be _bad idea_. 

The deprecation would be only for the usages that can be replaced.
But If I could I would change the title to removal of phase 2.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web