2018-12-16 05:11:41 +08:00
|
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
// Copyright (c) Yuxuan Shui <yshuiv7@gmail.com>
|
|
|
|
|
2018-12-16 01:42:37 +08:00
|
|
|
#include <string.h>
|
|
|
|
|
2018-12-16 02:47:21 +08:00
|
|
|
#include "compiler.h"
|
2018-12-16 01:42:37 +08:00
|
|
|
#include "string_utils.h"
|
|
|
|
#include "utils.h"
|
|
|
|
|
2019-02-02 09:58:41 +08:00
|
|
|
#pragma GCC diagnostic push
|
|
|
|
|
|
|
|
// gcc warns about legitimate strncpy in mstrjoin and mstrextend
|
|
|
|
// strncpy(str, src1, len1) intentional truncates the null byte from src1.
|
|
|
|
// strncpy(str+len1, src2, len2) uses bound depends on the source argument,
|
|
|
|
// but str is allocated with len1+len2+1, so this strncpy can't overflow
|
2019-02-02 10:12:01 +08:00
|
|
|
#pragma GCC diagnostic ignored "-Wpragmas"
|
2019-02-02 09:58:41 +08:00
|
|
|
#pragma GCC diagnostic ignored "-Wstringop-truncation"
|
|
|
|
#pragma GCC diagnostic ignored "-Wstringop-overflow"
|
|
|
|
|
2018-12-16 01:42:37 +08:00
|
|
|
/**
|
|
|
|
* Allocate the space and join two strings.
|
|
|
|
*/
|
|
|
|
char *mstrjoin(const char *src1, const char *src2) {
|
2019-01-30 08:12:12 +08:00
|
|
|
auto len1 = strlen(src1);
|
|
|
|
auto len2 = strlen(src2);
|
|
|
|
auto len = len1 + len2 + 1;
|
|
|
|
auto str = ccalloc(len, char);
|
2018-12-16 01:42:37 +08:00
|
|
|
|
2019-01-30 08:12:12 +08:00
|
|
|
strncpy(str, src1, len1);
|
|
|
|
strncpy(str + len1, src2, len2);
|
|
|
|
str[len - 1] = '\0';
|
2018-12-16 01:42:37 +08:00
|
|
|
|
2019-01-30 08:12:12 +08:00
|
|
|
return str;
|
2018-12-16 01:42:37 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Concatenate a string on heap with another string.
|
|
|
|
*/
|
|
|
|
void mstrextend(char **psrc1, const char *src2) {
|
2019-01-30 08:12:12 +08:00
|
|
|
if (!*psrc1) {
|
|
|
|
*psrc1 = strdup(src2);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto len1 = strlen(*psrc1);
|
|
|
|
auto len2 = strlen(src2);
|
|
|
|
auto len = len1 + len2 + 1;
|
|
|
|
*psrc1 = crealloc(*psrc1, len);
|
|
|
|
|
|
|
|
strncpy(*psrc1 + len1, src2, len2);
|
|
|
|
(*psrc1)[len - 1] = '\0';
|
2018-12-16 01:42:37 +08:00
|
|
|
}
|
Parse number locale-independently
Previously we were using glibc's strtod function to parse floating point
numbers. The problem is, strtod is locale dependent. Meaning 7,7 might
be parsed as two numbers (7 and 7) in one locale, and parsed as one
number (7 point 7) in another locale. This is undesirable.
We need to set the locale to a value we know to make number parsing
consistently. We could use setlocale(), but that is not thread-safe. We
can also use uselocale(), which is thread-safe, but doesn't cover strtod
(Yeah, some of the locale-aware functions only acknowledge the global
locale, not the thread local one).
So in frustration, I just wrote a simple floating point number parser
myself. This parser obviously doesn't cover all cases strtod covers, but
is good enough for our needs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-02-02 09:22:41 +08:00
|
|
|
|
2019-02-02 09:58:41 +08:00
|
|
|
#pragma GCC diagnostic pop
|
|
|
|
|
Parse number locale-independently
Previously we were using glibc's strtod function to parse floating point
numbers. The problem is, strtod is locale dependent. Meaning 7,7 might
be parsed as two numbers (7 and 7) in one locale, and parsed as one
number (7 point 7) in another locale. This is undesirable.
We need to set the locale to a value we know to make number parsing
consistently. We could use setlocale(), but that is not thread-safe. We
can also use uselocale(), which is thread-safe, but doesn't cover strtod
(Yeah, some of the locale-aware functions only acknowledge the global
locale, not the thread local one).
So in frustration, I just wrote a simple floating point number parser
myself. This parser obviously doesn't cover all cases strtod covers, but
is good enough for our needs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-02-02 09:22:41 +08:00
|
|
|
/// Parse a floating point number of form (+|-)?[0-9]*(\.[0-9]*)
|
|
|
|
double strtod_simple(const char *src, const char **end) {
|
2019-03-10 20:34:37 +08:00
|
|
|
double neg = 1;
|
|
|
|
if (*src == '-') {
|
|
|
|
neg = -1;
|
|
|
|
src++;
|
|
|
|
} else if (*src == '+') {
|
|
|
|
src++;
|
|
|
|
}
|
Parse number locale-independently
Previously we were using glibc's strtod function to parse floating point
numbers. The problem is, strtod is locale dependent. Meaning 7,7 might
be parsed as two numbers (7 and 7) in one locale, and parsed as one
number (7 point 7) in another locale. This is undesirable.
We need to set the locale to a value we know to make number parsing
consistently. We could use setlocale(), but that is not thread-safe. We
can also use uselocale(), which is thread-safe, but doesn't cover strtod
(Yeah, some of the locale-aware functions only acknowledge the global
locale, not the thread local one).
So in frustration, I just wrote a simple floating point number parser
myself. This parser obviously doesn't cover all cases strtod covers, but
is good enough for our needs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-02-02 09:22:41 +08:00
|
|
|
|
2019-03-10 20:34:37 +08:00
|
|
|
double ret = 0;
|
|
|
|
while (*src >= '0' && *src <= '9') {
|
|
|
|
ret = ret * 10 + (*src - '0');
|
|
|
|
src++;
|
|
|
|
}
|
Parse number locale-independently
Previously we were using glibc's strtod function to parse floating point
numbers. The problem is, strtod is locale dependent. Meaning 7,7 might
be parsed as two numbers (7 and 7) in one locale, and parsed as one
number (7 point 7) in another locale. This is undesirable.
We need to set the locale to a value we know to make number parsing
consistently. We could use setlocale(), but that is not thread-safe. We
can also use uselocale(), which is thread-safe, but doesn't cover strtod
(Yeah, some of the locale-aware functions only acknowledge the global
locale, not the thread local one).
So in frustration, I just wrote a simple floating point number parser
myself. This parser obviously doesn't cover all cases strtod covers, but
is good enough for our needs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-02-02 09:22:41 +08:00
|
|
|
|
2019-03-10 20:34:37 +08:00
|
|
|
if (*src == '.') {
|
|
|
|
double frac = 0, mult = 0.1;
|
|
|
|
src++;
|
|
|
|
while (*src >= '0' && *src <= '9') {
|
|
|
|
frac += mult * (*src - '0');
|
|
|
|
mult *= 0.1;
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
ret += frac;
|
|
|
|
}
|
Parse number locale-independently
Previously we were using glibc's strtod function to parse floating point
numbers. The problem is, strtod is locale dependent. Meaning 7,7 might
be parsed as two numbers (7 and 7) in one locale, and parsed as one
number (7 point 7) in another locale. This is undesirable.
We need to set the locale to a value we know to make number parsing
consistently. We could use setlocale(), but that is not thread-safe. We
can also use uselocale(), which is thread-safe, but doesn't cover strtod
(Yeah, some of the locale-aware functions only acknowledge the global
locale, not the thread local one).
So in frustration, I just wrote a simple floating point number parser
myself. This parser obviously doesn't cover all cases strtod covers, but
is good enough for our needs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-02-02 09:22:41 +08:00
|
|
|
|
2019-03-10 20:34:37 +08:00
|
|
|
*end = src;
|
|
|
|
return ret * neg;
|
Parse number locale-independently
Previously we were using glibc's strtod function to parse floating point
numbers. The problem is, strtod is locale dependent. Meaning 7,7 might
be parsed as two numbers (7 and 7) in one locale, and parsed as one
number (7 point 7) in another locale. This is undesirable.
We need to set the locale to a value we know to make number parsing
consistently. We could use setlocale(), but that is not thread-safe. We
can also use uselocale(), which is thread-safe, but doesn't cover strtod
(Yeah, some of the locale-aware functions only acknowledge the global
locale, not the thread local one).
So in frustration, I just wrote a simple floating point number parser
myself. This parser obviously doesn't cover all cases strtod covers, but
is good enough for our needs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
2019-02-02 09:22:41 +08:00
|
|
|
}
|