Bug: Line editor input not consistent with file I/O behaviour
Danger: Medium - Will break any mudprog entered via OLC before the mud reboots.
Found by: Stan
Fixed by: Samson
mudstrlcat( tmp, "\r\n", 100 );
mudstrlcat( tmp, "\n", 100 );
Replace the same line in copy_buffer_nohash.
If you have not yet applied the mudstrlcpy/cat functions, then look for:
strcat( tmp, "\r\n" );
And change it to:
strcat( tmp, "\n" );
If you have not yet done the telnet protocol fix where \n\r is replaced with \r\n, you won't be affected by the bug but should probably still fix it anyway.
This is one of those stupid things that even after looking at it and banging heads against walls still fails to make alot of sense, but nonetheless, having the line editor only use \n (LF) to signify a newline seems to be the proper solution to this. Since mudprogs are saved to disk with \r (CR) stripped the behaviour of the line editor now properly follows the same standard used by the file I/O systems. And it can never hurt anything to use consistent behaviour, right? We've just seen what happens when you don't!