String issue

[No Such Luck]

I have a string that is behaving stangely:

strlen(string) = 25

printf("%s!\n", string);

#This is a comment test
!

Conclusions: There is a newline in the string, and there is also a
discrepancy between the result of strlen, and the string printed, even
including the newline.

So I scan the string, and replace '\n' with '\0'

printf("%s!\n", string);

!This is a comment test

This one really has me stumped. Any idea what that unaccounted for
character is? It's acting like hitting the "home" key. What char can I
compare against?

Thanks for any help.

 

[Zara]

I have a string that is behaving stangely:

strlen(string) = 25

printf("%s!\n", string);

#This is a comment test
!

Conclusions: There is a newline in the string, and there is also a
discrepancy between the result of strlen, and the string printed, even
including the newline.

So I scan the string, and replace '\n' with '\0'

printf("%s!\n", string);

!This is a comment test

This one really has me stumped. Any idea what that unaccounted for
character is? It's acting like hitting the "home" key. What char can I
compare against?

Thanks for any help.

Easy one.
You are working in ms_windows. So, endline is substituted with \r\n.
Thus, when you change \n to \0, you get a dangling \r: Carriage Return.
return to beginnign of line with no line advance.

It is inherited form gool old teletype machines.

You must kill both \r *and* \n

Don't let 'em trolls say this is OT, althoguh it is so.

 

[Martin Ambuhl]

I have a string that is behaving stangely:

strlen(string) = 25

printf("%s!\n", string);

#This is a comment test
!

Conclusions: There is a newline in the string, and there is also a
discrepancy between the result of strlen, and the string printed, even
including the newline.

A perfectly invalid conclusion. Can you see the whitespace at the end
of "#This is a comment test "? How many spaces are there?
How many tabs? Post real code that shows your problem. It is clear
that your description is insufficient and your diagnosis is at least
unfounded if not wrong.

So I scan the string, and replace '\n' with '\0'

That hardly gets rid of whitespace; nor does it take care of a '\r' that
might be lurking before the '\n', yielding results like:

printf("%s!\n", string);

!This is a comment test

Did you open in binary mode a file containing "\r\n" line terminators?

This one really has me stumped. Any idea what that unaccounted for
character is?
'\r'

It's acting like hitting the "home" key. What char can I
compare against?

'\r'

 

[No Such Luck]

A perfectly invalid conclusion.

Why? I counted the visible characters in the string. 23. I saw that
there was a newline. + 1 = 24. strlen reported a length of 25. 25 - 24
= 1 unaccounted for character. Regardless of whether the unaccounted
for character was a ' ', or a '\r', or whatever else, it seems my
conclusion was not only valid, but fit in line perfectly with the
eventual solution.

Can you see the whitespace at the end
of "#This is a comment test "? How many spaces are there?
How many tabs? Post real code that shows your problem. It is clear
that your description is insufficient and your diagnosis is at least
unfounded if not wrong.

Sorry you feel that way. Others who have posted in this thread do not
concur, and were able to quickly provide a correct solution based on my
discription.

Thanks.

 

[No Such Luck]

Easy one.
You are working in ms_windows. So, endline is substituted with \r\n.
Thus, when you change \n to \0, you get a dangling \r: Carriage Return.
return to beginnign of line with no line advance.

It is inherited form gool old teletype machines.

You must kill both \r *and* \n

Thanks. This was, indeed, the issue.

 

[Martin Ambuhl]

Why? I counted the visible characters in the string. 23. I saw that
there was a newline. + 1 = 24. strlen reported a length of 25. 25 - 24
= 1 unaccounted for character. Regardless of whether the unaccounted
for character was a ' ', or a '\r', or whatever else, it seems my
conclusion was not only valid, but fit in line perfectly with the
eventual solution.

There need not be any discrepancy between the result of strlen and the
string printed. There is only a discrepancy between the result of
strlen and the construction you have placed upon the string printed.
For example, there is no way for you to know what white space follows
the text you see. Indeed, your logic is invalid and wrong.

Sorry you feel that way. Others who have posted in this thread do not
concur, and were able to quickly provide a correct solution based on my
discription.

You, of course, snipped my diagnosis which is the same as the others. A
bit dishonest? You, of course, have no way of knowing that others
posting to this thread disagree with me. As usual, you have
interpretate what you choose to see as what is. Your logic continues to
be unworthy of even a child.

 

[No Such Luck]

There need not be any discrepancy between the result of strlen and the
string printed. There is only a discrepancy between the result of
strlen and the construction you have placed upon the string printed.
For example, there is no way for you to know what white space follows
the text you see.

Ok, I'll concede this point. I should have said "there is a visual
descrepancy between what I *see* printed to the screen, and the result
of strlen". Whether that descrepancy is accounted for by a trailing ' '
or a '\r', makes no difference. It's still a visual descrepancy. I saw
a string that I thought *should* have a length of 24. It had a length
of 25.

Indeed, your logic is invalid and wrong.

I still think my logic was fine. My wording was wrong.

You, of course, snipped my diagnosis which is the same as the others. A
bit dishonest?

It wasn't intentional, and I appreciate the help. I just felt I had to
address the condescending nature of your initial points.

You, of course, have no way of knowing that others
posting to this thread disagree with me.

True, although because the other poster provided a prompt and correct
solution, I'm assuming that they found my description sufficient, a
stand that would be in disagreement with yours.

As usual, you have
interpretate what you choose to see as what is. Your logic continues to
be unworthy of even a child.

No need for insults. I just find it very strange that if my description
was so "insufficient", how was it that two people were able to arrive
at the correct solution within 30 minutes of my intial inquiry.

Thanks for your help (honestly).

 

[Keith Thompson]

I have a string that is behaving stangely:

strlen(string) = 25

printf("%s!\n", string);

#This is a comment test
!

Conclusions: There is a newline in the string, and there is also a
discrepancy between the result of strlen, and the string printed, even
including the newline.

So I scan the string, and replace '\n' with '\0'

printf("%s!\n", string);

!This is a comment test

This one really has me stumped. Any idea what that unaccounted for
character is? It's acting like hitting the "home" key. What char can I
compare against?

I see you've already solved the problem, but here's some advice for
next time.

The first thing I would do in a case like this is use some tool to
examine the *actual* output of the program, rather than how it appears
on the screen. On Unix, I'd use "./program | cat -A". On Windows, I
might redirect the program's output to a file and examine the
resulting file with whatever tool is available.

Another options would be to write a function that takes a string and
prints its contents in some unambiguous form. For example:

#include <ctype.h>

void print_string(char *s)
{
int i;
for (i = 0; s != '\0'; i ++) {
if (isprint((unsigned char)s)) {
putchar(s);
}
else {
printf("<%02X>", (unsigned char)s);
}
}
putchar('\n');
}

Actually, it's not quite ambiguous, since the string might actually
contain a literal "<0D>", but it's good enough for a quick check.

A debugger is also likely to be able to show you exactly what's in the
string.

 

[Martin Ambuhl]

I still think my logic was fine. My wording was wrong.

That is one of the more inane things ever written.

 

[Mark B]

That is one of the more inane things ever written.

Although it was only a small snippet of a much larger post...
Your response however is one of the 'more inane posts ever written'.
Are you trying to incite a flame war? For what purpose?
How about making CLC a better place... let the thread die.

 

[Martin Ambuhl]

Although it was only a small snippet of a much larger post...
Your response however is one of the 'more inane posts ever written'.
Are you trying to incite a flame war? For what purpose?
How about making CLC a better place... let the thread die.

No, I am not trying to start a flame war. Mr. "No Such Luck"'s response
to my initial post might qualify for that, but I don't take part in
flame wars at all. Throughout this thread, in addition to answering his
problem without the spurious reference to "ms_windows" from Zara, I have
tried to help someone who obviously has an extremely poor grasp on logic
get a clue. If he thinks about the line that I wrote here, he might
start to understand something. If he reacts as if it were an attempt
"to incite a flame war," a response you have now encouraged, then that's
his loss.

 

[Old Wolf]

I guess this is pseudocode...

I count 25 printed characters:

1:# 2:T 3:h 4:i 5:s 6:<space> 7:i 8:s 9:<space> 10:a 11:<space>
12:c 13 14:m 15:m 16:e 17:n 18:t 19:<space> 20:t 21:e 22:s

How did you do that?

You should print out the characters in your string in some other
format, as Keith Thompson suggested.

Easy one.
You are working in ms_windows. So, endline is substituted with \r\n.
Thus, when you change \n to \0, you get a dangling \r: Carriage
Return. return to beginnign of line with no line advance.

If you actually do have "\r\n" in a string, you have probably caused
undefined behaviour earlier in the program (eg. opening a text
file in binary mode).

Any of the C input functions from a text stream (eg. using
fgets() with stdin) will represent newlines as just "\n").

 

[Jack Klein]

On 15 Sep 2005 18:02:15 -0700, "Old Wolf" <[email protected]>
wrote in comp.lang.c:

[snip]

If you actually do have "\r\n" in a string, you have probably caused
undefined behaviour earlier in the program (eg. opening a text
file in binary mode).

Questionable choice of words. Text files may be certainly be opened
in binary mode, and there is nothing undefined about it. The results
are implementation-defined or unspecified, and of course platform
specific, but nothing that rises to the level of undefined behavior.

 

[Dave Thompson]

Another options would be to write a function that takes a string and
prints its contents in some unambiguous form. For example:

#include <ctype.h>

(also need stdio.h)

void print_string(char *s)

Could better be const char *s .

{
int i;

Could better be size_t in case the string is really large -- although
in that case you might well not want to print it, or not all of it.

for (i = 0; s != '\0'; i ++) {
if (isprint((unsigned char)s)) {
putchar(s);
}
else {
printf("<%02X>", (unsigned char)s);
}
}
putchar('\n');
}

Actually, it's not quite ambiguous, since the string might actually
contain a literal "<0D>", but it's good enough for a quick check.

Can fix that by also doing '<' in the hex format (<3C> if ASCII
family), and I would also do '>' (<3E>) for symmetry. Might want to
use isgraph() and thus also hexify space, since otherwise trailing
spaces usually are visually indistinct, and substantial runs of
contiguous spaces are hard to judge visually. Or can add a flag and a
separate test to hexify only every second, or perhaps third or fourth,
contiguous space and a (last) space at end of line.

A debugger is also likely to be able to show you exactly what's in the
string.

Also true (though not covered or required by the standard).

- David.Thompson1 at worldnet.att.net