Issue information

Issue ID
#45
Status
Fixed
Severity
Critical
Started
Hercules Elf Bot
Sep 12, 2007 20:06
Last Post
Hercules Elf Bot
Sep 12, 2007 20:06
Confirmation
N/A

Hercules Elf Bot - Sep 12, 2007 20:06

Originally posted by [b]theultramage[/b]
http://www.eathena.ws/board/index.php?autocom=bugtracker&showbug=45

(Originally reported in this topic)

The '\n' char is a standardized C token meaning "newline". That is, they came up with the idea that people shouldn't need to change their code when porting to a different OS. It goes like this: you write \n in your program. The compiler writes \n (1 byte with value 10) in the output binary. Only the OS layer does the mapping from symbolic to physical newline.

now see this thing:
CODE
#if defined(WIN32) || defined(CYGWIN)
#define RETCODE   "\r\n"   // CR/LF : Windows systems
#elif defined(__APPLE__)
#define RETCODE "\r" // CR : Macintosh systems
#else
#define RETCODE "\n" // LF : Unix systems
#endif


This is the reason why windows' savefiles are terminated with CRCRLF - because RETCODE is "\r\n" and windows expands it to #13#13#10.
Actually, RETCODE should never have existed since it goes completely against C's definition.
(Truthfully, I also didn't know what the cause was until I accidentally found this topic while random-browsing. This thing is a non-trivial catch).

More details:
This thing was there since revision 1 and still is in jAthena. Key difference is that before r9435, it only (erroneously) applied to CYGWIN. After that change that 'corrected' the bad define, this is how it ended up.
One more mention of cygwin... according to info, cygwin lets you pick whether you want to go Unix-style or DOS-style during installation, therefore it supports both modes and can't be covered by a simple declaration like the above. It actually breaks cygwin's reading the same way it breaks windows'.