46

Background:

In versions of Mac OS up to version 9, the standard representation for text files used an ASCII CR (carriage return) character, value decimal 13, to mark the end of a line.

Mac OS 10, unlike earlier releases, is UNIX-like, and uses the ASCII LF (line feed) character, value decimal 10, to mark the end of a line.

The question is, what are the values of the character constants '\n' and '\r' in C and C++ compilers for Mac OS releases prior to OS X?

There are (at least) two possible approaches that could have been taken:

  1. Treat '\n' as the ASCII LF character, and convert it to and from CR on output to and input from text streams (similar to the conversion between LF and CR-LF on Windows systems); or
  2. Treat '\n' as the ASCII CR character, which requires no conversion on input or output.

There would be some potential problems with the second approach. One is that code that assumes '\n' is LF could fail. (Such code is inherently non-portable anyway.) The other is that there still needs to be a distinct value for '\r', and on an ASCII-based system CR is the only sensible value. And the C standard doesn't permit '\n' == '\r' (thanks to mafso for finding the citation, 5.2.2 paragraph 3), so some other value would have to be used for '\r'.

What is the output of this C program when compiled and executed under Mac OS N, for N less than 10?

#include <stdio.h>
int main(void) {
    printf("'\\n' = %d\n", '\n');
    printf("'\\r' = %d\n", '\r');
    if ('\n' == '\r') {
        printf("Hmm, this could be a problem\n");
    }
}

The question applies to both C and C++. I presume the answer would be the same for both.

The answer could also vary from one C compiler to another -- but I would hope that compiler implementers would have maintained consistency with each other.

To be clear, I am not asking what representation old releases of Mac OS used to represent end-of-line in text files. My question is specifically and only about the values of the constants '\n' and '\r' in C or C++ source code. I'm aware that printing '\n' (whatever its value is) to a text stream causes it to be converted to the system's end-of-line representation (in this case, ASCII CR); that behavior is required by the C standard.

phuclv
  • 37,963
  • 15
  • 156
  • 475
Keith Thompson
  • 254,901
  • 44
  • 429
  • 631
  • 2
    added mac-classic tag... – Grady Player Jul 31 '14 at 18:09
  • 1
    AFAIK, the values of `\n` and `\r` have always been ASCII newline and ASCII carriage return -- 0x0A and 0x0D. But I gather that early (pre-*nix) versions of MacOs used more like a DOS/Windows line terminator -- `\r\n` in sequence. – Hot Licks Jul 31 '14 at 18:10
  • @GradyPlayer: Thanks. Deleted osx tag (automatically changed from "macos", which is what I typed). – Keith Thompson Jul 31 '14 at 18:10
  • 1
    I can't provide the exact output, but I am pretty sure old macs (and some other oses) used carriage returns (\r) to create a new line: https://en.wikipedia.org/wiki/Newline – dohashi Jul 31 '14 at 18:10
  • @HotLicks: No, I'm fairly sure that old Mac OS used just `\r`, not `\r\n`, to mark end-of-line in files. But my question is about the constants *in C or C++ code*. – Keith Thompson Jul 31 '14 at 18:10
  • if you are using ascii, then the codes will be the same, as for the appropriate line endings it changes a lot depending on context... there are possible scenarios where "\n", "\r" or "\r\n" could be appropriate. – Grady Player Jul 31 '14 at 18:11
  • The constants have not changed, since they are mnemonically tied to the ASCII character names. (Though of course there may have been, somewhere in history, a bastardized C compiler that mapped them differently.) – Hot Licks Jul 31 '14 at 18:11
  • of course if you were using a different character encoding it would be different... UTF-8 or MacRoman are the same, as they keep the core of ASCII as the same – Grady Player Jul 31 '14 at 18:12
  • 1
    @HotLicks: `'\n'` is tied to the term "newline", which does not appear in ASCII. UNIX has a convention of using LF (line feed) to mark the end of a line. – Keith Thompson Jul 31 '14 at 18:12
  • Are you sure your test program covers your question entirely? What if `printf("bla\n");` actually prints a carriage return, but `printf("%d\n", '\n');` don't give the ASCII value of the carriage return? – ouah Jul 31 '14 at 18:15
  • 1
    Well, there isn't a `\l` because you couldn't tell it from `\1` -- `\n` was used instead, and the "newline" moniker was hung on it. – Hot Licks Jul 31 '14 at 18:16
  • 9
    Booting up my old iMac now... I'll have an answer soon. (Mac OS 8.6) – Mankarse Jul 31 '14 at 18:19
  • @ouah: Yes, the test program covers the question I'm actually asking. I'm aware that `printf("bla\n")` will print an ASCII CR character, because that's what the OS uses to mark end-of-line in text files. – Keith Thompson Jul 31 '14 at 18:19
  • @HotLicks: That's an interesting explanation. Can you cite a source for it? – Keith Thompson Jul 31 '14 at 18:19
  • Understand that the whole concept is tied to the Teletype and its kin. The carriage-return caused the print head to fly back to the left margin, and the line-feed caused the platen to advance the paper one line. These were physical operations that didn't care what software was being used. *nix systems, when you routed output to a TTY, would scan the outgoing stream and insert line-feed after each carriage-return. Most other systems expected the user to supply both characters. – Hot Licks Jul 31 '14 at 18:22
  • 3
    Classic Mac used `\r` as the line separator in text files. Since the C I/O library is responsible for transforming between filesystem and in-memory representation, I'd guess `\n`s were serialized as `\r`. – The Paramagnetic Croissant Jul 31 '14 at 18:23
  • @KeithThompson - I read it somewhere once. – Hot Licks Jul 31 '14 at 18:23
  • 3
    To address how standard conforming `'\n'` = `'\r'` would be: Seems unchanged since C89… C11 5.2.2 p3: “Each of these escape sequences shall produce a unique implementation-defined value […]”. So, no, it's not conforming. But what about a character set using 0xd for `'\n'` and 0xa for `'\r'`? – mafso Jul 31 '14 at 18:23
  • I'm vaguely recalling that, when they built the first Apple machines, Jobs and Wozniak got the CR/LF thing backwards in their CRT-based TTY substitute, and had to fudge it in the software. I suppose this confusion could have been carried forward into the early Macs, but it became untenable when "portable" C programs started being passed around. – Hot Licks Jul 31 '14 at 18:37
  • 3
    @HotLicks The way I remember it, old macs used `'\r'` precisely in the same way as UNIX systems use `'\n'`. There was never a DOS-like combination in use. Microsoft users always annoyed us with that extra character - the mac users with the line-feed, the unix users with the carriage-return... – cmaster - reinstate monica Jul 31 '14 at 19:01
  • The thing that is being ignored by some is that the `printf` and `scanf` family functions didn't just send and `\n` and `\r` that occurred in their first argument (as opposed to converted arguments) on unmodified. So that when I wrote K&R style utilities they produced files that worked on the machine they were run on and needed translation to work properly on a unix or dos machine. And as @ouah you can't test that with a numeric comparison of the values of the character literals or by printing the results after a `%d` conversion. – dmckee --- ex-moderator kitten Jul 31 '14 at 21:46
  • @dmckee: `printf` and `scanf` work as if they repeatedly called `fputc` or `fgetc` respectively. `The following are all equivalent: `printf("\n")`, `printf("%s", "\n")`, `printf("%c", '\n')` and `fputc('\n', stdout)`. Conversion of `'\n'` (whatever it is) to and from the system's end-of-line marker happens for I/O to any text stream. That conversion is not what I'm asking about. I am specifically asking about the values of `'\n'` and `'\r'` -- and `printf("%d\n", '\n')` *does* answer that question. – Keith Thompson Jul 31 '14 at 22:00
  • The compiler's representation of the constant `'\n'` and the runtime library's decision of which character to translate to an end-of-line representation do have to agree for the implementation to be conforming. (For UNIX-like systems that's trivial, since `'\n'` is `10`, i.e. LF, which *is* the system's end-of-line representation). – Keith Thompson Jul 31 '14 at 22:01
  • Fair enough. There just seems to be a lot of noise in the comments from people who apparently never had to deal with the way these systems worked on the ground. – dmckee --- ex-moderator kitten Jul 31 '14 at 22:02
  • @mafso I don't think you are right. `\n` is **still** unique and **different** from memory than `\r`. It's just that the classic Mac C I/O library is responsible for translating between `\r` and `\n` *when writing to or reading from a file.* – The Paramagnetic Croissant Aug 01 '14 at 11:19
  • @mafso ah OK, sorry then. – The Paramagnetic Croissant Aug 01 '14 at 11:30
  • On early teletypes, a carriage return issued near the right margin would have to be followed by a non-printable character in order to ensure that the print head could reach the left edge of the paper before the next printable character arrived (there was *zero* buffering). Requiring newlines to be punched on tape as a CR/LF sequence didn't add any real overhead. In cases where carriage-return speed wasn't an issue, many printers offered an option to advance the paper when given a CR alone; some others offered an option to perform a carriage return when given an LF alone. – supercat Apr 29 '15 at 21:20
  • What would have been ideal would have been to have separate codes for CR only, LF only, and CR+LF. Having CR and LF both have one bit that was set, and having the CR+LF code set both bits, would have been no more complicated than what was actually done (if anything it would have been a few transistors cheaper), but a newline would still have had to be two characters (a CR+LF character and a NUL) so there would have been no advantage until buffered printers came along. – supercat Apr 29 '15 at 21:24
  • @cmaster: The "DOS-like combination" predates DOS by well over a decade, going back to the ASR-33 teletype (1963). I think the discrepancy over which character should be considered the "newline" probably stems from the fact that on many terminals, a line LF would move the cursor to the left side of the next line, but a CR was easier to type. Thus, if one copies stdin to a file and then outputs the file to the console, something will have to translate the typed CR into an LF. Macintosh stores the file *as typed*, while Unix stores it *as it should be output*. – supercat Apr 29 '15 at 21:50

5 Answers5

45

The values of the character constants \r and \n was the exact same in Classic Mac OS environments as it was everywhere else: \r was CR was ASCII 13 (0x0d); \n was LF was ASCII 10 (0x0a). The only thing that was different on Classic Mac OS was that \r was used as the "standard" line ending in text editors, just like \n is used on UNIX systems, or \r\n on DOS and Windows systems.

Here's a screenshot of a simple test program running in Metrowerks CodeWarrior on Mac OS 9, for instance:

Example program running in CodeWarrior

Keep in mind that Classic Mac OS systems didn't have a system-wide standard C library! Functions like printf() were only present as part of compiler-specific libraries like SIOUX for CodeWarrior, which implemented C standard I/O by writing output to a window with a text field in it. As such, some implementations of standard file I/O may have performed some automatic translation between \r and \n, which may be what you're thinking of. (Many Windows systems do similar things for \r\n if you don't pass the "b" flag to fopen(), for instance.) There was certainly nothing like that in the Mac OS Toolbox, though.

  • Do you have a reference for this? BTW, any conforming hosted C implementation must include the full standard library, including `printf`; such an implementation needn't be provided by the OS. – Keith Thompson Jul 31 '14 at 19:12
  • 1
    Does the mean `stdout` (in text mode) emitted 13 on both `fputc('\n')` [translated due to text mode] and `fputc('\r')`? – chux - Reinstate Monica Jul 31 '14 at 19:14
  • @chux Talking about what character is "emitted" is a little messy here because classic Mac OS didn't have true file descriptors — some standard I/O implementations display output in graphical form only! Even when I/O went to a text editor, there's no guarantee those would preserve control characters. –  Jul 31 '14 at 19:22
  • It might be useful to try to find classic-mac ports of unix tools for accessing portable binary and text files and see what the code did. – Chris Stratton Jul 31 '14 at 19:31
  • 1
    @duskwuff: But stdio can open files (`fopen`) and which bytes are written there is clearly testable. – R.. GitHub STOP HELPING ICE Jul 31 '14 at 20:10
  • @R.. If you can give me an example of what you want to test, I can see about running that later. The machine I've got is pretty unstable, though, and getting even this test to run (and getting the screenshot back off the machine) was kind of a pain, so I'd rather not dink around too much. –  Jul 31 '14 at 20:22
  • @duskwuff: I think determining how text file translations occur is explicitly outside the scope of the question. The question is about the actual value of `'\n'` which you established well. I already upvoted your answer and I think it should be the accepted answer. – R.. GitHub STOP HELPING ICE Jul 31 '14 at 20:24
  • One thing to remember in the old days was that basically you didn't have a shell (unless you were using the one that came with code warrior, which was just a program that wired a text view control to their std lib io) and you didn't ever use printf, you almost always dealt with things like writing to a file with some Mac Toolbox call that used Pascal Strings anyway... I am so glad that you are still able to run CodeWarrior! – Grady Player Jul 31 '14 at 20:34
  • Having never been a Mac programmer, I still have questions. How many compilers were available for the Mac? Were they all the same in their interpretation of `\r` and `\n`? Which compiler was considered standard? – Mark Ransom Jul 31 '14 at 21:28
  • @MarkRansom There were several compiler available. Turbo C from Borland, MPW C and CodeWarrior were the common ones. There were others including a couple of gcc ports (a 1.37 with it own goofy IDE, and a early version 2 that I never had the kit to run) The ones that could be run under MPW all did the same thing. – dmckee --- ex-moderator kitten Jul 31 '14 at 21:40
  • 2
    This answer is correct. There was also, however, a variation of the standard library available that interpreted files opened in text mode. That is, if the file contained a \r (13) you'd get a \n (10) when you read it in text mode. On output, you'd write a \r (13) and it would actually be written to disk as a \n (10). – Steven Fisher Jul 31 '14 at 23:46
  • are there no terminal in classic Mac OS? – phuclv Aug 01 '14 at 04:30
  • @LưuVĩnhPhúc None whatsoever! It is a *very* different environment from what you're probably familiar with. –  Aug 01 '14 at 04:43
  • What a strange OS! Even Windows have a place for you to type commands – phuclv Aug 01 '14 at 05:39
  • 2
    @LưuVĩnhPhúc: well there was Apple's [MPW](http://en.m.wikipedia.org/wiki/Macintosh_Programmer's_Workshop) which was a wonderful environment for developers - you could use it like a shell (or terminal), but every "session" was also an editable text document - I miss it. – Paul R Aug 01 '14 at 05:43
5

I've done a search and found this page with an old discussion where especially the following can be found:

The Metrowerks MacOS implementation goes a step further by reversing the significance of CR and LF with regard to the '\r' and '\n' escapes in i/o involving a file, but not in any other context. This means that if you open a FILE or fstream in text mode, every '\r' will be output there as an LF as well as every '\n' being output as CR, and the same is true of input - the escape-to-ASCII-binary correspondences are reversed. They are not reversed however in memory, e.g. with sprintf() to a buffer or with a std::stringstream. I find this confusing and, if not non-standard, at least worse than other implementations.

It turns out there is a workaround with MSL - if you open the file in binary mode then '\n' always == LF and '\r' always == CR. This is what I wanted but in getting this information I also got a lot of justification from folks over there that this was the "standard" way to get what I wanted, when I feel like this is more like a workaround for a bug in their implementation. After all, CR and LF are 7-bit ASCII values and I'd expect to be able to use them in a standard way with a file opened in text mode.

(An answer makes clear that this is indeed not a violation of the standard.)

So obviously there was at least one implementation which used \n and \r with the usual ASCII values, but translated them in (non-binary) file output (by just exchanging them).

Community
  • 1
  • 1
celtschk
  • 19,311
  • 3
  • 39
  • 64
  • Assuming that `'\n'` == 10 (ASCII LF), writing `'\n'` to a text stream would *have* to translate it to CR, since that's the system's end-of-line marker. Additionally translating `'\r'` to LF makes some sense, I suppose, and opening a file in binary mode would inhibit the translation. (This is all standard C stuff). So under Metroworks, the output of the program in my question would be `'\n' = 10` `\r = 13`. As far as my question is concerned, that's consistent with duskwuff's answer. – Keith Thompson Jul 31 '14 at 22:28
  • @KeithThompson The compiler I used to illustrate my answer *was* Metrowerks CodeWarrior! –  Jul 31 '14 at 22:59
2

On older Mac compilers, the roles of \r and \n where reversed: We had '\n' == 13 and '\r' == 10, while today '\n' == 10 and '\r' == 13. Great fun during the transition phase. Write a '\n' to a file with an old compiler, read the file with a new compiler, and get a '\r' (of course, both times you actually had a number 13).

gnasher729
  • 51,477
  • 5
  • 75
  • 98
  • I don't think this answers OP's question. OP is not asking about text file translations but the actual value of the expression `'\n'`. – R.. GitHub STOP HELPING ICE Jul 31 '14 at 18:30
  • but this was done by convention I presume right? to allow for code compatibility rather than C language adherence? I checked MacRoman, and /n(lf) is still 0xa and \r(cr) is still 0xd – Grady Player Jul 31 '14 at 18:30
  • 6
    I think you have that backwards; `'\n' == 10` and `'\r' == 13` would be the modern version. – Keith Thompson Jul 31 '14 at 18:31
  • 2
    The problem of reading and writing to the file would also occur, if I/O functions did the conversions (as in Windows with `\n` to `\r\n`). Just to be sure: Does `'\n' == 13` evaluate to 1 on such a system? – mafso Jul 31 '14 at 18:35
  • Can you tell when that switch happened? Because I don't remember `'\n'` being anything other than the line feed character back then, but that might have to do with the time I started programming on the mac. – cmaster - reinstate monica Jul 31 '14 at 18:50
  • @R..: Apart from the apparent reversal I mentioned in my previous comment, this does seem to answer the question I asked; it specifically says `'\n' == 13'`. (The last part of the answer is about text file translations, which isn't what I asked about.) Waiting for clarification from gnasher729. – Keith Thompson Jul 31 '14 at 19:00
  • 3
    This is not true. `\r` is always CR is ASCII 13; `\n` is always LF is ASCII 10. Classic Mac OS just used `\r` as the standard line ending instead of `\n`, just like DOS/Windows use the `\r\n` sequence. –  Jul 31 '14 at 19:01
  • (Where by "is always", of course I only mean that to apply to the common ASCII systems: UNIX, classic and modern Mac OS, and Windows. EBCDIC systems and so on are a completely different matter!) –  Jul 31 '14 at 19:10
  • 1
    @duskwuff: But we have an assertion that under Classic Mac OS, `'\n' == 13`. I think we need to see the actual output of the program in my question to settle this. – Keith Thompson Jul 31 '14 at 19:14
  • 1
    @KeithThompson I'll boot up my old Mac in a few minutes and get a screenshot. :) –  Jul 31 '14 at 19:17
  • 1
    @duskwuff When you experiment, note that text mode IO operations do conversions. So try saving `"foo\n"` to files opened in both text and binary modes and see what bytes get actually written. – hyde Jul 31 '14 at 19:52
  • @KeithThompson After endless wrestling with old computers and old file formats… added a screenshot to my answer! –  Jul 31 '14 at 19:56
  • 3
    @duskwuff has provided screenshots indicating that `'\n' == 10` and `'\r == 13`; presumably `'\n'` would be translated to CR on output. Your answer seems to imply that the values of the `'\n'` and `'\r'` literals were reversed, which would be inconsistent with the evidence of the screenshots. Could it be that different C compiles behaved differently? – Keith Thompson Jul 31 '14 at 20:00
  • @KeithThompson I can't rule that out, as I can't remember how to build an executable under MPW, and I don't have any other compilers available. :) As far as I'm aware, though, Codewarrior was not unusual in this respect, though. –  Jul 31 '14 at 20:03
  • Fixed the numbers; sorry about that. – gnasher729 Jul 31 '14 at 21:02
  • The CodeWarrior C compiler switched when they started producing MacOS X code. Actually, the same compiler could produce code for pre-MacOS X and for MacOS X, and '\n' would be translated differently. – gnasher729 Jul 31 '14 at 21:10
  • @gnasher729: What exactly do you mean by "'\n' would be translated differently"? There are two translations occurring: the compile-time translation of the constant `'\n'` in source code, and the run-time translation of that value to the system's end-of-line marker on output (and vice versa on input). The first is the only thing I'm asking about. Do you assert that the output of the program in my question under CodeWarrior would be `'\n' = 13` `'\r' = 10`? If so, then CodeWarrior behaved quite differently from what we see in duskwuff's screenshot (and I think he used CodeWarrior). – Keith Thompson Jul 31 '14 at 22:31
  • @KeithThompson Yes, that's what I used. (Added a bit to my answer to make that clear.) –  Jul 31 '14 at 23:39
1

C-language specification:

5.2.2
...
2 Alphabetic escape sequences representing nongraphic characters in the execution character set are intended to produce actions on display devices as follows:
...
\n (new line) Moves the active position to the initial position of the next line.
\r (carriage return) Moves the active position to the initial position of the current line.

so \n represents the appropriate char in that character encoding... in ASCII is the LF char

Grady Player
  • 14,399
  • 2
  • 48
  • 76
  • 7
    I don't believe this answers the question. That section also describes the *intended* behavior of `\f` and `\v`; few systems actually behave as described. – Keith Thompson Jul 31 '14 at 18:23
  • @KeithThompson I am looking for a document that supports a swap of char values... by the compilers... I believe that they worked this way, I have some old Classic programs that seem to enforce this idea, but I can't run them right now. – Grady Player Jul 31 '14 at 18:32
  • @GradyPlayer: if you have some executable files from that period you could examine your strings with a hex viewer. I'm pretty sure a modern one won't silently translate `\r` back to `\n` again ;-) – Jongware Jul 31 '14 at 19:56
  • I think this does answer the question... We didn't really run portable C programs on the Mac, they were originally written in Pascal and then later C/C++, but we didn't even have a console... so the concept of a newline was basically just in the native controls and in text files, and I remember every mac program reading \n, \r, and \r\n as a newline... where would printf even print? – Grady Player Jul 31 '14 at 21:05
  • @GradyPlayer: The question was about the actual values of the `'\n'` and `'\r'` character constants, not about how I/O behaves. duskwuff has been able to compile and run the portable C program from my question and produce a screenshot. – Keith Thompson Jul 31 '14 at 22:19
  • @KeithThompson That is in SIOUX, which is actually how I learned C, but I think the invariant holds \n == lf... if you output to a file "hello\nthere\rworld\r\n..." it would depend on what application opened the file on how it was interpreted, but it would be 4 lines if you opened it in BBEdit... – Grady Player Jul 31 '14 at 22:24
1

I don't have an old Mac compiler to check if they follow this, but the numeric value of '\n' should be the same as the ASCII new line character (given that those compilers used ASCII compatible encoding as the execution encoding, which I believe they did). '\r' should have the same numeric value as the ASCII carriage return.

The library or OS functions that handle writing text mode files is responsible for converting the numeric value of '\n' to whatever the OS uses to terminate lines. The numeric values of these characters at runtime are determined entirely by the execution character set.

Thus, since we're still ASCII compatible execution encodings the numeric values should be the same as with classic Mac compilers.

bames53
  • 86,085
  • 15
  • 179
  • 244
  • 1
    ASCII does not imply that the LF character is a "newline" character; in fact ASCII has no newline character. A conforming C implementation for old Mac OS could have `'\n' == 13 && '\r' == 10` (with no conversion needed on input or output) *or* it could have `'\n' == 10 && '\r' == 13` (and convert LF to CR on text output and CR to LF on text input. The C and ASCII standards by themselves do not answer my question, which is about which of the two (or more) valid choices was made by the authors of C and C++ compilers for classic Mac OS. – Keith Thompson Jul 31 '14 at 18:43
  • That would be a conforming implementation, but it would mean the encoding wasn't ascii. The ascii character doesn't need to be named 'newline' to mean the same thing. The question boils down entirely to 'what is the execution encoding used by classic Mac computers.' – bames53 Jul 31 '14 at 18:47
  • 2
    How so? What in the ASCII standard implies that LF is the correct character to use for newline? – Keith Thompson Jul 31 '14 at 18:49
  • Well, I'm sure I could find a rational, but I can't find a copy of ANSI Document X3.4-1986 (R1997). 'line feed' certainly causes printing on the current line to end. – bames53 Jul 31 '14 at 19:23
  • And how closely do existing C implementations follow the ASCII standard? Printing a formfeed or vertical tab to a terminal (say, an xterm window) typically does nothing, for example. I don't think we an use the requirements of the ASCII standard to infer how C compilers implement the `'\n'` character constant. – Keith Thompson Jul 31 '14 at 19:26
  • Obviously what an ascii control character actually does is up to the mechanism that's reading it, but in my experience console programs do implement most of the ascii control characters and C implementations do map the escapes to the sensible character. \a causes a sound to play (or the screen to flash if the console program is configured that way), \b does move the cursor back one character, \f clears the screen, \r does start printing from the beginning of the line without also moving down to a new line, \v moves down several lines, \t does produce a horizontal tab. – bames53 Jul 31 '14 at 20:13
  • It might depend on what sort of device your program is emulating, VT100 or whatever. – bames53 Jul 31 '14 at 20:16
  • I'm not sure I've ever seen a terminal emulator clear the screen on `\f`. I've just tried xterm, Gnome terminal, lxterm, xfce4-terminal, and PuTTY; none of them behave that way. – Keith Thompson Jul 31 '14 at 20:25
  • @KeithThompson I'm getting that behavior on PuTTY now. – bames53 Jul 31 '14 at 20:27
  • Correction: I haven't been able to try PuTTY. By "that behavior" do you mean that the scree is cleared? – Keith Thompson Jul 31 '14 at 20:35
  • Yeah. Well, scrolled down to where the next printed line appears at the top of the window. – bames53 Jul 31 '14 at 20:36
  • There are different areas: First, the compiler must decide what the value of '\n' and '\r' is. That value has changed from pre-MacOS X to MacOS X compilers. Next, when printing '\n' as a char to a text file (not a binary file), printf must replace that char value with the OS-dependent correct character(s). What the correct characters for a line separator are has also changed from MacOS to MacOS X. But third, if you want to write a utility today that translates Windows-style text files (con'd) – gnasher729 Jul 31 '14 at 21:16
  • to MacOS 9 style text files, then you really can't rely on what printf does, and what the compiler says '\n' is; you just have to know that Windows typically used two specific chars and MacOS 9 used another char. – gnasher729 Jul 31 '14 at 21:20
  • @gnasher729: Your first point, the values of `'\n'` and `'\r'`, is the only thing I'm actually asking about, and the screenshot in [duskwuff's answer](http://stackoverflow.com/a/25067011/827263) indicates that those values *have not* changed from pre-MacOS X to MacOS X compilers. I'd be very interested in seeing evidence, preferably in the form of copy-and-pasted or screen-captured output of the program in my question, that indicates otherwise (which would imply that different pre-MacOS X compilers behaved differently). – Keith Thompson Jul 31 '14 at 22:16
  • ASCII code 10 is "linefeed". Traditionally, it would advance paper without resetting the carriage position, or on display terminals it would move the cursor to the next line without resetting it to the left edge. While some terminals had an option to automatically advance paper upon receipt of a carriage return, someone (perhaps Digital Equipment Corporation) came up with the brilliant observation that resetting the carriage without advancing paper was useful more often than advancing paper without resetting the carriage, and thus implemented LF as a double-duty code. – supercat Jul 31 '14 at 22:55