getch() returns \r instead of \n

[Mikeall]

Check the compiler option  "Define Compatibility Names", then compile and run the following code:

#include <stdio.h>

int main()
{
   char getch(void);
   char c;

   c = getchar();
   if (c == '\r')
      printf("Return\n");
   if (c == '\n')
      printf("Newline\n");

   c = getch();
   if (c == '\r')
      printf("Return\n");
   if (c == '\n')
      printf("Newline\n");
   return 0;
}

Now press the Enter key twice.  The getchar() returns '\n', but the getch() returns '\r'.
Seems like both functions should return '\n'.  ANSI K&R pg 125 shows the getch() returning a '\n', not a '\r'.

Pelles C for Windows
Version 5.00.8

RSRC0009.DLL: Version 5.00.1
SUPPORT.DLL: Version 5.00.2
POCFMT.DLL: Version 5.00.1
PORC.DLL: Version 5.00.1
POBR.DLL: Version 5.00.2
SQLITE3.DLL: Version 3.5.3
POCC.EXE: Version 5.00.13
POASM.EXE: Version 5.00.4
POLINK.EXE: Version 5.00.1
IDESPAWN.EXE: Version 5.00.1

Pelles installed on Windows XP Pro Service Pack 2


 

[aj]

In Windows a new line is produced by the character sequence "\r\n", not just "\n", this might have something to do with it?
Also getch is, as I can see it taken from conio.h, which probably is more "low-level" than getchar, which in turn might strip out the '\r' in the new line sequence.

[Mikeall]

It is my understanding that the standard requires a \n to be mapped to a single char regardless of whether the native platform uses one or two bytes for a line break.  For example, if a platform use 2 bytes 0xD 0xA for a line break, then a \n should be represented by a single byte (usually 0xA).  So when reading text, the 13 10 should be translated to \n and when writing text the \n should be translated back to 13 10.

In the code above the 2-byte line break is not being translated to \n, and the two functions are inconsistent in their handling of a line break.

[Greg]

Mikeall,

I get a link error trying to compile your code: "POLINK: error: Unresolved external symbol '_getch'." If you change getch() to _getch() it builds.

_getch() is not standard C, in K&R getch() is a function that they wrote, the code is on page 67 at the bottom.

I get the same results from getchar() and _getch() from MS Visual C/C++ 6.0 as from Pelles C.

[Mikeall]

Greg,

The reason you are getting the link error is because you didn't check the box labeled, "Define Compatibility Names", that is under the Compiler tab under Project Options.  If you don't have that option checked, then yes, you have to rename getch to _getch.

I compiled both ways, but getch and _getch both return a \r for my version and OS.  I understand that getch is not an ANSI function, but it seems to me that an ENTER key should be interpreted the same regardless of what function reads it.   However, the two functions are returning inconsistent results.

[Greg]

The reason you are getting the link error is because you didn't check the box labeled, "Define Compatibility Names", that is under the Compiler tab under Project Options.  If you don't have that option checked, then yes, you have to rename getch to _getch.

Yeah, you're right, I forgot about that option and you even mentioned it at the top of your post.    I guess it's because I never use that option.

Anyway, it looks like Pelle chose to implement it the same way as Microsoft did. I just tried your code with Borland C/C++ 5.5, same result. Pelle's C is consistent with other C compilers.