Ljubljana, Slovenia
From Bor Grošelj Simić to ~sircmpwn/hare-dev
It is guaranteed that dest < src, so we can safely use memcpy Signed-off-by: Bor Grošelj Simić <bgs@turminal.net> --- src/gen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/gen.c b/src/gen.c index 73cda32..c6e7d3e 100644 --- a/src/gen.c +++ b/src/gen.c @@ -2186,7 +2186,7 @@ gen_expr_delete(struct gen_context *ctx, const struct expression *expr) pushi(ctx->current, &qlen, Q_SUB, &qlen, &qend, NULL); pushi(ctx->current, &mlen, Q_MUL, &qlen, &membsz, NULL); [message trimmed]
From Bor Grošelj Simić to ~sircmpwn/hare-dev
In case of expandable arrays the offset of the last explicitly specified member is used as a parameter to memcpy. Because the address was computed earlier anyway, we can just reuse it. Signed-off-by: Bor Grošelj Simić <bgs@turminal.net> --- src/gen.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/src/gen.c b/src/gen.c index daca666..8b3612f 100644 --- a/src/gen.c +++ b/src/gen.c @@ -1758,9 +1758,10 @@ gen_const_array_at(struct gen_context *ctx, [message trimmed]
From Bor Grošelj Simić to ~sircmpwn/hare-dev
Signed-off-by: Bor Grošelj Simić <bgs@turminal.net> --- src/gen.c | 29 +++++------------------------ 1 file changed, 5 insertions(+), 24 deletions(-) diff --git a/src/gen.c b/src/gen.c index 03ea6f7..daca666 100644 --- a/src/gen.c +++ b/src/gen.c @@ -162,11 +162,7 @@ gen_load(struct gen_context *ctx, struct gen_value object) break; // no-op } struct gen_value value = { [message trimmed]
From Bor Grošelj Simić to ~sircmpwn/hare-rfc
> `...` fills in zero or more values (as opposed to now, where it fills > in one or more values). So [...] will work to initialize any array > type, provided the member type has a definite default value. About the expression... form, under the new rules, `alloc([a(), b(), c()...], 2);` is supposed to be legal. Does c() ever get called (and side-effects observed) in this case? I'm leaning towards no, but either way it's a bit confusing and unfortunate.
From Bor Grošelj Simić to ~sircmpwn/hare-dev
Signed-off-by: Bor Grošelj Simić <bgs@turminal.net> --- src/gen.c | 2 +- tests/08-slices.ha | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/src/gen.c b/src/gen.c index 0ed2489..03ea6f7 100644 --- a/src/gen.c +++ b/src/gen.c @@ -783,7 +783,7 @@ gen_expr_assign_slice(struct gen_context *ctx, const struct expression *expr) struct qbe_value vptr = mkqtmp(ctx, ctx->arch.ptr, ".%d"); pushi(ctx->current, &optr, Q_LOADL, &qobj, NULL); pushi(ctx->current, &vptr, Q_LOADL, &qval, NULL); [message trimmed]
From Bor Grošelj Simić to ~sircmpwn/hare-rfc
On Wed Sep 20, 2023 at 12:07 AM CEST, Sebastian wrote: > On Thu Sep 14, 2023 at 9:51 PM EDT, Bor Grošelj Simić wrote: > > > - Taking the address of an immutable object of type `foo` yields an > > > object of type `*foo` (pointer to immutable foo). > > > > Calling *T a 'pointer to immutable T' imo does not convey the actual > > meaning of the type expression. It's just this particular reference to the > > underlying object that is immutable we don't know anything about the actual > > object. Unfortunately, it's really easy to mess this up mentally when thinking > > about immutability and I think it would be great if we came up with a better > > way to talk about this. > > Hm, I kinda see what you mean. I don't have any better ideas though, > since I think "(im)mutable pointer/slice" is even more misleading.
From Bor Grošelj Simić to ~sircmpwn/hare-dev
On Tue Sep 19, 2023 at 11:50 PM CEST, Sebastian wrote: > On Tue Sep 19, 2023 at 3:51 PM EDT, Bor Grošelj Simić wrote: > > One thing that I find useful about *[*]opaque is the ability to get an > > opaque slice from it via regular unbounded array slicing: > > > > fn to_slice(data: *[*]opaque, ndata: size) = { > > return data[..ndata]; > > }; > > > > Equivalent code without this patch involves quite a bit of casting gymnastics. > > I'm still not convinced tbh. It's only one additional cast, which is > hardly "casting gymnastics".
From Bor Grošelj Simić to ~sircmpwn/hare-dev
On Tue Sep 19, 2023 at 11:29 PM CEST, Sebastian wrote: > On Tue Sep 19, 2023 at 5:32 PM EDT, Bor Grošelj Simić wrote: > > I don't particularly like this. The name \u implies it has something to do with > > unicode in all contexts. Perhaps a less weird alternative would be to have \u > > behave identically in str and rune and instead allow arbitrary \x sequences up > > to 4 bytes in lenght in runes, consistently with how \x allows one to disregard > > the rules in string literals. > > \u does have to do with Unicode in all contexts though. It's just that > codepoints are stored differently in rune than in str. Right. +1 to this part then. >
From Bor Grošelj Simić to ~sircmpwn/hare-dev
'\u aa' was also considered valid before this patch (strto* functions allow whitespace before the number), so the commit message, comments and tests should also reflect that.
From Bor Grošelj Simić to ~sircmpwn/hare-dev
> Hold off on merging this until I send a spec update, I just realized right now I > forgot to do that. Specifically, I imagine the spec will need to be more > explicit about what kind of stuff is allowed in rune/string constants, and the > behavior of \x in rune/string constants will need to be changed. Actually I > should probably talk about that: > > So, some context: \u is kinda weird. It behaves differently depending on where > it's used. In rune literals, it denotes the value the rune should hold, so > '\u1234' is represented as 0x1234. But in string literals, it's converted to > UTF-8. This is weird, but I feel like it's still correct. I don't particularly like this. The name \u implies it has something to do with unicode in all contexts. Perhaps a less weird alternative would be to have \u behave identically in str and rune and instead allow arbitrary \x sequences up