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

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

Implicit String-Literal Concatenation

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

Contents

  Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-24 23:05 +0000
    Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-25 17:38 +0100
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 20:43 +0000
        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-25 21:20 +0000
    Re: Implicit String-Literal Concatenation Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-02-25 16:45 +0000
    Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-25 20:25 +0000
    Re: Implicit String-Literal Concatenation Łukasz 'Maly' Ostrowski <l3vi4than@gmail.com> - 2024-02-26 21:12 +0100
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 20:31 +0000
        Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-27 13:18 +0100
          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 23:10 +0000
            Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-28 00:50 +0100
    Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-26 20:42 +0000
    Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-26 22:03 +0000
      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-26 23:17 +0000
        Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-27 17:27 +0000
      Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-27 09:36 +0100
        Re: Implicit String-Literal Concatenation porkchop@invalid.foo (Mike Sanders) - 2024-02-27 17:31 +0000
        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-27 18:56 +0000
          Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-27 23:21 +0100
            Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 22:52 +0000
              Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-28 01:09 +0000
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 12:50 +0100
                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 20:56 +0000
                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 21:34 +0000
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-28 23:52 +0000
                        Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 00:15 +0000
                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 02:53 +0000
                            Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 09:20 +0000
                          Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 15:48 +0000
                            Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 17:03 +0100
                              Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 16:17 +0000
                                Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 18:12 +0100
                                  Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 17:30 +0000
                                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:20 -0800
                                      Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 21:44 +0000
                                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 14:06 -0800
                                          Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 18:09 +0100
                                            Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-01 10:49 -0800
                                              Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-03-01 22:06 +0100
                                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:20 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 08:58 +0100
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:05 +0000
                        Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 09:16 +0100
                          Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-01 16:55 +0000
                            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 18:28 +0100
        Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 20:25 +0000
          Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-27 12:35 -0800
            Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-27 23:03 +0000
          Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-27 22:12 +0000
            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 12:54 +0100
              Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 13:13 +0000
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-28 15:08 +0100
                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:36 -0800
                  Re: Implicit String-Literal Concatenation Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-29 11:56 +0000
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 16:19 +0100
                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:36 +0000
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:53 -0800
                        Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-01 12:59 +0000
                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-01 20:59 +0000
                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:08 -0800
                  Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 14:31 +0000
                    Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-29 15:22 +0000
                      Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-29 13:10 -0800
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 13:45 -0800
                          Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-29 14:03 -0800
                            Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 14:14 -0800
                              Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-02 13:48 -0800
                              Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:48 +0000
                                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-04 20:55 -0800
                                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-07 21:08 +0000
                                    Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 21:44 +0000
                                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 14:25 -0800
                                        Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-03-07 23:00 +0000
                                          Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 15:46 -0800
                                        Re: Implicit String-Literal Concatenation "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-03-07 16:17 -0800
                                        Re: Implicit String-Literal Concatenation Richard Harnden <richard.nospam@gmail.invalid> - 2024-03-08 00:26 +0000
                                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-03-07 14:16 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 16:30 +0100
                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:25 -0800
                    Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 08:18 -0800
                      Re: Implicit String-Literal Concatenation Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-29 18:17 +0100
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:22 -0800
                          Re: Implicit String-Literal Concatenation Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-29 19:26 +0000
                            Re: Implicit String-Literal Concatenation James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-29 14:45 -0500
                Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:41 -0800
              Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 13:57 -0800
                Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-28 23:01 +0000
                  Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 15:31 -0800
                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 00:47 +0000
                      Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-28 17:12 -0800
                      Re: Implicit String-Literal Concatenation tTh <tth@none.invalid> - 2024-02-29 16:29 +0100
                        Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 16:15 +0000
                      Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 15:53 +0000
                        Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:06 -0800
                          Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 17:28 +0000
                            Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 18:58 +0100
                              Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 18:05 +0000
                                Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-02-29 18:09 +0000
                                  Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-29 21:27 +0000
                                    Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-03-01 11:52 +0000
                                      Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-05 04:47 +0000
                                        Re: Implicit String-Literal Concatenation scott@slp53.sl.home (Scott Lurndal) - 2024-03-05 15:09 +0000
                                          Re: Implicit String-Literal Concatenation Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-03-06 01:49 +0000
                                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 20:51 +0100
                Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 10:10 +0100
                  Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-02-29 10:18 +0000
                    Re: Implicit String-Literal Concatenation tTh <tth@none.invalid> - 2024-02-29 16:34 +0100
                      Re: Implicit String-Literal Concatenation bart <bc@freeuk.com> - 2024-03-01 11:58 +0000
                        Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-03-01 13:17 +0100
                  Re: Implicit String-Literal Concatenation Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-29 09:03 -0800
                    Re: Implicit String-Literal Concatenation David Brown <david.brown@hesbynett.no> - 2024-02-29 19:08 +0100

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#383156

On 28/02/2024 21:56, Lawrence D'Oliveiro wrote:
> On Wed, 28 Feb 2024 12:50:10 +0100, David Brown wrote:
> 
>> ... people write utilities for them in a variety of languages ...
>>
>> But it will often be more convenient to have it built into the language
>> and compiler.
> 
> What can be built into the language can only ever be a small subset of
> the many and varied ways that people have incorporated data blobs into
> their programs. 

Of course.  But that doesn't mean that a language should not include a 
feature that makes it easy for a lot of people to get some data blobs 
into their code.  Maybe /you/ won't find it useful, but other people will.

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

#383195

On Thu, 29 Feb 2024 08:58:40 +0100, David Brown wrote:

> On 28/02/2024 21:56, Lawrence D'Oliveiro wrote:
>>
>> On Wed, 28 Feb 2024 12:50:10 +0100, David Brown wrote:
>> 
>>> ... people write utilities for them in a variety of languages ...
>>>
>>> But it will often be more convenient to have it built into the
>>> language and compiler.
>> 
>> What can be built into the language can only ever be a small subset of
>> the many and varied ways that people have incorporated data blobs into
>> their programs.
> 
> Of course.  But that doesn't mean that a language should not include a
> feature that makes it easy for a lot of people to get some data blobs
> into their code.

Maybe the C compiler should concentrate on compiling C code, and leave it 
to the rest of the build toolchain to deal with other data.

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

#383209

On 29/02/2024 22:05, Lawrence D'Oliveiro wrote:
> On Thu, 29 Feb 2024 08:58:40 +0100, David Brown wrote:
> 
>> On 28/02/2024 21:56, Lawrence D'Oliveiro wrote:
>>>
>>> On Wed, 28 Feb 2024 12:50:10 +0100, David Brown wrote:
>>>
>>>> ... people write utilities for them in a variety of languages ...
>>>>
>>>> But it will often be more convenient to have it built into the
>>>> language and compiler.
>>>
>>> What can be built into the language can only ever be a small subset of
>>> the many and varied ways that people have incorporated data blobs into
>>> their programs.
>>
>> Of course.  But that doesn't mean that a language should not include a
>> feature that makes it easy for a lot of people to get some data blobs
>> into their code.
> 
> Maybe the C compiler should concentrate on compiling C code, and leave it
> to the rest of the build toolchain to deal with other data.

It is possible to be actively involved in the development of the 
standards - preparing and discussing proposals, joining committees, or 
at least joining mailing lists for the discussions.  If you are not 
doing the work and showing the interest /before/ decisions are made, you 
don't get a say afterwards.  It is more productive to discuss what you 
can do with the features C has, than to wish it never had them.

Oh, and the reason C23 has #embed, is because people want it.  It is 
something C developers have asked for for many years.  /You/ might not 
have use of it, but that's true of lots of features of C for all 
programmers - no one needs everything in the language and standard library.

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

#383220

On 2024-03-01, David Brown <david.brown@hesbynett.no> wrote:
> It is possible to be actively involved in the development of the 
> standards - preparing and discussing proposals, joining committees, or 
> at least joining mailing lists for the discussions.  If you are not 
> doing the work and showing the interest /before/ decisions are made, you 
> don't get a say afterwards.  It is more productive to discuss what you 
> can do with the features C has, than to wish it never had them.

Also, if you don't join the gang that breaks windows and spray
paints walls, you don't get to say aftward which windows are broken
and what is scribbled on what wall.

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

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

#383225

On 01/03/2024 17:55, Kaz Kylheku wrote:
> On 2024-03-01, David Brown <david.brown@hesbynett.no> wrote:
>> It is possible to be actively involved in the development of the
>> standards - preparing and discussing proposals, joining committees, or
>> at least joining mailing lists for the discussions.  If you are not
>> doing the work and showing the interest /before/ decisions are made, you
>> don't get a say afterwards.  It is more productive to discuss what you
>> can do with the features C has, than to wish it never had them.
> 
> Also, if you don't join the gang that breaks windows and spray
> paints walls, you don't get to say aftward which windows are broken
> and what is scribbled on what wall.
> 

A slightly closer version of that feeble analogy would be that you don't 
get to say they should have used a different colour, or broken doors 
instead of windows.

It's okay for Lawrence (or anyone else) to say that don't approve of 
#embed, or don't think they will use it themselves.  But like most 
(probably all) features in newer C standards, it was added because 
enough people wanted it for the committee and connected developers to do 
the work designing and documenting the features, and testing prototypes 
in practice.

There are procedures in place for people to have an influence on the 
future of C.  If you want to have your say, you can have it.  But 
waiting until a new standard version is solidified and then complaining 
that you don't like the direction it is taking, is too late.  Whining 
about things here afterwards doesn't do anyone any good.

That's different from saying you don't like the feature, or you don't 
like the way C is heading, or you won't use it yourself.  And it's 
different from talking about it, trying to learn how a new feature works 
and how to make the best of it.  Such discussions are great, and I'd 
love to see more of them here in c.l.c.

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

#383114

On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:

> And with C23, we will get #embed, though it is not yet supported by
> major tools.

More and more hacks on the preprocessor. Why not just get rid of it and 
replace it with something like m4?

Because then you will discover that string-based macros are inherently an 
unmanageable problem.

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

#383115

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
>> And with C23, we will get #embed, though it is not yet supported by
>> major tools.
>
> More and more hacks on the preprocessor. Why not just get rid of it and 
> replace it with something like m4?

Because it would invalidate 99% or more of existing C code.

(m4?  Seriously?)

> Because then you will discover that string-based macros are inherently an 
> unmanageable problem.

The C preprocessor operates on preprocessor tokens, not just strings.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383122

On Tue, 27 Feb 2024 12:35:35 -0800, Keith Thompson wrote:

> (m4?  Seriously?)

Do you know of any more powerful string-based macro processor?

> The C preprocessor operates on preprocessor tokens, not just strings.

Think of “hygienic” macros in the Lisps, and why that is just impossible 
in any string-based preprocessor.

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

#383117

On 27/02/2024 20:25, Lawrence D'Oliveiro wrote:
> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
> 
>> And with C23, we will get #embed, though it is not yet supported by
>> major tools.
> 
> More and more hacks on the preprocessor. Why not just get rid of it and
> replace it with something like m4?
> 
> Because then you will discover that string-based macros are inherently an
> unmanageable problem.

I hadn't notice that #embed was a preprocessor directive. But that is 
not the problem here, it is this:

"The expansion of a #embed directive is a token sequence formed from the 
list of integer constant expressions described below."

If a string like "ABC" really is converted to the five tokens 'A' comma 
'B' comma 'C', then it's going to make long strings and binary files 
inefficient.

Embedding a 100KB file will result in a 100KB bigger executable, but 
along the way it may have to generate 200,000 tokens within the 
compiler, half of them commas. Which in turn will need to be turned into 
100,000 integer expressions.

I would hope that implementations find some way of streamlining that 
process, perhaps by turning that 100KB of data directly into a 100KB string.

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

#383133

On 27/02/2024 23:12, bart wrote:
> On 27/02/2024 20:25, Lawrence D'Oliveiro wrote:
>> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
>>
>>> And with C23, we will get #embed, though it is not yet supported by
>>> major tools.
>>
>> More and more hacks on the preprocessor. Why not just get rid of it and
>> replace it with something like m4?
>>
>> Because then you will discover that string-based macros are inherently an
>> unmanageable problem.
> 
> I hadn't notice that #embed was a preprocessor directive. But that is 
> not the problem here, it is this:
> 
> "The expansion of a #embed directive is a token sequence formed from the 
> list of integer constant expressions described below."
> 
> If a string like "ABC" really is converted to the five tokens 'A' comma 
> 'B' comma 'C', then it's going to make long strings and binary files 
> inefficient.
> 
> Embedding a 100KB file will result in a 100KB bigger executable, but 
> along the way it may have to generate 200,000 tokens within the 
> compiler, half of them commas. Which in turn will need to be turned into 
> 100,000 integer expressions.
> 
> I would hope that implementations find some way of streamlining that 
> process, perhaps by turning that 100KB of data directly into a 100KB 
> string.

They won't use strings, they will use data blobs - binary data.  Then 
there is no issue with null bytes.  And yes, implementations will skip 
the token generation (unless you are doing something weird, such as 
using #embed to read the parameters to a function call).

Tests with prototype implementations gave extremely fast results.

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

#383136

On 28/02/2024 11:54, David Brown wrote:
> On 27/02/2024 23:12, bart wrote:
>> On 27/02/2024 20:25, Lawrence D'Oliveiro wrote:
>>> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
>>>
>>>> And with C23, we will get #embed, though it is not yet supported by
>>>> major tools.
>>>
>>> More and more hacks on the preprocessor. Why not just get rid of it and
>>> replace it with something like m4?
>>>
>>> Because then you will discover that string-based macros are 
>>> inherently an
>>> unmanageable problem.
>>
>> I hadn't notice that #embed was a preprocessor directive. But that is 
>> not the problem here, it is this:
>>
>> "The expansion of a #embed directive is a token sequence formed from 
>> the list of integer constant expressions described below."
>>
>> If a string like "ABC" really is converted to the five tokens 'A' 
>> comma 'B' comma 'C', then it's going to make long strings and binary 
>> files inefficient.
>>
>> Embedding a 100KB file will result in a 100KB bigger executable, but 
>> along the way it may have to generate 200,000 tokens within the 
>> compiler, half of them commas. Which in turn will need to be turned 
>> into 100,000 integer expressions.
>>
>> I would hope that implementations find some way of streamlining that 
>> process, perhaps by turning that 100KB of data directly into a 100KB 
>> string.
> 
> They won't use strings, they will use data blobs - binary data.  Then 
> there is no issue with null bytes.

AFAIK strings in C can have embedded zeros when not assumed to be 
zero-terminated. So here:

     char s[]={1,2,3,0,4,5,6};

s will have a length of 7.

>  And yes, implementations will skip 
> the token generation (unless you are doing something weird, such as 
> using #embed to read the parameters to a function call).

What happens if you do -E to preprocess only?

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

#383137

On 28/02/2024 14:13, bart wrote:
> On 28/02/2024 11:54, David Brown wrote:
>> On 27/02/2024 23:12, bart wrote:
>>> On 27/02/2024 20:25, Lawrence D'Oliveiro wrote:
>>>> On Tue, 27 Feb 2024 09:36:38 +0100, David Brown wrote:
>>>>
>>>>> And with C23, we will get #embed, though it is not yet supported by
>>>>> major tools.
>>>>
>>>> More and more hacks on the preprocessor. Why not just get rid of it and
>>>> replace it with something like m4?
>>>>
>>>> Because then you will discover that string-based macros are 
>>>> inherently an
>>>> unmanageable problem.
>>>
>>> I hadn't notice that #embed was a preprocessor directive. But that is 
>>> not the problem here, it is this:
>>>
>>> "The expansion of a #embed directive is a token sequence formed from 
>>> the list of integer constant expressions described below."
>>>
>>> If a string like "ABC" really is converted to the five tokens 'A' 
>>> comma 'B' comma 'C', then it's going to make long strings and binary 
>>> files inefficient.
>>>
>>> Embedding a 100KB file will result in a 100KB bigger executable, but 
>>> along the way it may have to generate 200,000 tokens within the 
>>> compiler, half of them commas. Which in turn will need to be turned 
>>> into 100,000 integer expressions.
>>>
>>> I would hope that implementations find some way of streamlining that 
>>> process, perhaps by turning that 100KB of data directly into a 100KB 
>>> string.
>>
>> They won't use strings, they will use data blobs - binary data.  Then 
>> there is no issue with null bytes.
> 
> AFAIK strings in C can have embedded zeros when not assumed to be 
> zero-terminated. So here:
> 
>      char s[]={1,2,3,0,4,5,6};
> 
> s will have a length of 7.

That's not a string, it's an array of char.  A "string" in C is "a 
contiguous sequence of characters terminated by and including the first 
null character".  The difference is crucial in respect to the handling 
of null bytes.  And it is the main reason for #embed generating a 
comma-separated sequence of integer constants rather than a string.  (It 
also avoids messy hex character sequences if you show the output of 
#embed somewhere.)

> 
>>   And yes, implementations will skip the token generation (unless you 
>> are doing something weird, such as using #embed to read the parameters 
>> to a function call).
> 
> What happens if you do -E to preprocess only?
> 

That's something weird :-)

I guess you get the integer list.

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

#383143

bart <bc@freeuk.com> writes:
[...]
> AFAIK strings in C can have embedded zeros when not assumed to be
> zero-terminated. So here:
>
>     char s[]={1,2,3,0,4,5,6};
>
> s will have a length of 7.

Strings *by definition* cannot have embedded zeros.  A null character
terminates a string.

A string literal can have embedded \0 characters, but if you're
suggesting that #embed should expand to a string literal, I can see
several disadvantages and no significant advantages.  For one thing, the
data may or may not end with a null character; string literals always
do.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383162

On 28/02/2024 21:36, Keith Thompson wrote:
> bart <bc@freeuk.com> writes:
> [...]
>> AFAIK strings in C can have embedded zeros when not assumed to be
>> zero-terminated. So here:
>>
>>      char s[]={1,2,3,0,4,5,6};
>>
>> s will have a length of 7.
> 
> Strings *by definition* cannot have embedded zeros.  A null character
> terminates a string.
> 
C strings. Not strings in other programming languages. And only if you 
define "C strings" in a rather restrictive but, to be fair, totally 
legitimate way. So I wouldn't have put in the asterisks.

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

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

#383165

On 29/02/2024 12:56, Malcolm McLean wrote:
> On 28/02/2024 21:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>> zero-terminated. So here:
>>>
>>>      char s[]={1,2,3,0,4,5,6};
>>>
>>> s will have a length of 7.
>>
>> Strings *by definition* cannot have embedded zeros.  A null character
>> terminates a string.
>>
> C strings. Not strings in other programming languages.

Let me point you to the name of this Usenet group.

And strings in any programming language have either :

1. A string of characters and a terminating null, thus no embedded null 
characters.
2. A starting length (such as Pascal strings).
3. A fixed size.
4. A more advanced structure.

An array of bytes is not a "string".

> And only if you 
> define "C strings" in a rather restrictive but, to be fair, totally 
> legitimate way. So I wouldn't have put in the asterisks.
> 

The definition of "C string" is given in section 7.1.1p1 of the C 
standards.  There is only one definition of "C string".

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

#383200

On Thu, 29 Feb 2024 16:19:45 +0100, David Brown wrote:

> An array of bytes is not a "string".

It is in PHP, I think also in Perl, and also in (obsolete) Python 2.

And what about C string functions that take explicit lengths?

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

#383203

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Thu, 29 Feb 2024 16:19:45 +0100, David Brown wrote:
>> An array of bytes is not a "string".
>
> It is in PHP, I think also in Perl, and also in (obsolete) Python 2.

I'm fairly sure that strings are of a distinct non-array type in all
three of those languages.  If you're curious about the details, consult
the relevant documentation or post in an appropriate newsgroup.

> And what about C string functions that take explicit lengths?

What about them?

The C standard defines the term "string" (7.1.1 paragraph 1).  Do you
dispute that definition?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

#383213

On 29/02/2024 21:36, Lawrence D'Oliveiro wrote:
> On Thu, 29 Feb 2024 16:19:45 +0100, David Brown wrote:
> 
>> An array of bytes is not a "string".
> 
> It is in PHP, I think also in Perl, and also in (obsolete) Python 2.
> 
> And what about C string functions that take explicit lengths?

You mean: There's a danger that a function that returns a 'string', but 
truncates it to n chars, might not be returning a string at all ?

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

#383229

On Fri, 1 Mar 2024 12:59:43 +0000, Richard Harnden wrote:

> You mean: There's a danger that a function that returns a 'string', but
> truncates it to n chars, might not be returning a string at all ?

If it’s not NUL-terminated, then it’s not a “string”, right?

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

#383174

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 28/02/2024 21:36, Keith Thompson wrote:
>> bart <bc@freeuk.com> writes:
>> [...]
>>> AFAIK strings in C can have embedded zeros when not assumed to be
>>> zero-terminated. So here:
>>>
>>>      char s[]={1,2,3,0,4,5,6};
>>>
>>> s will have a length of 7.
>> Strings *by definition* cannot have embedded zeros.  A null
>> character
>> terminates a string.
>> 
> C strings. Not strings in other programming languages. And only if you
> define "C strings" in a rather restrictive but, to be fair, totally 
> legitimate way. So I wouldn't have put in the asterisks.

Yes, C strings.  Or has we call them here in comp.lang.c, strings.

Sheesh.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

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

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

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

csiph-web