Age | Commit message (Collapse) | Author |
|
|
|
Thanks to Nihal Jere for his initial patches implementing this
feature.
Fixes #35.
|
|
Also, make utf*enc assert that the codepoint is valid and return 0
for an invalid codepoint. This makes it possible to use safely
without error checking. We intend that these functions will only
be called with valid codepoints.
|
|
Also, make utf8dec take unsigned char * to avoid overflow when
converting to signed char.
|
|
|
|
Although we don't need the cnew in this case, we still need to do
the appropriate extension to 32-bit.
|
|
We explicitly ignore ERANGE for strtod, and in any other error case,
the end pointer is set to the beginning of the string.
|
|
It is implementation-defined whether malloc returns NULL or some
pointer when the size is 0, so we don't want to error out if the
implementation chose NULL.
|
|
We now hard-code the float precision in the format string instead
of using the float.h macros.
The other headers were never used (except maybe prior to the first
commit).
|
|
7e838669 removed conversion to bool for int expressions used only
to control jnz, but incorrectly dropped the conversion for the
right-hand-side of logical and/or as well. We need the result of
the expression to be 0 or 1, so we still need that conversion.
|
|
|
|
|
|
Instead, use an additional int64_t member in the union. Since
exact-width integer types have no padding bits or trap representations,
and use two's-complement representation, we can portably access an
int64_t union member stored as uint64_t and vice-versa.
This allows us to reinterpret the value without invoking potentially
implementation-defined behavior of casting an unsigned integer to
a signed integer type which may not be able to represent its value.
|
|
This will prepare us for adding a signed int64_t field called i.
|
|
We now do this evaluation during parsing.
|
|
We don't need exact-width integer types here.
|
|
This compiles `0 ? e1 : e2` as `e2`, and `1 ? e1 : e2` as `e1`
(while still adjusting the type as necessary).
|
|
|
|
|
|
As in ede6a5c9, if an expression is used only to control a jnz, we
don't need to convert it to a 0 or 1 value. QBE ignores the upper
32-bits of the argument to jnz, so the conversion is still needed
for pointer, long, and floating point types (including float since
-0 has non-zero bit representation).
|
|
QBE doesn't emit position-independent code, so we don't want __PIC__
defined if the preprocessor does by default.
|
|
|
|
We don't have any of these currently, but it's easier to support
than to error out.
|
|
|
|
|
|
This reverts commit c16f07acf655b9f4fb006d8256b4027fb5a13aa8.
This incorrectly allows octal escapes to span between adjacent
string literals (e.g. "\0" "1" is not the same as "\01").
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We are already using cpp here, so -E is redundant.
|
|
Since we no longer pass -P to cpp ourselves, we need to pass it
through when it appears on the command-line instead of ignoring it.
|
|
Zero-length array members are quite common in linux UAPI headers,
where they don't follow the restrictions of flexible array members.
Since they are non-standard, relax the error checking for them,
rather than considering them the same as a flexible array member.
|
|
If the argument was a function parameter, its type has already been
adjusted. So on x86_64, we can't just ignore the automatic
array-to-pointer conversion, since it was never a pointer to begin
with.
Instead, keep track of the adjusted va_list type, and check that
the arguments to varargs built-ins match that type.
|
|
|
|
Previously, cproc effectively used used
typedef struct { /* 32 bytes, 8-byte aligned */ } __builtin_va_list[1];
However, this is not quite correct for x86_64 nor aarch64, though
it was close enough for both to work in most cases.
In actuality, for x86_64 we want
typedef struct { /* 24 bytes, 8-byte aligned */ } __builtin_va_list[1];
and for aarch64 we want
typedef struct { /* 32 bytes, 8-byte aligned */ } __builtin_va_list;
The difference only appears when the size of va_list matters, or
when va_list is passed as a parameter. However, the former is not
often the case, and the aarch64 ABI replaces aggregate arguments
with pointers to caller-allocated memory, which is quite similar
to arrays decaying to pointers in C except that the struct is not
copied.
Additionally, riscv64 simply uses
typedef void *__builtin_va_list;
which again has a different size and calling convention.
To fix this, make the __builtin_va_list type architecture-specific
and use architecture-specific tests for varargs-related functionality.
|
|
|
|
|
|
|
|
|
|
The location should not include preceding whitespace and was off
by one.
|
|
|
|
Fixes #66.
|
|
|
|
|
|
Some operating systems do not support uchar.h, and glibc only defines
char16_t/char32_t for GNU C compilers.
|
|
When declarator() is called with allowabstract == false, the caller
can assume that it will always return the identifier being declared.
However, abstract function declarators were incorrectly accepted
in this case with name set to NULL instead of erroring out due to
invalid syntax.
To fix this, only skip forward to function declarator parsing for
abstract declarators, since this is the only case where we can't
immediately tell whether we have a parenthesized declarator or a
function declarator.
Fixes #74.
|