10 Jun, 2009, Kaene wrote in the 1st comment:
Votes: 0
I was just wondering if the leading space stripping inside of one_argument was there for some security reason, or just a matter of convenience, or maybe something else entirely I don't see?

I ask because there are things I would like to allow leading spaces (titles, pretitles, other custom messages, etc), but I don't want to open myself up to some problem that it is fixing.

I don't think that's the case, it seems to be just a guard against people hitting space more than once and screwing their commands up… but then again I am still very new to the coding.

Thanks for any info, and apologies for the n00bity. :D


For reference:
/*
* Pick off one argument from a string and return the rest.
* Understands quotes.
*/
char *one_argument (char *argument, char *arg_first)
{
char cEnd;

while (isspace (*argument))
argument++;

cEnd = ' ';
if (*argument == '\'' || *argument == '"')
cEnd = *argument++;

while (*argument != '\0')
{
if (*argument == cEnd)
{
argument++;
break;
}
*arg_first = LOWER (*argument);
arg_first++;
argument++;
}
*arg_first = '\0';

while (isspace (*argument))
argument++;

return argument;
}
10 Jun, 2009, Runter wrote in the 2nd comment:
Votes: 0
It's just the way the author intended the function to work. To grab the first argument, ignoring any leading space. There's no other purpose for security, etc. (But that doesn't mean changing it won't make legacy uses of it fail for some purposes.)
10 Jun, 2009, David Haley wrote in the 3rd comment:
Votes: 0
You generally don't want it to make a difference if I type:
look_guard
or
look__guard
(where _ means space)
because the latter would try to look up a creature called " guard", and the guard's name is, well, "guard", not " guard".
Generally speaking, whitespace is not considered to be significant, so it's discarded.

Since the common use case is to ignore spaces, it might make sense to have your particular functions that need whitespace to use a different routine.

Another option would be to enclose them in quotes or something like that, and have the argument parsing functions respect quotes.
10 Jun, 2009, Scandum wrote in the 4th comment:
Votes: 0
Allowing color codes in titles is one way to work around the spacing issue, in ROM you can generally use: title {w the white space cowboy!
10 Jun, 2009, David Haley wrote in the 5th comment:
Votes: 0
I think it's generally discouraged to use "white" to mean "lack of color" because it's not a given that people use white as the default color code.
10 Jun, 2009, Scandum wrote in the 6th comment:
Votes: 0
That's why you don't use the default foreground color codes and instead decide yourself what you use as the default foreground color.
10 Jun, 2009, David Haley wrote in the 7th comment:
Votes: 0
So the client has to fix problems caused by the server… nice. :wink:
I'm not sure what you could mean otherwise: if the server is sending "white", thinking it's saying "default", and my default is blue, how else could this possibly work?


EDIT:
Regardless I think it's pretty obvious that this is a hacky solution to what is an easily fixable server-side problem.
10 Jun, 2009, Scandum wrote in the 8th comment:
Votes: 0
I have no idea what you're talking about. I'm saying not to use \eI have no idea what you're talking about. I'm saying not to use \e[0m as a foreground color and instead to use \e[0-1;31-37m. As far as I know {w sends \e[0;37m on most rom muds.
10 Jun, 2009, David Haley wrote in the 9th comment:
Votes: 0
I'm saying that you shouldn't send the code for "white" unless you actually mean "white". In particular one should not send "white" to mean "default": one should not assume that the client uses white as its default color.
11 Jun, 2009, ATT_Turan wrote in the 10th comment:
Votes: 0
I think that Scandum was saying the player would insert {w at the beginning of their title in order to have the spaces after it recognized - he wasn't recommending that Kaene insert it into the user's argument within do_who. In that case, the player would certainly intend the text to be white, as he is the white space cowboy :grinning:
11 Jun, 2009, David Haley wrote in the 11th comment:
Votes: 0
Well, sure, but then the only way to have a title with spaces is to use a color. It's debatable whether or not the MUD wants people to have free-form colors in their titles, too, incidentally.
11 Jun, 2009, ATT_Turan wrote in the 12th comment:
Votes: 0
It is debatable, but not by me :grinning: I was just attempting to clear up what seemed to be a point of misunderstanding between you folks. Personally, the only thing I care about in titles is stripping out any line returns.
11 Jun, 2009, David Haley wrote in the 13th comment:
Votes: 0
Well, titles aside, you have the exact same problem for any piece of text (which might be sent in some other color to begin with, or intentionally without color) for which you want leading whitespace, so the color solution just really isn't appropriate in general. I'm not sure that point is really debatable, frankly…

It's easy enough to fix the parsing functions to understand quotation marks (in some bases, they already do), or to make new ones that treat whitespace as significant. You would then use those in functions where you cared about the extra whitespace.
0.0/13