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

If REG_* is defined by the operating system and collides with Hatari
namespace, isn't it possible to use an #include "foo..h" locally to avoid
the collision? Or is there a bigger issue here?

- When you can't simultaneously use the #defines from #include "foo.h"
and #include <foo.h> in the same .c file because of name collisions.

- The scope of a #define directive is limited to the file where it is defined;
and to the files where it is included with an #include directive.

- I can can imagine that register names will have collisions across

different architectures (especially for emulators).

On Sun, Jul 10, 2022 at 4:06 AM Thomas Huth <th.huth@xxxxxxxxx> wrote:

Am Sun, 10 Jul 2022 10:46:10 +0000
schrieb Thomas Huth <th.huth@xxxxxxxxx>:

> Am Sat, 09 Jul 2022 18:49:35 +0200
> schrieb Thorsten Otto <admin@xxxxxxxxxxx>:
....
> > 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...

.... or simple avoid including <signal.h> since that seems to be header that
is pulling in <sys/ucontext.h>. The culprit seems to be the #include in
src/cpu/debug.c where we do not really need it, so let's give that a try
first.

Thomas