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]

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]

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]

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]

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!

 

[Flash Gordon]

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.

 

[S.Tobias]

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.

 

[Robert Harris]

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

S.Tobias wrote:

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.

 

[Dave Vandervies]

[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

 

[Flash Gordon]

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

 

[Dan Pop]

[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

 

[Keith Thompson]

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.

 

[Dan Pop]

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

 

[Michael Wojcik]

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

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]

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

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]

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;\
}\

 

[pete]

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?