~turminal

Ljubljana, Slovenia

~turminal/test

Last active 1 year, 7 months ago

~turminal/public-inbox

Last active 2 years ago
View more

Recent activity

[PATCH harec] gen_expr_delete: use memcpy instead of memmove 21 hours ago

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]

[PATCH harec] gen_const_array_at: avoid recomputation of the last offset 21 hours ago

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]

[PATCH harec] gen: don't reinvent mkgtemp 21 hours ago

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]

Re: [RFC v1] Autofilling default values in more places 21 hours ago

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.

[PATCH harec] gen: dealias object type in slice assignment 3 days ago

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]

Re: [RFC v1] Mutability overhaul 3 days ago

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.

Re: [PATCH harec] type_store: allow unbounded arrays with undefined member size 3 days ago

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".

Re: [PATCH harec 2/3] Improve handling of invalid UTF-8 in rune/str literals 4 days ago

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.

>

Re: [PATCH harec 3/3] lex: disallow sign in hex literal 4 days ago

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.

Re: [PATCH harec 2/3] Improve handling of invalid UTF-8 in rune/str literals 4 days ago

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