[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change ci/rlog, etc to accept '@' as part of symbol
From: |
Sam Detweiler |
Subject: |
Re: change ci/rlog, etc to accept '@' as part of symbol |
Date: |
Thu, 12 May 2005 17:23:50 -0500 |
The issue is whether my email address,
address@hidden, or address@hidden is a valid 'author' string.
I claim it is.
I agree that the '@' when preceded by a white space,
or first on a line is a treated as a comment character.
I want to allow it IN a symbol.
Here is my checkidentifier
checkidentifier(id, delimiter, dotok,AtOK)
register char *id;
int delimiter;
register int dotok;
register int AtOK;
/* Function: check whether the string starting at id is an */
/* identifier and return a pointer to the delimiter*/
/* after the identifier. White space, delim and 0 */
/* are legal delimiters. Aborts the program if not*/
/* a legal identifier. Useful for checking commands*/
/* If !delim, the only delimiter is 0. */
/* Allow '.' in identifier only if DOTOK is set. */
register char *temp;
register char c;
register char delim = delimiter;
int isid = false;
temp = id;
for (;; id++) {
switch (ctab[(unsigned char)(c = *id)]) {
case IDCHAR:
case LETTER:
case Letter:
isid = true;
continue;
case DIGIT:
continue;
case PERIOD:
if (dotok)
continue;
break;
case SBEGIN:
if(AtOK)
{
/* AT sign can be embedded, but not start */
if(isid)
{
continue;
} /* end if */
else
{
break;
} /* end else */
} /* end if */
else
{
/* fall thru into default behavior */
} /* end if */
default:
break;
}
break;
}
if ( ! isid
|| (c && (!delim || (c!=delim && c!=' ' && c!='\t' && c!='\n')))
) {
/* append \0 to end of id before error message */
while ((c = *id) && c!=' ' && c!='\t' && c!='\n' && c!=delim)
id++;
*id = '\0';
faterror("invalid %s `%s'",
dotok ? "identifier" : "symbol", temp
);
}
return id;
On Thu, 12 May 2005 16:41:50 -0400 (EDT), Aaron S. Hawley wrote:
>allowing numeric and other "special" characters as the login value of a
>revision is a common conflict for users of RCS. here's a debian gnu/linux
>bug report on the issue.
>http://bugs.debian.org/247494
>i'm sure there is similar archived discussions of this issue in other
>places. they will likely accompany reasons why the "status quo" behavior
>exists. though the status quo could be just backwards compatibility.
>if by "system" you mean some front-end to RCS, i'm sure there's some
>workaround you could do that could provide a workaround of patching RCS
>source files, making your "system" more portable (not requiring a patched
>version of RCS).
Sam