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 1 of 2  [1] 2  Next page →

#170309 — deprecate backslash-newline (line continuation) ?

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?

[toc] | [next] | [standalone]

#170310

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!

Why?  What is the benefit?  How much code will break if this changes?

> The only reason to use line continuation is at end of macros.

You mean that's the only thing you want them for!  Most low-level line
continuation conventions date from the days when some systems had
fixed-length record file formats.  It makes lots of things easier if you
can continue a logical line at any point with a mechanism that sits
below the tokeniser.

> #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.

I'd vote no.

-- 
Ben.

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

#170313

On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@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!
> Why? What is the benefit? 
It is a simplification. Similar of removal of trigraphs etc.. 

>How much code will break if this changes?

That depends how it is defined/implemented. 
If backslash-new-line is considered a whitespace

Then
#define A \
B\
C

A would expand to B C instead of BC
But code that depends on spaces are already dangerous .

> > The only reason to use line continuation is at end of macros.
> You mean that's the only thing you want them for! Most low-level line 
> continuation conventions date from the days when some systems had 
> fixed-length record file formats. It makes lots of things easier if you 
> can continue a logical line at any point with a mechanism that sits 
> below the tokeniser.
It is a modernization we don't need this anymore.

I am writing more details an a implementation to see the details.

It may be defined just where it makes sense like #define or everywhere
in preprocessor. 

The problem is making it as space is it would work here
#undef \
X

and it does not make sense. But the rule it would be simpler comparing
with defining where it can be used.

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

#170318

On 22/05/2023 20:14, Thiago Adams wrote:
> On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@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!
>> Why? What is the benefit?
> It is a simplification. Similar of removal of trigraphs etc..
> 
>> How much code will break if this changes?
> 
> That depends how it is defined/implemented.
> If backslash-new-line is considered a whitespace
> 
> Then
> #define A \
> B\
> C
> 
> A would expand to B C instead of BC
> But code that depends on spaces are already dangerous .
> 

As far as I understand the standards, backslash-newline is removed 
entirely - it is /not/ considered whitespace or translated to a space 
character (you are perhaps mixing that up with comments).

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

#170321

On Monday, May 22, 2023 at 4:49:16 PM UTC-3, David Brown wrote:
> On 22/05/2023 20:14, Thiago Adams wrote: 
> > On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote: 
> >> Thiago Adams <thiago...@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! 
> >> Why? What is the benefit? 
> > It is a simplification. Similar of removal of trigraphs etc.. 
> > 
> >> How much code will break if this changes? 
> > 
> > That depends how it is defined/implemented. 
> > If backslash-new-line is considered a whitespace 
> > 
> > Then 
> > #define A \ 
> > B\ 
> > C 
> > 
> > A would expand to B C instead of BC 
> > But code that depends on spaces are already dangerous . 
> >
> As far as I understand the standards, backslash-newline is removed 
> entirely - it is /not/ considered whitespace or translated to a space 
> character (you are perhaps mixing that up with comments).

Yes you  are correct.
Making it a space was a alternative design to support "normal"usage.

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

#170324

Thiago Adams <thiago.adams@gmail.com> writes:

> On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams <thiago...@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!
>> Why? What is the benefit? 
>
> It is a simplification.

Your suggestion is more complex.  The \ rule is trivial to describe and
implement.

> Similar of removal of trigraphs etc..

That's a removal.  It's bound to make C simpler.  You are suggesting
something quite different from a plain removal.

>>How much code will break if this changes?
>
> That depends how it is defined/implemented.

So you don't yet know how much existing code you expect will break?  OK.

> If backslash-new-line is considered a whitespace
>
> Then
> #define A \
> B\
> C
>
> A would expand to B C instead of BC
> But code that depends on spaces are already dangerous .
>
>> > The only reason to use line continuation is at end of macros.
>> You mean that's the only thing you want them for! Most low-level line 
>> continuation conventions date from the days when some systems had 
>> fixed-length record file formats. It makes lots of things easier if you 
>> can continue a logical line at any point with a mechanism that sits 
>> below the tokeniser.
> It is a modernization we don't need this anymore.

Any evidence?  Have you done any research?

-- 
Ben.

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

#170326

On Monday, May 22, 2023 at 6:16:09 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> 
> > On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote: 
> >> Thiago Adams <thiago...@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! 
> >> Why? What is the benefit? 
> > 
> > It is a simplification.
> Your suggestion is more complex. The \ rule is trivial to describe and 
> implement.
> > Similar of removal of trigraphs etc..
> That's a removal. It's bound to make C simpler. You are suggesting 
> something quite different from a plain removal.
> >>How much code will break if this changes? 
> > 
> > That depends how it is defined/implemented.
> So you don't yet know how much existing code you expect will break? OK.
> > If backslash-new-line is considered a whitespace 
> > 
> > Then 
> > #define A \ 
> > B\ 
> > C 
> > 
> > A would expand to B C instead of BC 
> > But code that depends on spaces are already dangerous . 
> > 
> >> > The only reason to use line continuation is at end of macros. 
> >> You mean that's the only thing you want them for! Most low-level line 
> >> continuation conventions date from the days when some systems had 
> >> fixed-length record file formats. It makes lots of things easier if you 
> >> can continue a logical line at any point with a mechanism that sits 
> >> below the tokeniser. 
> > It is a modernization we don't need this anymore.
> Any evidence? Have you done any research? 
I will do some research and separate the correct/usual usage
of line continuation and propose something that matches the 
correct usage.
  

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

#170328

On Monday, May 22, 2023 at 7:11:07 PM UTC-3, Thiago Adams wrote:
> On Monday, May 22, 2023 at 6:16:09 PM UTC-3, Ben Bacarisse wrote: 
> > Thiago Adams <thiago...@gmail.com> writes: 
> > 
> > > On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote: 
> > >> Thiago Adams <thiago...@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! 
> > >> Why? What is the benefit? 
> > > 
> > > It is a simplification. 
> > Your suggestion is more complex. The \ rule is trivial to describe and 
> > implement. 
> > > Similar of removal of trigraphs etc.. 
> > That's a removal. It's bound to make C simpler. You are suggesting 
> > something quite different from a plain removal. 
> > >>How much code will break if this changes? 
> > > 
> > > That depends how it is defined/implemented. 
> > So you don't yet know how much existing code you expect will break? OK. 
> > > If backslash-new-line is considered a whitespace 
> > > 
> > > Then 
> > > #define A \ 
> > > B\ 
> > > C 
> > > 
> > > A would expand to B C instead of BC 
> > > But code that depends on spaces are already dangerous . 
> > > 
> > >> > The only reason to use line continuation is at end of macros. 
> > >> You mean that's the only thing you want them for! Most low-level line 
> > >> continuation conventions date from the days when some systems had 
> > >> fixed-length record file formats. It makes lots of things easier if you 
> > >> can continue a logical line at any point with a mechanism that sits 
> > >> below the tokeniser. 
> > > It is a modernization we don't need this anymore. 
> > Any evidence? Have you done any research?
> I will do some research and separate the correct/usual usage 
> of line continuation and propose something that matches the 
> correct usage.

I did some search on windows includes using visual studio regex

backslash + newline
regex:\\.$
256964   

space backslash + newline
regex:\ \\.$
141932

 , backslash + newline
regex:\,\\.$
1166

) backslash + newline
regex:\)\\.$
446

digit  backslash + newline
regex:\d\\.$
33

word  backslash + newline
\w\\.$
450

word  backslash + newline word 
\w\\.$\w
0

I checked "visually" 100% of usage is inside #define.
(need better regex for this)

some usage in line comments

// CertSvc\Configuration\<CAName>\PolicyModules\<ProgId>\LdapSessionOptions\
//                                        OptionId1\
//                                                  LDAPSessionOptionValue 
//                                        OptionId2\
//                                                  LDAPSessionOptionValue 
//                                        OptionId3\
//                                                  LDAPSessionOptionValue 
//                                        ...

This usage suggests that we only need add these tokens
at define to match 100% compatibility with windows headers
(for instance) 
But we need to accept non-space before. But this is the natural usage
not join tokens.

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

#170329

I am a little more confident now to say that we only need 
ignore backslash-newline at preprocessor phase.

I let backslash  survive phase 2, then  parsed windows headers
ignoring them at preprocessor - it worked for this set of files.

The exactly places where backslash-newline are allowed depends.
But in general where spaces are allowed backslash-newline can be 
ignored. 

For instance:
#define \
M \
1

We may define that after define and before macro name we don´t allow
backslash-newline. It just a matter of rewriting the grammar .

Parsing windows header I also find backslash-newline in #if expressions
and separating function-line macros arguments.

Breaking changes:

#define A\
B 1
Before the macro name is AB. With this change macro name is A.
I don´t expect to find code relying on this.


//comment \
1
Before change 1 is part of the comment. After the 1 is separated.
I don´t expect to find code relying on this.

int a, \
 b;
After this change backslash will survive and generate error in compile time.
Just delete the backslash  in this case.

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

#170330

>I am a little more confident now to say that we only need
>ignore backslash-newline at preprocessor phase. 

Better way to say is 

I am a little more confident now to say that we only need
ignore backslash-newline at preprocessor directives. (#define #if etc) 

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

#170335

On Tuesday, 23 May 2023 at 03:48:00 UTC+3, Thiago Adams wrote:
> >I am a little more confident now to say that we only need 
> >ignore backslash-newline at preprocessor phase.
> 
> Better way to say is
> 
> I am a little more confident now to say that we only need
> ignore backslash-newline at preprocessor directives. (#define #if etc)
> 
Why you asked what others think? It seems that outright everybody
who expressed their opinion are opposing such change and posted
also why. That however somehow made you more convinced and
confident that we need to do it.

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

#170336

On Tuesday, May 23, 2023 at 5:24:23 AM UTC-3, Öö Tiib wrote:
> On Tuesday, 23 May 2023 at 03:48:00 UTC+3, Thiago Adams wrote: 
> > >I am a little more confident now to say that we only need 
> > >ignore backslash-newline at preprocessor phase. 
> > 
> > Better way to say is 
> > 
> > I am a little more confident now to say that we only need 
> > ignore backslash-newline at preprocessor directives. (#define #if etc) 
> >
> Why you asked what others think? It seems that outright everybody 
> who expressed their opinion are opposing such change and posted 
> also why. That however somehow made you more convinced and 
> confident that we need to do it.

I asked for several reasons. Someone could find a usage that I am 
not aware of or find a problem in the suggestion.
But the reason I was more confident was because  I already did
a research in windows headers and a implementation that parsed
#include <windows.h> without problems. So "normal" use cases 
were not affected.
It starts to work after ignoring line-continuation instead of making 
it works as space.


I wrote the suggestion in form of proposal.
https://github.com/thradams/cake/blob/main/removing_phase_2.md

The proposal is implemented in cake
http://thradams.com/cake/playground.html

If possible I would like to send it for C standard  I believe this is one step
forward in modernization.
(
I generally don't like the word "modernization" but in this case I choose this
word because I don't believe any new language/compiler would implement 
this feature as a separated phase.
)

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

#170337

On 23/05/2023 11:59, Thiago Adams wrote:
 > On Tuesday, May 23, 2023 at 5:24:23 AM UTC-3, Öö Tiib wrote:
 >> On Tuesday, 23 May 2023 at 03:48:00 UTC+3, Thiago Adams wrote:
 >>>> I am a little more confident now to say that we only need
 >>>> ignore backslash-newline at preprocessor phase.
 >>>
 >>> Better way to say is
 >>>
 >>> I am a little more confident now to say that we only need
 >>> ignore backslash-newline at preprocessor directives. (#define #if etc)
 >>>
 >> Why you asked what others think? It seems that outright everybody
 >> who expressed their opinion are opposing such change and posted
 >> also why. That however somehow made you more convinced and
 >> confident that we need to do it.
 >
 > I asked for several reasons. Someone could find a usage that I am
 > not aware of or find a problem in the suggestion.
 > But the reason I was more confident was because  I already did
 > a research in windows headers and a implementation that parsed
 > #include <windows.h> without problems. So "normal" use cases
 > were not affected.

You shouldn't be looking at system headers, the ones provided with a C 
implementation.

Because if that implementation chooses to change the behaviour of "\", 
it can provide suitably modified headers if necessary, which probably 
won't be.

The troublesome code is that belonging other libraries and other 
applications.

Fortunately this special ability of '\', to break within token, even here:

  /\
  /\
  comment

is something very few know about, so hardly anyone will make use of, 
except inadvertently. (You will see it in bugs quirks this:

     a; // path c:\abc\
     b;

here that closing \ is not part of the comment, it continues the comment 
onto the next line so that `b` is part of the comment and not executed.)

 > It starts to work after ignoring line-continuation instead of making
 > it works as space.
 >
 >
 > I wrote the suggestion in form of proposal.
 > https://github.com/thradams/cake/blob/main/removing_phase_2.md
 >
 > The proposal is implemented in cake
 > http://thradams.com/cake/playground.html

I have my own treatment of '\' in my C compiler, since I didn't know it 
could break mid-token. However, if someone really needs that behaviour, 
they can use this option:

    -splicing

then a special pass is performed on the just-loaded source code, just to 
splice \ lines. The new text is then the basis for a normal parse, 
without needing to bother about \, which otherwise would be very 
disruptive having to allow for it at every single character.


 > If possible I would like to send it for C standard  I believe this is 
one step
 > forward in modernization.

It would nice to get rid of this particular quirk, but C is never going 
to be modernised in the way it should.


 > I generally don't like the word "modernization" but in this case I 
choose this
 > word because I don't believe any new language/compiler would implement
 > this feature as a separated phase.

No-one would have thought of it! But actually it is easy to bolt on such 
a feaure, if handled the way I have, as a separate step.

A few years ago I would have found a use for this feature, as my 
generated C sources sometimes had very large string literals. Not 
usually a problem, they didn't work with MSVC which had a 16KB limit per 
string.

I tried breaking up long strings, but it was awkward to avoid escape 
sequences when choosing a break point. I didn't know I could split a 
string in the middle of an escape sequence.

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

#170338

On Tuesday, May 23, 2023 at 12:52:09 PM UTC-3, Bart wrote:
> A few years ago I would have found a use for this feature, as my 
> generated C sources sometimes had very large string literals. Not 
> usually a problem, they didn't work with MSVC which had a 16KB limit per 
> string. 
> 
...
> I tried breaking up long strings, but it was awkward to avoid escape 
> sequences when choosing a break point. I didn't know I could split a 
> string in the middle of an escape sequence.

After thinking about the problem I realized that the proposal is basically
removal of phase 2 handling line-continuation at grammar level.
We can be 100% compatible if we wish.

Do we want allow line-continuation inside literal strings? 
No. Then we emit error.
Yes. Then we allow line-continuation inside literals tokens.

Do we want allow line-continuation inside line comments? 
No. Then we emit error.
Yes. Then we allow line-continuation inside line comments.

Where we find a lot of usages is inside preprocessor directives.
So making line-continuation a blank token inside preprocessor directives 
will handle all preprocessor usage.

The process now is catalogue usages of line continuation and let's
say 1/10000 its a candidate for error.

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

#170339

On Tuesday, May 23, 2023 at 2:40:40 PM UTC-3, Thiago Adams wrote:
> On Tuesday, May 23, 2023 at 12:52:09 PM UTC-3, Bart wrote: 
> > A few years ago I would have found a use for this feature, as my 
> > generated C sources sometimes had very large string literals. Not 
> > usually a problem, they didn't work with MSVC which had a 16KB limit per 
> > string. 
> >
> ...
> > I tried breaking up long strings, but it was awkward to avoid escape 
> > sequences when choosing a break point. I didn't know I could split a 
> > string in the middle of an escape sequence.
> After thinking about the problem I realized that the proposal is basically 
> removal of phase 2 handling line-continuation at grammar level. 
> We can be 100% compatible if we wish. 
> 
> Do we want allow line-continuation inside literal strings? 
> No. Then we emit error. 
> Yes. Then we allow line-continuation inside literals tokens. 
> 
> Do we want allow line-continuation inside line comments? 
> No. Then we emit error. 
> Yes. Then we allow line-continuation inside line comments. 
> 
> Where we find a lot of usages is inside preprocessor directives. 
> So making line-continuation a blank token inside preprocessor directives 
> will handle all preprocessor usage. 
> 
> The process now is catalogue usages of line continuation and let's 
> say 1/10000 its a candidate for error.

I decided UNDO the feature. It may return in a form of warnings.
"warning  using line continuation inside ... line comments, "
"warning  using line continuation breaking identifiers"
etc.

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

#170341

Thiago Adams <thiago.adams@gmail.com> writes:
[...]
> I asked for several reasons. Someone could find a usage that I am 
> not aware of or find a problem in the suggestion.
> But the reason I was more confident was because  I already did
> a research in windows headers and a implementation that parsed
> #include <windows.h> without problems. So "normal" use cases 
> were not affected.

Are you assuming that a test on Windows headers is sufficient to
demonstrate that such a change would not cause problems for *all
other C software*?

-- 
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]

#170315

On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote:
>How much code will break if this changes?

If we don't break code that means we allow silly things inside 
preprocessor directives.

For instance, keeping as it is today but only inside preprocessor

#define M\
A\
      B

Is it silly?
MA expands to  B. 
Maybe the programmer want macro name to be  M?

If we make \new-line  be a space then the name 
of the macro is M and the expansion of M is A B

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

#170325

Thiago Adams <thiago.adams@gmail.com> writes:

> On Monday, May 22, 2023 at 12:30:52 PM UTC-3, Ben Bacarisse wrote:
>>How much code will break if this changes?
>
> If we don't break code that means we allow silly things inside 
> preprocessor directives.

Yes.  The PP was always a hack.  Yet it was a superb example of an
effective engineering compromise at the time.

And C lives by being stable.  The committee seems to be less
conservative that in the past, and the worries me.

-- 
Ben.

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

#170971

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

[regarding how C might evolve]

> And C lives by being stable.  The committee seems to be less
> conservative that in the past, and the worries me.

The more I learn about where C is going since C11, the more
inclined I am to think it will be significantly worse in the
future, and not better.

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

#170311

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.)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web