MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

Re: Server Patch - chr() and asc() functions - Ian



On Wed, 17 May 1995, Alex Stewart wrote:

> > STR chr(NUM)
> > This will return a string (length(string) = 1) that contains the 
> > character represented by the code NUM.
> 
> This is generally a bad idea without proper limitations.  For example, if you
> happen to do a chr(10) and stick it in a prop, your checkpoint and dump files
> will end up corrupted foreverafter (or at least as long as that value stays in
> the DB).
> 
> A _much_ better way to deal with making non-cooked codes available for the DB
> to use actually involves no server modifications at all (I posted it here some
> time ago).  The method is as follows:
> 
> 1.  Create a prop on an object, and give it an easy to identify and (hopefully)
> unique string value ("***!!!UniqueStringThatNobodyElseIsLikelyToUse!!!***" or
> some such).

I did use the other method you prescribe, but after editing the database 
and putting a #0.ESC ($ESC) property, I needed the IAC GA (\377 \371) 
characters for prompting. 

I just considered the 'editing' method to be more crude, and then thought 
that I *might* find a use for asc() anyway, so I put it in.

However, the point you bring up is definately valid.  chr(10) and chr(13) 
should also return E_INVARG.  I'll patch my code to do that, and if I 
don't get shot down in flames totally in the next few messages, will post 
the updated chr() function :)

Thanks for the comments.

Regards,

Ian.

+--------------------------------------------------------------------+
| Ian Macintosh         | P.O. Box 24-036 | Anything really worth    |
| General Manager       | Royal Oak       | doing, is worth doing    |
| Sytek New Zealand Ltd | Auckland 1      | badly.     - Duncan Shaw |
+--------------------------------------------------------------------+
References:
Home | Subject Index | Thread Index