One of the
recurring issues of ASCII is:
"What is the ASCII code for newline?"
0x0a, one of whose names is NL. This is well-defined.
Is a new line CR (carriage return)? LF
(linefeed)? CR LF? LF CR?
This is not a question about ASCII; it is a question about how some
unspecified system represents linebreaks - about how that system uses
ASCII, perhaps.
Worse, on many systems the answer differs depending what point you
measure at. On most Unix variants, for example, it's 0x0a when
measured in files or in C strings, but 0x0d 0x0a when measured on
hardware serial lines.
Is '\n' 0Dh? 0Ah? 0Dh 0Ah? 0Ah 0Dh?
It's only one character; that much is well-specified (well, assuming
your '\n' was supposed to be C). What the numerical value of that
character is is not well-defined without reference to a particular
system (though 0x0a is by far the commonest, probably because it's
ASCII NL).
If you run the following bit of C code under MS-DOS (or Windows):
#include <stdio.h>
#include <stdlib.h>
int main(int argc,char *argv[])
{
FILE *fp;
int c;
if (argv == 1)
fp = stdin;
else
fp = fopen(argv[1],"r");
if (fp == NULL)
{
perror(argv[1]);
return(EXIT_FAILURE);
}
while((c = getc(fp)) != EOF)
{
if (c == '\n')
printf("new line\n");
else if (c == 0x0D)
printf("carriage return\n");
}
return(EXIT_SUCCESS);
}
All you will see is repetition of "new line"----you won't see any
"carriage
return" at all. That's because the Standard C Library is sucking up the
carriage returns. Upon printing a '\n', the Standard C Library is silently
adding carriage returns. Change the "r" in the fopen() call to "rb"
and
then you'll start seeing carriage returns.
-spc (Gah! Why do I remember this horrible MS-DOS crap?)