James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated
by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space"
- but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated
by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space"
- but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
I learned a couple of decades ago that adjacent string literals get concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that "Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated
by white-space do not qualify as adjacent. There's also no mention of white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space"
- but that doesn't seem obvious to me.
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated
by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space"
- but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
On 2021-01-26 13:22, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated >>> by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space" >>> - but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
The interesting situation is cases like these:
"a" /* Long comment explaining why b is the next byte */ "b"
And
#define LEAD_BYTE "a"
#define TRAIL_BYTE "b"
LEAD_BYTE TRAIL_BYTE
On 1/26/21 7:22 AM, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated >>> by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space" >>> - but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
No, I would not - and that's precisely because "long int x" is not
parsed as a declaration until translation phase 7, and the very first sentence of the description of that phase says "White-space characters separating tokens are no longer significant.". Phase 6 occurs before
that sentence applies, which is precisely my point.
On 2021-01-26 13:22, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated >>> by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space" >>> - but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
The interesting situation is cases like these:
"a" /* Long comment explaining why b is the next byte */ "b"
And
#define LEAD_BYTE "a"
#define TRAIL_BYTE "b"
LEAD_BYTE TRAIL_BYTE
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
On 1/26/21 7:22 AM, Ben Bacarisse wrote:
No, I would not - and that's precisely because "long int x" is not
parsed as a declaration until translation phase 7, and the very first
sentence of the description of that phase says "White-space characters
separating tokens are no longer significant.". Phase 6 occurs before
that sentence applies, which is precisely my point.
I meant at the stage you were asking about: phase 6. The example was an attempt to find out if your reluctance to see "a" "b" as being adjacent
was in part due to do with the fact that they could have been written
with no spaces.
I think your answer makes it clear that, at phase 6, you think that
there are no two tokens adjacent to one another. I find that a rather artificial reading.
On 1/26/21 4:46 PM, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
On 1/26/21 7:22 AM, Ben Bacarisse wrote:
No, I would not - and that's precisely because "long int x" is not
parsed as a declaration until translation phase 7, and the very first
sentence of the description of that phase says "White-space characters
separating tokens are no longer significant.". Phase 6 occurs before
that sentence applies, which is precisely my point.
I meant at the stage you were asking about: phase 6. The example was an
attempt to find out if your reluctance to see "a" "b" as being adjacent
was in part due to do with the fact that they could have been written
with no spaces.
Yes, it is. In "a""b", the two tokens are adjacent. In "a" "b", they are
not, because both are adjacent to some white-space instead.
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
Yes, it is. In "a""b", the two tokens are adjacent. In "a" "b", they are
not, because both are adjacent to some white-space instead.
Adjacent does not mean with nothing in between (thought it can, of
course). What's more, things can be adjacent to each other, and also adjacent to something in between. I can say that there was a fire in
the house adjacent to mine. The two house are adjacent. But both are adjacent to the lane separating them.
On 1/26/21 8:16 PM, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
Yes, it is. In "a""b", the two tokens are adjacent. In "a" "b", they are >>> not, because both are adjacent to some white-space instead.
Adjacent does not mean with nothing in between (thought it can, of
course). What's more, things can be adjacent to each other, and also
adjacent to something in between. I can say that there was a fire in
the house adjacent to mine. The two house are adjacent. But both are
adjacent to the lane separating them.
It takes at least two dimensions for the issue you raise to come up.
As
far as the C standard is concerned, source code is a one-dimensional
sequence of characters. It's possible to think of the text
two-dimensionally, but the standard doesn't make use of that fact in any
way that I'm aware of. I don't think anyone would suggest that two
string literals that are vertically adjacent to each other:
char first = "James";
char second = "Kuyper";
should be merged.
Even if you acknowledge only that this is one possible way of
interpreting "adjacent", that would mean the meaning is ambiguous.
Moving the first sentence of translation phase 7 to be the first
sentence of translation phase 6 would remove all ambiguity, and have, as
far as I can see, no other consequence.
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
On 1/26/21 8:16 PM, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
Yes, it is. In "a""b", the two tokens are adjacent. In "a" "b", they are >>>> not, because both are adjacent to some white-space instead.
Adjacent does not mean with nothing in between (thought it can, of
course). What's more, things can be adjacent to each other, and also
adjacent to something in between. I can say that there was a fire in
the house adjacent to mine. The two house are adjacent. But both are
adjacent to the lane separating them.
It takes at least two dimensions for the issue you raise to come up.
I don't follow. 1 and 2 are adjacent integers on the real line
(i.e. despite having other kinds of number between them). In addition,
they are both integers adjacent to 1/2.
Moving the first sentence of translation phase 7 to be the first
sentence of translation phase 6 would remove all ambiguity, and have, as
far as I can see, no other consequence.
I think the strongest case for the possibility of misunderstanding comes
from this sentence being where it is. I don't see any problem with the
word "adjacent", but I can imagine someone wondering why this sentence
is where it is if not to do what you are suggesting.
On 1/27/21 10:46 AM, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
On 1/26/21 8:16 PM, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:...
Yes, it is. In "a""b", the two tokens are adjacent. In "a" "b", they are >>>>> not, because both are adjacent to some white-space instead.
Adjacent does not mean with nothing in between (thought it can, of
course). What's more, things can be adjacent to each other, and also
adjacent to something in between. I can say that there was a fire in
the house adjacent to mine. The two house are adjacent. But both are >>>> adjacent to the lane separating them.
It takes at least two dimensions for the issue you raise to come up.
I don't follow. 1 and 2 are adjacent integers on the real line
(i.e. despite having other kinds of number between them). In addition,
they are both integers adjacent to 1/2.
I'm not familiar with any meaning that could reasonably be attached to "adjacent" which would make either of those statements true.
In the future, I will try to remember that there's at least one person
who does attach such a meaning to that word - but it would make it
easier for me to understand how you could say such a thing if you
would specify that definition.
When using a meaning that allows 1 and 2 to be both adjacent to 1/2,
while also being adjacent to each other, how do you interpret "adjacent string literal" so that it doesn't apply to
ptrdiff_t d = "Ben"-"Bacarisse";
It seems to me that, despite having no idea how you could possibly mean
what you seem to have said, I can make a direct analogy, matching 1 with "Ben", 1/2 with '-', and 2 with "Bacarisse". So, how does that analogy
break down? Or are you claiming that they should be concatenated?
...
Moving the first sentence of translation phase 7 to be the first
sentence of translation phase 6 would remove all ambiguity, and have, as >>> far as I can see, no other consequence.
I think the strongest case for the possibility of misunderstanding comes
from this sentence being where it is. I don't see any problem with the
word "adjacent", but I can imagine someone wondering why this sentence
is where it is if not to do what you are suggesting.
I think you just agreed with me, but you didn't quite say so directly.
Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:
On 2021-01-26 13:22, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that >>>> "Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance >>>> until translation phase 7. Therefore, string literals that are separated >>>> by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space" >>>> - but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens
are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
The interesting situation is cases like these:
"a" /* Long comment explaining why b is the next byte */ "b"
By translation phase 6 (when adjacent string literals are concatenated)
this has become
"a" "b"
And
#define LEAD_BYTE "a"
#define TRAIL_BYTE "b"
LEAD_BYTE TRAIL_BYTE
And this has become
"a" "b"
Am I missing some ambiguity?
On 2021-01-26 22:40, Ben Bacarisse wrote:
Jakob Bohm <jb-usenet@wisemo.com.invalid> writes:
On 2021-01-26 13:22, Ben Bacarisse wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that >>>>> "Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance >>>>> until translation phase 7. Therefore, string literals that are separated >>>>> by white-space do not qualify as adjacent. There's also no mention of >>>>> white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me >>>>> that "adjacent" should be understood as "adjacent, ignoring white-space" >>>>> - but that doesn't seem obvious to me.
Surely it just means "next to", and in the sequence of tokens "a" "b"
the two are next to each other. It happens that string literal tokens >>>> are such that they can be adjacent without having any white-space
between then, but I suspect that's making you over-think the meaning.
Would you say that 'long int x' has no tokens adjacent to any others?
The interesting situation is cases like these:
"a" /* Long comment explaining why b is the next byte */ "b"
By translation phase 6 (when adjacent string literals are concatenated)
this has become
"a" "b"
And
#define LEAD_BYTE "a"
#define TRAIL_BYTE "b"
LEAD_BYTE TRAIL_BYTE
And this has become
"a" "b"
Am I missing some ambiguity?
Sorry, but I couldn't easily find the definition of the translation
phases, only scattered mentions of "phase 6" and "phase 7", so I had to
guess which practically related language features were buried in that distinction.
I learned a couple of decades ago that adjacent string literals get concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that "Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated
by white-space do not qualify as adjacent. There's also no mention of white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space"
- but that doesn't seem obvious to me. It also sounds vaguely familiar,
like I've had this discussion with someone before, but I can't locate
the discussion. Every example of adjacent string literals that appears
in the standard has at least one white-space character separating them,
so the intent is crystal-clear, but the wording doesn't clearly say so.
If the phrase "White-space characters separating tokens are no longer significant." were moved from the beginning of the description of phase
7 to the beginning of the description phase 6, it would make the insignificance of white space separating string literals perfectly
clear, and as far as I can see, would have no other effect
James Kuyper <jameskuyper@alumni.caltech.edu> writes:[...]
If the phrase "White-space characters separating tokens are no longer
significant." were moved from the beginning of the description of phase
7 to the beginning of the description phase 6, it would make the
insignificance of white space separating string literals perfectly
clear, and as far as I can see, would have no other effect
The word "adjacent" doesn't alway mean touching. There is another
word for that, the word "adjoining". Booking a hotel reservation
for adjacent rooms is not the same as a reservation for adjoining
rooms.
James Kuyper <james...@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that "Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance until translation phase 7. Therefore, string literals that are separated
by white-space do not qualify as adjacent. There's also no mention of white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space"
- but that doesn't seem obvious to me. It also sounds vaguely familiar, like I've had this discussion with someone before, but I can't locate
the discussion. Every example of adjacent string literals that appears
in the standard has at least one white-space character separating them,
so the intent is crystal-clear, but the wording doesn't clearly say so.
If the phrase "White-space characters separating tokens are no longer significant." were moved from the beginning of the description of phaseThe word "adjacent" doesn't alway mean touching. There is another
7 to the beginning of the description phase 6, it would make the insignificance of white space separating string literals perfectly
clear, and as far as I can see, would have no other effect
word for that, the word "adjoining". Booking a hotel reservation
for adjacent rooms is not the same as a reservation for adjoining
rooms.
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
If the phrase "White-space characters separating tokens are no longer
significant." were moved from the beginning of the description of phase
7 to the beginning of the description phase 6, it would make the
insignificance of white space separating string literals perfectly
clear, and as far as I can see, would have no other effect
The word "adjacent" doesn't alway mean touching. There is another
word for that, the word "adjoining". Booking a hotel reservation
for adjacent rooms is not the same as a reservation for adjoining
rooms.
That's not entirely clear. dictionary.com (not a definitive reference
but a convenient one) shows "adjoining" as one of the definitions of "adjacent".
If I understand you correctly, if rooms 110 and 112 share a common wall, perhaps with a door going between them, they're both adjacent and
adjoining,
but if instead they're on opposide sides of the elevator
they're adjacent but not adjoining. Is that what you meant? I'm not
sure I'd call them "adjacent" in that case.
A footnote on "Adjacent string literals are concatenated" saying that
two string literals are adjacent if they're adjoining or separated only
by white-space characters would clear this up. Moving "White-space characters separating tokens are no longer significant." from the
beginning of phase 7 to the beginning of phase 6 would also be a good solution.
But given the clear examples, I wouldn't object to leaving it as it is.
On Saturday, July 10, 2021 at 11:49:09 AM UTC-4, Tim Rentsch wrote:
James Kuyper <james...@alumni.caltech.edu> writes:
I learned a couple of decades ago that adjacent string literals get
concatenated into a single longer literal, even if separated by
arbitrarily large amounts of white-space.
Yesterday I happened to notice that translation phase 6 says only that
"Adjacent string literal tokens are concatenated.", without saying
anything about white-space. White-space doesn't lose it's significance
until translation phase 7. Therefore, string literals that are separated >>> by white-space do not qualify as adjacent. There's also no mention of
white-space in the fuller discussion that occurs in 6.4.5p5.
Am I missing something obvious here? I can imagine someone telling me
that "adjacent" should be understood as "adjacent, ignoring white-space" >>> - but that doesn't seem obvious to me. It also sounds vaguely familiar, >>> like I've had this discussion with someone before, but I can't locate
the discussion. Every example of adjacent string literals that appears
in the standard has at least one white-space character separating them,
so the intent is crystal-clear, but the wording doesn't clearly say so.
If the phrase "White-space characters separating tokens are no longer
significant." were moved from the beginning of the description of phase
7 to the beginning of the description phase 6, it would make the
insignificance of white space separating string literals perfectly
clear, and as far as I can see, would have no other effect
The word "adjacent" doesn't alway mean touching. There is another
word for that, the word "adjoining". Booking a hotel reservation
for adjacent rooms is not the same as a reservation for adjoining
rooms.
But, if it doesn't mean "touching", what does it mean?
If a blank space
doesn't prevent them from being adjacent, what does?
How do you
draw the line between things that do prevent two string literals from
being adjacent, and things that don't?
And - most importantly, where in the actual text of the standard
does it clearly make that distinction?
I contend that it doesn't clearly make that distinction anywhere,
but
that moving the sentence "White-space characters separating
tokens are no longer significant." From the beginning of phase 7 to
the beginning of phase 6 would remove all ambiguity, making the text
match the way all real world implementations actually handle this
issue, and would have no other effect. Do you disagree?
If so, with which part of what I just said, and for what reason?
James Kuyper <james...@alumni.caltech.edu> writes:...
On Saturday, July 10, 2021 at 11:49:09 AM UTC-4, Tim Rentsch wrote:
The word "adjacent" doesn't alway mean touching. There is another
word for that, the word "adjoining". Booking a hotel reservation
for adjacent rooms is not the same as a reservation for adjoining
rooms.
But, if it doesn't mean "touching", what does it mean?In hotels, normally it means on the same floor and with no
intervening rooms or other major building structures (but small
things like utility closets don't count). In a country inn where
there are standalone cottages rather than rooms, two cottages
would normally be called adjacent if there were no other cottages
in between, and the cottages in question were not inordinately far
apart.
In the C standard it means having no intervening tokens.
If a blank spaceAnother token (not a string literal token, presumably, ...
doesn't prevent them from being adjacent, what does?
... but only
because we might consider a sequence of string literal tokens
to be "adjacent tokens").
I contend that it doesn't clearly make that distinction anywhere,If I may make a suggestion, how you read the C standard doesn't
match the reading mode expected by its authors. ...
... If no one else has noticed it in
more than 30 years, what does that say about how clear or unclear
the distinction is?
On Thursday, July 22, 2021 at 6:26:22 PM UTC-4, Tim Rentsch wrote:
James Kuyper <james...@alumni.caltech.edu> writes:
On Saturday, July 10, 2021 at 11:49:09 AM UTC-4, Tim Rentsch wrote:
...
The word "adjacent" doesn't alway mean touching. There is
another word for that, the word "adjoining". Booking a hotel
reservation for adjacent rooms is not the same as a reservation
for adjoining rooms.
But, if it doesn't mean "touching", what does it mean?
In hotels, normally it means on the same floor and with no
intervening rooms or other major building structures (but small
things like utility closets don't count). In a country inn where
there are standalone cottages rather than rooms, two cottages
would normally be called adjacent if there were no other cottages
in between, and the cottages in question were not inordinately
far apart.
In the C standard it means having no intervening tokens.
If a blank space
doesn't prevent them from being adjacent, what does?
Another token (not a string literal token, presumably, ...
I think your wording got a little confused there. In "A""B""C",
the "B" string literal token definitely does prevent the "A" and
"C" string literal tokens from being considered adjacent. An
implementation would certainly be non-conforming if it
concatenated "A" directly to "C" without first concatenating one
or the other with "B". The following wording may be intended to
address that issue:
... but only
because we might consider a sequence of string literal tokens
to be "adjacent tokens").
but it's not very clear that it does. The simpler approach is to
say that the one thing that unambiguously DOES prevent two string
literal tokens from being considered adjacent is another string
literal token. The only real question is whether there's anything
else that does so.
[...]
I contend that it doesn't clearly make that distinction anywhere,
If I may make a suggestion, how you read the C standard doesn't
match the reading mode expected by its authors. ...
Your reading mode puts too much emphasis on guessing the intent of
the authors,
and not enough on trying to write the text clearly
enough to avoid the need for such guesswork.
You might be right that it is the intended reading mode, but if
so, I consider it a seriously flawed one.
... If no one else has noticed it in
more than 30 years, what does that say about how clear or unclear
the distinction is?
You can't be sure that no one else has noticed it, [...]
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 365 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:19:33 |
Calls: | 7,753 |
Calls today: | 4 |
Files: | 12,891 |
Messages: | 5,743,002 |