On Wed, 12 Nov 1997, George wrote:
> You all may be relieved to know that I have determined the cause of the
> ^M's which pop up in world files.
>
> They are caused by a small bug in fread_string() right by this comment:
> /* If there is a '~', end the string; else put an "\r\n" over the '\n'. */
That's not really a bug in fread_string. On a unix system, it's necessary
to add the \r to have multiline text from db files comply with the telnet
rfc. It may cause problems with windows or macs, since they use different
text file arrangements.
> It appears that when it overwrites the \n with a \r\n, there was already a
> \r there to begin with!
Only when an olc addition saves a multiline description, so stock circle
won't ever do this.
> That is not a patch. :) I've only tested it by booting, setting a
> breakpoint in copy_room, and then copying the room description.
I'm using a set of file-buffering functions now that read an entire file
into memory so it can be parsed more quickly. That gives me plenty of
spare cpu time to check the end of lines and make sure each one is \r\n
terminated, regardless of operating system.
I haven't profiled the difference, but I'd guess I'm pretty close to
binary file speed (the only difference is the necesary parsing from the
file buffer to the appropriate data structures).
> Maybe in bpl13 we can throw away all those string strippers. :)
Using your patch or my extra checks, you'll still get ^M's in your files
on a unix system every time you save, tho they won't stack up.
Sam
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST