Strings in C source code

[Jason Curl]

Hello,

Is it legal to have a non-quote terminated string in C?

For example:

printf("Hello World
\n");

instead of what I normally use

printf("Hello World"
"\n");

I had believed not, but some compilers seem to allow this. Just want to
be sure if this is a problem with my Compiler, or if it really is
allowed. <ot> does anyone know of compilers that allow this? </ot>

Thanks
Jason.

[Abhilash]

It is not legal.

[Abhilash]

It is not Legal. See K&R2 page 7.

[Martin Ambuhl]

Abhilash wrote:

It is not legal.

You are right that strings cannot be broken across end-of-lines without
changing them to multiple strings to be concatenated, but snipping away
all context only works for people using toys like google groups to read
newsgroups.

[chris]

Martin Ambuhl wrote:

Abhilash wrote:

It is not legal.

You are right that strings cannot be broken across end-of-lines without
changing them to multiple strings to be concatenated, but snipping away
all context only works for people using toys like google groups to read
newsgroups.

I would say that any newsreader which is displaying conversations in a
threaded manner is in the "toy" category.

Chris

[chris]

chris wrote:

Martin Ambuhl wrote:

Abhilash wrote:

It is not legal.

You are right that strings cannot be broken across end-of-lines
without changing them to multiple strings to be concatenated, but
snipping away all context only works for people using toys like google
groups to read newsgroups.

I would say that any newsreader which is

*NOT* displaying conversations in a threaded manner is in the "toy" category.

That will teach me to post off-topic ¬_¬

[Jason Curl]

Martin Ambuhl wrote:

Abhilash wrote:

It is not legal.

You are right that strings cannot be broken across end-of-lines without
changing them to multiple strings to be concatenated, but snipping away
all context only works for people using toys like google groups to read
newsgroups.

Thanks!

[S.Tobias]

Jason Curl <j_****************************@foo.bar> wrote:

For example: printf("Hello World
\n"); instead of what I normally use printf("Hello World"
"\n");

I have seen such code and believe that:
"A
B"
is equivalent to:
"A\nB"
so in your example:
printf("Hello World
\n");
should actually equal:
printf("Hello World\n \n");
(note two'\n's and spaces between them).

As an aside:
"A
B
C"
could be easily converted to proper form by appending '\\'s:
"A\n\
B\n\
C"
(the "concatenation" is managed by the preprocessor).

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Flash Gordon]

On Wed, 27 Oct 2004 11:17:09 +0100
chris <ca*@cs.york.ac.uk> wrote:

chris wrote:

Martin Ambuhl wrote:

Abhilash wrote:

It is not legal.
You are right that strings cannot be broken across end-of-lines
without changing them to multiple strings to be concatenated, but
snipping away all context only works for people using toys like
google groups to read newsgroups.

I would say that any newsreader which is

*NOT*

displaying conversations in a threaded manner is in the "toy"
category.

That will teach me to post off-topic ¬_¬

However, someone might not have received the post that is being replied
to, or might have read it three weeks ago last Thursday and forgotten
it. So you can be using a decent news reader and still need the context.

Obviously I am not getting at you Chris, since you are quoting properly.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Robert Harris]

S.Tobias wrote:

Jason Curl <j_****************************@foo.bar> wrote:
[snip]
Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything. There is no standard new-line character. That is OS-dependent.

[S.Tobias]

Robert Harris <ro*****************@blueyonder.co.uk> wrote:

S.Tobias wrote:

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

There is no standard new-line character. That is OS-dependent.

I agree, but:
# 5.2.1 Character sets
# [#3] [...] In source files, there shall be some way
# of indicating the end of each line of text; this
# International Standard treats such an end-of-line indicator
# as if it were a single new-line character.
I asked my question in above context.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Dave Vandervies]

In article <KG*********************@fe2.news.blueyonder.co.uk >,
Robert Harris <ro*****************@blueyonder.co.uk> wrote:

S.Tobias wrote:

Jason Curl <j_****************************@foo.bar> wrote:
[snip]
Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

There is no standard new-line character. That is OS-dependent.

Not the reason, since it would be trivial to define `appropriate
representation of end-of-line in source file' to be mapped to '\n'
if it's encountered inside a string.

My first guess would be that it makes tokenizing and/or preprocessing
harder than it would be otherwise, but (never having written a lexer or
preprocessor for C) I can't say for sure that this is it.

It also has the potential to make source code harder to read, with no
real benefits. (C isn't exactly optimized for readibility, but most of
the potential readability problems do in fact have some other benefit
to go along with it.)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Unnecessary casts are the tool of evil (and of C++ programmers, but I
repeat myself).
--Richard Bos in comp.lang.c

[Keith Thompson]

"S.Tobias" <sN*******@amu.edu.pl> writes:
[...]

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

The reader's patience, perhaps.

Allowing embedded newlines in string literals would make it difficult
or impossible to tell how many trailing blanks there are before the
newline. It would cause string literals to be the only kind of token
that can cross line boundaries. And given that adjacent string
literals are catenated and a newline can be represented as "\n",
there's absolutely no need for it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dan Pop]

In <KG*********************@fe2.news.blueyonder.co.uk > Robert Harris <ro*****************@blueyonder.co.uk> writes:

S.Tobias wrote:

Jason Curl <j_****************************@foo.bar> wrote:
[snip]
Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

There is no standard new-line character. That is OS-dependent.

What makes you think that a standard newline character, the same on all
platforms, would be needed for supporting this feature? After all, each
compiler must be able to tell the end of each line, otherwise it
couldn't handle the \<newline> sequence properly, as well as the
preprocessing directives, that are newline terminated.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Flash Gordon]

On Wed, 27 Oct 2004 13:48:26 GMT
Robert Harris <ro*****************@blueyonder.co.uk> wrote:

S.Tobias wrote:

Jason Curl <j_****************************@foo.bar> wrote:
[snip]
Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

There is no standard new-line character. That is OS-dependent.

There is within C with appropriate translations being performed
automatically by the implementation on reading/writing text streams.
--
Flash Gordon
Sometimes I think shooting would be far too good for some people.
Although my email address says spam, it is real and I read it.

[Dan Pop]

In <2u*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

Imagine what would happen if you forgot to close a string literal.

It's nice to have a syntax that allows the compiler to diagnose as many
errors as possible on the source code line where they do occur. From
this point of view, C already has a problem with unclosed comments and
mismatched braces. Even a missing semicolon may generate a puzzling
diagnostic. No need to extend the list by adding features with little to
no redeeming merits.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Michael Wojcik]

In article <cl**********@pump1.york.ac.uk>, chris <ca*@cs.york.ac.uk> writes:

chris wrote:

Martin Ambuhl wrote:

Abhilash wrote:

It is not legal.

You are right that strings cannot be broken across end-of-lines
without changing them to multiple strings to be concatenated, but
snipping away all context only works for people using toys like google
groups to read newsgroups.

I would say that any newsreader which is

*NOT*

displaying conversations in a threaded manner is in the "toy" category.

And I'd say you're wrong. There are excellent reasons not to display
Usenet posts in a threaded manner. For one, threading requires
downloading the headers (at least the Subject and References headers)
of all the available unread messages for a group; where bandwidth is
constrained, that would be a poor approach.

Not all Usenet participants want to see a threaded display. The
user agent I'm using - xrn - does threading, but I have it disabled.
xrn's sorted-subject mode suffices for my needs.

Further, Martin's advice accords with the most recent IETF drafts for
updating RFC 1036, so clearly there's some consensus, among people
who care enough about the subject to attend to the development of
relevant standards, that removing all context is the wrong thing to
do.

--
Michael Wojcik mi************@microfocus.com

You have Sun saying, "Who needs Linux? We have Solaris." You have
Microsoft saying, "Who needs Linux? We have Windows 2000." Then you
have IBM saying, "I think we all need Linux." Only the greatest
sinners know how to really repent. -- John Patrick, IBM VP

[Michael Wojcik]

In article <2u*************@uni-berlin.de>, "S.Tobias" <sN*******@amu.edu.pl> writes:

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

Allow string literals to extend across lines.

Begin a string literal on line N. Omit the closing quote character.
Where does that literal end? At the next quote character in the
file, regardless of where it occurs.

Now, as soon as you accidentally leave off the closing quote from
a string literal, you invert what's a string literal and what's
not, for the remainder of the source file:

char *foo = "whoops; /* one string */
char *bar = "something else";

Here, if string literals were allowed to continue past the end of
the line, foo would point to a string beginning with "whoops;" and
ending with "bar = ". "something else" would not be a string
literal, and so forth.

The resulting diagnostics are likely to be ugly, and in some
circumstances quite confusing.

Since it's trivial to construct multiline string literals correctly
(through string-literal concatenation), there's nothing to be gained
by letting them extend across lines.

--
Michael Wojcik mi************@microfocus.com

Memory, I realize, can be an unreliable thing; often it is heavily coloured
by the circumstances in which one remembers, and no doubt this applies to
certain of the recollections I have gathered here. -- Kazuo Ishiguro

[pete]

Martin Ambuhl wrote:

Abhilash wrote:

It is not legal.

You are right that strings cannot be broken across
end-of-lines without changing them to multiple strings
to be concatenated,

#include <stdio.h>\

int main(void)\
{\
puts("\
Strings \
can be broken across lines of source code,\n\
if a backslash \
is placed at the line break.\
");\
return 0;\
}\
but snipping away
all context only works for people using toys like google
groups to read newsgroups.

--
pete

[pete]

S.Tobias wrote:

Jason Curl <j_****************************@foo.bar> wrote:

For example:

printf("Hello World
\n");

instead of what I normally use

printf("Hello World"
"\n");

I have seen such code and believe that:
"A
B"
is equivalent to:
"A\nB"
so in your example:
printf("Hello World
\n");
should actually equal:
printf("Hello World\n \n");
(note two'\n's and spaces between them).

As an aside:
"A
B
C"
could be easily converted to proper form by appending '\\'s:
"A\n\
B\n\
C"
(the "concatenation" is managed by the preprocessor).

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

Everybody else but me seems to know what you're talking about.
Are you saying that "\n\n\n" isn't OK?

--
pete

[Dave Vandervies]

In article <41***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:

S.Tobias wrote:

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

Everybody else but me seems to know what you're talking about.
Are you saying that "\n\n\n" isn't OK?

No, that would be `embedded newlines [represented by the `\n' escape]
inside strings [represented by string literals]'.

He's talking about a (unescaped) newline (not the `\n' escape representing
the newline character) in the source representation of a string literal,
like this:
char *str="string literal with a
newline in the middle"
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
[i]n some circles having a degree does not make you superior to those
around you; it merely makes you a bit less inferior.
--Giles Malet in uw.general

[Matthew Johnson]

In article <41***********@mindspring.com>, pete says...

S.Tobias wrote:

Jason Curl <j_****************************@foo.bar> wrote:

> For example:

> printf("Hello World
> \n");

> instead of what I normally use

> printf("Hello World"
> "\n");

I have seen such code
But this code is _different_ from what you propose: the above code works because
of C's string literal concatenation. The whitespace between the closing " of
"Hellow World" and the opening quote of '"\n" is IGNORED.
and believe that:

"A
B"
is equivalent to:
"A\nB"

No. In ANSI C, "A
B" is not allowed. To get a newline in the string, use "A\nB".
so in your example:
printf("Hello World
\n");
should actually equal:
printf("Hello World\n \n");
(note two'\n's and spaces between them).
No, it should not even compile: you should get an error message reading much
like, "error: newline in constant".

As an aside:
"A
B
C"
could be easily converted to proper form by appending '\\'s:
"A\n\
B\n\
C"
(the "concatenation" is managed by the preprocessor).

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

Everybody else but me seems to know what you're talking about.
Are you saying that "\n\n\n" isn't OK?

Of _course_ it is OK. I use constructs like printf("\n\nMake lots of space");
all the time. It is the ASCII CR that cannot be embedded in a string literal.
That is, you cannot write the following line(s):

BogusStr = "This string has impossible CR in
itself";

Instead, to achieve the effect you want, you use the ANSI escape sequence and
write:
BogusNoMoreStr = "This string has possible carriage return\nin itself";

[Jason Creighton]

On Tue, 26 Oct 2004 18:44:45 +0200,
Jason Curl <j_****************************@foo.bar> wrote:

Hello,

Is it legal to have a non-quote terminated string in C?

For example:

printf("Hello World
\n");

instead of what I normally use

printf("Hello World"
"\n");

I had believed not, but some compilers seem to allow this. Just want to
be sure if this is a problem with my Compiler, or if it really is
allowed. <ot> does anyone know of compilers that allow this? </ot>

gcc 3.2.2 allows this, but gives a warning:

#include <stdio.h>

int main() {
printf("Hello world
<-- That's a newline!\n");
return 0;
}

~/prog/c$ gcc embedded-newline.c -o embedded-newline
embedded-newline.c:4:16: warning: multi-line string literals are deprecated
~/prog/c$ ./embedded-newline
Hello world
<-- That's a newline!
~/prog/c$

Jason Creighton

[pete]

Dave Vandervies wrote:

In article <41***********@mindspring.com>,
pete <pf*****@mindspring.com> wrote:

S.Tobias wrote:

Does anybody know the reason why the Standard does not allow
embedded new-lines inside string literals? I don't see how
it could break anything.

Everybody else but me seems to know what you're talking about.
Are you saying that "\n\n\n" isn't OK?

No, that would be `embedded newlines [represented by the `\n' escape]
inside strings [represented by string literals]'.

He's talking about a (unescaped) newline
(not the `\n' escape representing the newline character)
in the source representation of a string literal,
like this:
char *str="string literal with a
newline in the middle"

Thank you.

--
pete

[Dan Pop]

In <20*******************************@softhome.net.re move.to.reply> Jason Creighton <an*******@softhome.net.remove.to.reply> writes:

gcc 3.2.2 allows this, but gives a warning:

#include <stdio.h>

int main() {
printf("Hello world
<-- That's a newline!\n");
return 0;
}

~/prog/c$ gcc embedded-newline.c -o embedded-newline
embedded-newline.c:4:16: warning: multi-line string literals are deprecated

While gcc 3.3.3 is completely confused by your code:

fangorn:~/tmp 211> cat test.c
#include <stdio.h>

int main() {
printf("Hello world
<-- That's a newline!\n");
return 0;
}

fangorn:~/tmp 212> gcc test.c
test.c:4:16: missing terminating " character
test.c:5:9: missing terminating ' character
test.c:5:9: warning: character constant too long for its type
test.c: In function `main':
test.c:5: error: `That' undeclared (first use in this function)
test.c:5: error: (Each undeclared identifier is reported only once
test.c:5: error: for each function it appears in.)
test.c:5: error: parse error before '\xa22293b'

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Keith Thompson]

mw*****@newsguy.com (Michael Wojcik) writes:
[...]

Allow string literals to extend across lines.

Begin a string literal on line N. Omit the closing quote character.
Where does that literal end? At the next quote character in the
file, regardless of where it occurs.

Now, as soon as you accidentally leave off the closing quote from
a string literal, you invert what's a string literal and what's
not, for the remainder of the source file:

char *foo = "whoops; /* one string */
char *bar = "something else";

Here, if string literals were allowed to continue past the end of
the line, foo would point to a string beginning with "whoops;" and
ending with "bar = ". "something else" would not be a string
literal, and so forth.

The resulting diagnostics are likely to be ugly, and in some
circumstances quite confusing.

Perl allows multi-line string literals. If you forget to close one,
you'll get an error message on the next line that has a quotation
mark, but it will generally say something like:

Backslash found where operator expected at foo line 8, near "print "\"
(Might be a runaway multi-line "" string starting on line 5)

So *if* C allowed multi-line string literals, it would be possible to
produce reasonable diagnostics, at least in most cases.

This is not an argument in favor of allowing them, just an observation.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Matthew Johnson <me*****@onebox.com> writes:
[...]

Of _course_ it is OK. I use constructs like printf("\n\nMake lots of space");
all the time. It is the ASCII CR that cannot be embedded in a string literal.
That is, you cannot write the following line(s):

BogusStr = "This string has impossible CR in
itself";

Instead, to achieve the effect you want, you use the ANSI escape sequence and
write:
BogusNoMoreStr = "This string has possible carriage return\nin itself";

A quibble: end-of-line is not typically marked with an ASCII CR
character. Most systems use either LF or a CR-LF pair. (Using CR
would be perfectly legal, it's just uncommon; I think older MacOS
systems do this.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Matthew Johnson]

In article <ln************@nuthaus.mib.org>, Keith Thompson says...

Matthew Johnson <me*****@onebox.com> writes:
[...]

Of _course_ it is OK. I use constructs like printf("\n\nMake lots of space");
all the time. It is the ASCII CR that cannot be embedded in a string literal.
That is, you cannot write the following line(s):

BogusStr = "This string has impossible CR in
itself";

Instead, to achieve the effect you want, you use the ANSI escape sequence and
write:
BogusNoMoreStr = "This string has possible carriage return\nin itself";
A quibble: end-of-line is not typically marked with an ASCII CR
character. Most systems use either LF or a CR-LF pair. (Using CR
would be perfectly legal, it's just uncommon; I think older MacOS
systems do this.)

"Older", you say? As late as System 8 they were doing it. And I do know people
who are running System 7.

But I had forgotten about that. I was just using CR to mean 'carriage return',
which was somewhat imprecise. Neither LF nor CR nor the combination is allowed
-- nor would it be a good idea if they were allowed.

Hopefully, by now, the OP will realize the difference between embedding CR or LF
and concatenating strings.

[Jason Curl]

Matthew Johnson wrote:

In article <ln************@nuthaus.mib.org>, Keith Thompson says...

Matthew Johnson <me*****@onebox.com> writes:
[...]

Of _course_ it is OK. I use constructs like printf("\n\nMake lots of space");
all the time. It is the ASCII CR that cannot be embedded in a string literal.
That is, you cannot write the following line(s):

BogusStr = "This string has impossible CR in
itself";

Instead, to achieve the effect you want, you use the ANSI escape sequence and
write:
BogusNoMoreStr = "This string has possible carriage return\nin itself";

A quibble: end-of-line is not typically marked with an ASCII CR
character. Most systems use either LF or a CR-LF pair. (Using CR
would be perfectly legal, it's just uncommon; I think older MacOS
systems do this.)

"Older", you say? As late as System 8 they were doing it. And I do know people
who are running System 7.

But I had forgotten about that. I was just using CR to mean 'carriage return',
which was somewhat imprecise. Neither LF nor CR nor the combination is allowed
-- nor would it be a good idea if they were allowed.

Hopefully, by now, the OP will realize the difference between embedding CR or LF
and concatenating strings.

Our problem was exactly that: modifying the source using a Unix editor
or a Windows editor would result in a (nearly) non-visible change in
source that broke compatibility with an external device over a serial port.

[Dan Pop]

In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

mw*****@newsguy.com (Michael Wojcik) writes:
[...]

Allow string literals to extend across lines.

Begin a string literal on line N. Omit the closing quote character.
Where does that literal end? At the next quote character in the
file, regardless of where it occurs.

Now, as soon as you accidentally leave off the closing quote from
a string literal, you invert what's a string literal and what's
not, for the remainder of the source file:

char *foo = "whoops; /* one string */
char *bar = "something else";

Here, if string literals were allowed to continue past the end of
the line, foo would point to a string beginning with "whoops;" and
ending with "bar = ". "something else" would not be a string
literal, and so forth.

The resulting diagnostics are likely to be ugly, and in some
circumstances quite confusing.

Perl allows multi-line string literals. If you forget to close one,
you'll get an error message on the next line that has a quotation
mark, but it will generally say something like:

Backslash found where operator expected at foo line 8, near "print "\"
(Might be a runaway multi-line "" string starting on line 5)

So *if* C allowed multi-line string literals, it would be possible to
produce reasonable diagnostics, at least in most cases.

OTOH, Perl generates far better diagnostics than the average C compiler...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union