Strings in C source code

[Dave Vandervies]

S.Tobias wrote:

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

 

[Matthew Johnson]

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:

No. In ANSI C, "A
B" is not allowed. To get a newline in the string, use "A\nB".

No, it should not even compile: you should get an error message reading much
like, "error: newline in constant".

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]

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]

S.Tobias wrote:

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.

 

[Dan Pop]

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

 

[Keith Thompson]

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]

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

 

[Matthew Johnson]

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]

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

(e-mail address removed) (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