I cannot speak for Griska or the reasons why that change was committed. But with respect to my mail from 2/25, once again, all I was doing was hinting that tcc could be configured to not call (the since reverted) unportable APIs.
Anyway, from my point of view, a default of RO=1 is fine. But it should be #ifdef-protected so that tinycc/configure or win32/build-tcc.bat can change it. For instance: #ifndef CONFIG_RUNMEM_RO # define CONFIG_RUNMEM_RO 1 #endif But since I'm new here I'm not going to push such a commit without encouragement. Thanks - Eric On Wed, Feb 28, 2024 at 10:26 PM Herman ten Brugge <hermantenbru...@home.nl> wrote: > On 2/29/24 04:57, Eric Raible wrote: > > Huh? > > My email on 2/24 was definitely not intended to imply anything > about "old windows versions". I was simply trying to make a suggestion > about how to locally configure tcc to avoid a reported compiler error. > > In any case grischka responded 9 or so hours later to say > that the commit that caused that compiler error on windows > had been reverted. > > Griska reverted the memalign code but also made a change to > CONFIG_RUNMEM_RO=0. > I asume this was done because of your mail??? > > Setting CONFIG_RUNMEM_RO=0 looks incorrect to me because it sets write in > executables. > Apple has implemented W^X (Writes can not occur in executables) for > security reasons. > This may also be implemented in in future linux/bsd releases. > > Can I revert the change and set CONFIG_RUNMEM_RO=1 for all targets as > before? > > Herman >
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
