On Fri Oct 4, 2024 at 9:55 PM CEST, Sebastian wrote:
> I haven't gotten the chance to test this yet, but I remember someone
> else reporting a similar problem. There's a gen bug in harec which
> causes miscompilation when an implicit cast changes type flags (this was
> so annoying to track down lmao). Since const is a type flag, some
> bindings which use `const` instead of `let` miscompile because defers
> run at the wrong time, and I suspect that's what's happening here. I
> have a patch on the ML which makes const a no-op in harec since it's
> already broken anyway and it'll be overhauled in the future, which
> doesn't fully solve the problem since it's still reproducible with error
> flags, but it makes hare-c work at least (if this is what I think it
> is).
>
> Does applying https://lists.sr.ht/~sircmpwn/hare-dev/patches/54910 to

On Fri Oct 4, 2024 at 9:55 PM CEST, Sebastian wrote:
> I haven't gotten the chance to test this yet, but I remember someone
> else reporting a similar problem. There's a gen bug in harec which
> causes miscompilation when an implicit cast changes type flags (this was
> so annoying to track down lmao). Since const is a type flag, some
> bindings which use `const` instead of `let` miscompile because defers
> run at the wrong time, and I suspect that's what's happening here. I
> have a patch on the ML which makes const a no-op in harec since it's
> already broken anyway and it'll be overhauled in the future, which
> doesn't fully solve the problem since it's still reproducible with error
> flags, but it makes hare-c work at least (if this is what I think it
> is).
>
> Does applying https://lists.sr.ht/~sircmpwn/hare-dev/patches/54910 to

On Thu Oct 3, 2024 at 8:18 PM CEST, Max Schillinger wrote:
> What's especially strange:
> The first file listed in the backtrace doesn't even exist. And the 
> directory isn't related to my cwd, the location of hareconv or the 
> header file to be converted:
>
> Backtrace:
> /media/home/max/dev/hare/so_file/io/stream.ha:58:32 io::st_write+0x6b 
> [0x800a63b]

OK, it looks like the wrong paths in the backtrace are a known issue:
https://todo.sr.ht/~sircmpwn/hare/934

But it's still strange that I get `/media/home/max/dev/hare/so_file`

On Fri Oct 4, 2024 at 9:45 AM CEST, Max Schillinger wrote:
> This was Ember's recommendation[2] for how to fix this:
>
> On Wed Nov 29, 2023 at 2:31 AM CET, Ember Sawady wrote:
> > i think the way to do this that would work best would probably be to
> > keep paths absolute in the sources array, and strip either $PWD or the
> > -M argument in the various functions that emit locations
>
> [2]: https://lists.sr.ht/~sircmpwn/hare-users/%3CCWQ9IWWELP77.2TIL8M24VF5F5@mxsr.de%3E#%3CCXAWOPT6SX7K.3MY2T1FC8WBPR@d2evs.net%3E

See this patch for this issue:

https://lists.sr.ht/~sircmpwn/hare-dev/patches/55328

Signed-off-by: Max Schillinger <max@mxsr.de>
---
This fixes two issues:
- Help vim finding the file containing an error:
https://lists.sr.ht/~sircmpwn/hare-users/%3Cbee48d87-53db-41fd-86be-6989733c7a6a@upyum.com%3E
- Let `hare build` print the actual error line in case of
duplicate file names:
https://lists.sr.ht/~sircmpwn/hare-users/%3CCWQ9IWWELP77.2TIL8M24VF5F5@mxsr.de%3E

 include/util.h |  3 +++
 src/check.c    |  2 +-
 src/gen.c      |  6 ++++++
 src/main.c     | 10 ----------
 src/util.c     | 18 ++++++++++++++++++
[message trimmed]

On Fri Oct 4, 2024 at 8:57 AM CEST, Max Schillinger wrote:
> The problem is that `sources[loc.file]` in harec/src/util.c +133 is 
> just "main.ha". It's meant to refer to "bar/main.ha". I'm not sure yet 
> if the convention is to store paths relative to the current module or 
> the current working directory in `sources`.

Now I remember that I had a somehow related issue[1] when I wanted vim 
being able to jump to the error location (possible by printing paths 
relative to the current working directory).

This was Ember's recommendation[2] for how to fix this:

On Wed Nov 29, 2023 at 2:31 AM CET, Ember Sawady wrote:
> i think the way to do this that would work best would probably be to

On Fri Oct 4, 2024 at 8:16 AM CEST, Max Schillinger wrote:
> When I rename "mail.ha" to "main.ha", I can reproduce this error on 
> Linux x86_64 with the current master branch (of qbe, harec and hare).

The problem is that `sources[loc.file]` in harec/src/util.c +133 is just 
"main.ha". It's meant to refer to "bar/main.ha". I'm not sure yet if the 
convention is to store paths relative to the current module or the 
current working directory in `sources`.

On Fri Oct 4, 2024 at 4:46 AM CEST, Lorenz (xha) wrote:
> On Mon, Sep 30, 2024 at 08:41:03PM +0200, Kooda Loutre wrote:
> > Here is a simple example that displays the behavior:
> > 
> > // mail.ha

I think this file was meant to be named "main.ha".

> i cannot reproduce your bug on linux (aarch64) here. for me, harec 
> reports
> the correct error location/file. can you try with the latest master branch
> and see if it fixes the issue for you?

When I rename "mail.ha" to "main.ha", I can reproduce this error on

Hi Sebastian,

I'm trying to convert this C header using hareconv:

ndk/sources/android/native_app_glue/android_native_app_glue.h [1]

It fails with "Illegal pointer access (unknown reason) at address 0x0". 
See the full output below.

What's especially strange:
The first file listed in the backtrace doesn't even exist. And the 
directory isn't related to my cwd, the location of hareconv or the 
header file to be converted:

On Wed Oct 2, 2024 at 9:48 PM CEST, Drew DeVault wrote:
> We generally recommend binutils. You only need GCC if you want to link
> with C libraries.

aarch64-linux-gnu-binutils is indeed much smaller (37 MB). Thank you!