tree-wide: use DIGITS and friends
This commit is contained in:
+4
-11
@@ -33,8 +33,7 @@ int undecchar(char c) {
|
||||
}
|
||||
|
||||
char hexchar(int x) {
|
||||
static const char table[] = "0123456789abcdef";
|
||||
|
||||
const char *table = LOWERCASE_HEXDIGITS;
|
||||
return table[x & 15];
|
||||
}
|
||||
|
||||
@@ -165,9 +164,7 @@ int unhexmem_full(
|
||||
* useful when representing NSEC3 hashes, as one can then verify the
|
||||
* order of hashes directly from their representation. */
|
||||
char base32hexchar(int x) {
|
||||
static const char table[] = "0123456789"
|
||||
"ABCDEFGHIJKLMNOPQRSTUV";
|
||||
|
||||
const char *table = DIGITS "ABCDEFGHIJKLMNOPQRSTUV";
|
||||
return table[x & 31];
|
||||
}
|
||||
|
||||
@@ -516,9 +513,7 @@ int unbase32hexmem(const char *p, size_t l, bool padding, void **mem, size_t *_l
|
||||
|
||||
/* https://tools.ietf.org/html/rfc4648#section-4 */
|
||||
char base64char(int x) {
|
||||
static const char table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
|
||||
"abcdefghijklmnopqrstuvwxyz"
|
||||
"0123456789+/";
|
||||
const char *table = UPPERCASE_LETTERS LOWERCASE_LETTERS DIGITS "+/";
|
||||
return table[x & 63];
|
||||
}
|
||||
|
||||
@@ -526,9 +521,7 @@ char base64char(int x) {
|
||||
* since we don't want "/" appear in interface names (since interfaces appear in sysfs as filenames).
|
||||
* See section #5 of RFC 4648. */
|
||||
char urlsafe_base64char(int x) {
|
||||
static const char table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
|
||||
"abcdefghijklmnopqrstuvwxyz"
|
||||
"0123456789-_";
|
||||
const char *table = UPPERCASE_LETTERS LOWERCASE_LETTERS DIGITS "-_";
|
||||
return table[x & 63];
|
||||
}
|
||||
|
||||
|
||||
+9
-10
@@ -762,18 +762,17 @@ bool valid_user_group_name(const char *u, ValidUserFlags flags) {
|
||||
* don't allow slashes. */
|
||||
return false;
|
||||
|
||||
if (in_charset(u, "0123456789")) /* Don't allow fully numeric strings, they might be confused
|
||||
* with UIDs (note that this test is more broad than
|
||||
* the parse_uid() test above, as it will cover more than
|
||||
* the 32-bit range, and it will detect 65535 (which is in
|
||||
* invalid UID, even though in the unsigned 32 bit range) */
|
||||
if (in_charset(u, DIGITS)) /* Don't allow fully numeric strings, they might be confused with
|
||||
* UIDs (note that this test is more broad than the parse_uid()
|
||||
* test above, as it will cover more than the 32-bit range, and it
|
||||
* will detect 65535 (which is in invalid UID, even though in the
|
||||
* unsigned 32 bit range) */
|
||||
return false;
|
||||
|
||||
if (u[0] == '-' && in_charset(u + 1, "0123456789")) /* Don't allow negative fully numeric
|
||||
* strings either. After all some people
|
||||
* write 65535 as -1 (even though that's
|
||||
* not even true on 32-bit uid_t
|
||||
* anyway) */
|
||||
if (u[0] == '-' && in_charset(u + 1, DIGITS)) /* Don't allow negative fully numeric strings
|
||||
* either. After all some people write 65535 as
|
||||
* -1 (even though that's not even true on
|
||||
* 32-bit uid_t anyway) */
|
||||
return false;
|
||||
|
||||
if (dot_or_dot_dot(u)) /* User names typically become home directory names, and these two are
|
||||
|
||||
Reference in New Issue
Block a user