~ecs

trapped on the surface of a sphere

https://ecs.d2evs.net

she/her

~ecs/public-inbox

Last active a month ago

~ecs/mrsh-dev

Last active 3 months ago
View more

Recent activity

Re: [PATCH harec] Add C++ templates to Hare 11 days ago

From Ember Sawady to ~sircmpwn/hare-dev

thanks!

to git@git.sr.ht:~sircmpwn/harec
  b5e3f96..5434b13  master -> master

Re: What happens with array size after free call? 30 days ago

From Ember Sawady to ~sircmpwn/hare-users

On Wed Mar 13, 2024 at 9:43 PM UTC, Aleksander Szczygieł wrote:
> > not quite, that code is actually correct according to the spec as of
> > now, and i think it should stay that way
> > 
> > free() on slices frees the data pointer, not the slice itself:
>
> If the len field of the slice is still "alive" after free() maybe it 
> should be set to 0? I'm just voicing my opinion as an user but I cannot 
> see this behaviour as anything but confusing. It probably will need to 

i thought about this, but as you said, it wouldn't be able to update
aliases of the slice:

let sl = alloc([0]...);

Re: What happens with array size after free call? 30 days ago

From Ember Sawady to ~sircmpwn/hare-users

On Mon Mar 11, 2024 at 3:26 PM UTC, Drew DeVault wrote:
> On Mon Mar 11, 2024 at 4:09 PM CET, Aleksander Szczygieł wrote:
> > I'm just Hare user so treat my words as just answer from other Hare 
> > user, not as official help.
> >
> > I would say that this example looks like use-after-free which is 
> > programmer error. Shouldn't new allocator catch this case?
>
> This is use-after-free. The new allocator is not perfect, it cannot
> detect read-after-free and can only detect write-after-free on a future
> allocation that affects a nearby bucket.

not quite, that code is actually correct according to the spec as of
now, and i think it should stay that way

Re: strings::toutf8 allow to write more then allocated 30 days ago

From Ember Sawady to ~sircmpwn/hare-users

On Tue Mar 12, 2024 at 3:53 PM UTC, Drew DeVault wrote:
> let mem: []u8 = alloc([0...], 2);
> mem[..] = strings::toutf8("éèё∞")[..];

fyi the second [..] isn't needed:

mem[..] = strings::toutf8("éèё∞");

Re: [PATCH hare] fix mixed indentation a month ago

From Ember Sawady to ~sircmpwn/hare-dev

On Sat Mar 9, 2024 at 10:08 PM UTC, Sebastian wrote:
> On Sat Mar 9, 2024 at 5:04 PM EST, Ember Sawady wrote:
> > mind adding something to lint.sh for this? i'm pretty sure erroring out
> > on /^\t* / should be correct
>
> We still want to allow leading spaces in multi-line string literals (see
> hare/parse/doc/+test.ha), so this wouldn't work.

right, makes sense. once we have lossless ast, we should probably
rewrite lint.sh in hare, but until then we can merge this without an
automated check; i'll do so next time i'm doing code review

Re: [PATCH hare] fix mixed indentation a month ago

From Ember Sawady to ~sircmpwn/hare-dev

mind adding something to lint.sh for this? i'm pretty sure erroring out
on /^\t* / should be correct

Re: capturing the output of a command a month ago

From Ember Sawady to ~sircmpwn/hare-users

On Sat Mar 9, 2024 at 8:31 PM UTC, Andreas Reuleaux wrote:
> Still I am little confused (but maybe that's just me getting used to
> hare, and to low-level C like programming in general again):
>
>   data in my_dirs is a []u8;
>   whereas now I am returning a str, and a string is freed in main
>
> Apparently the string (x as string) that I am returning now and the []u8 (u8 slice)
> data are the same pointer, right?

yeah

> Maybe it would be cleaner thus to return a copy of the string in my_dirs -
> with strings::dup - and to free data where it occurs: in my_dirs? - I

Re: capturing the output of a command a month ago

From Ember Sawady to ~sircmpwn/hare-users

On Sat Mar 9, 2024 at 3:19 PM UTC, Andreas Reuleaux wrote:
> However the program prints just iiiiii.... - as below - also
> I am not sure: do I need to turn the []u8 data into a string
> (as I have done here: with strings::fromutf8)

a thing to know about hare's allocator: whenever you see "iiiii...",
think about use-after-free. when you free something, free() overwrites
it with a bunch of "i"s, in order to be able to detect write-after-free

> fn my_dirs() strings::tokenizer = {
-%<-
>     let data = io::drain(pipe.0)!;
>     defer free(data);

Re: When I should use return and when yield? a month ago

From Ember Sawady to ~sircmpwn/hare-users

On Sat Mar 9, 2024 at 12:51 PM UTC, Dmitry B wrote:
>      fmt::println(if (true) {
>                 return 10;
>         } else {
>                 return 20;
>         })!; // prints 10

return will return a value from a function, yield "returns" a value from
a compound expression:

fn print() int = {
	fmt::println("print",
		if (true) { return 10; } else { return 20; })!;
	return 30;

Re: rt::memcpy corner case behavior a month ago

From Ember Sawady to ~sircmpwn/hare-dev

we've thought about putting some parts of rt:: in the spec, this would
definitely fit in there if we decide to do that. alternatively, we've
also considered having a separate stdlib spec, under which this could
also fall

i tentatively think we should at least continue allowing this to
segfault if we specify rt::memcpy, and i'm open to either allowing
0-length invalid memcpys or continuing to segfault in our implementation