Re: [hatari-devel] Preparing for next release 2.4

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 09 Jul 2022 18:49:35 +0200
schrieb Thorsten Otto <admin@xxxxxxxxxxx>:

> On Samstag, 9. Juli 2022 18:13:53 CEST Thomas Huth wrote:
> > I think I agree with Eero - this sounds like it should rather be fixed in
> > the RISC-V system / libc headers by adding an underscore in front of the
> > macro there.  
> 
> I think i disagree. Symbols with underscores are supposed for implementation 
> only, so either the compiler or some internal library routines. But in this 
> case, it is a symbol that should be visible to user applications (it is an 
> index into the gregs of a processor context, much like REG_RAX etc. on x86), 
> just happens to clash with hatari's own symbols. Also i doubt that such things 
> will be changed in system header files, since it surely will break other 
> applications (like gdb).

So that's <sys/ucontext.h> if I googled that right? Ouch. Why don't they
use a proper prefix there, like UCONTEXT_REG_A0 ? That's just sick, that
pretty much means that all names starting with REG_ cannot be used savely
since you never now what other architecture might come around next,
claiming that "namespace".

> >If someone who's involved with RISC-V could report the bug there, too.  
> 
> I would not consider this being a bug. You'll never know what symbols are 
> defined by header files on not-so-common systems.

Well, that's why system headers normally use the underscore namespace for
non-standardized identifiers, at least in those files that get included
automaticall by other headers. If you look at
https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/riscv/sys/ucontext.h.html
you can also see that the used underscores for "union __riscv_mc_fp_state"
for example.

But it really seems like ucontext.h is claiming the REG_* namespace for its
public interface, so I guess we should rather convert all REG_* identifiers
in Hatari to something different instead...

 Thomas

PS: Funny, but m68k uses R_ as prefix instead, otherwise we would likely
have hit this problem earlier already:
https://code.woboq.org/userspace/glibc/sysdeps/unix/sysv/linux/m68k/sys/ucontext.h.html