Path: ...!2.eu.feeder.erje.net!feeder.erje.net!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Mon, 25 Mar 2024 15:11:17 +0200
Organization: A noiseless patient Spider
Lines: 45
Message-ID: <20240325161117.00002318@yahoo.com>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
	<20240320114218.151@kylheku.com>
	<20240321211306.779b21d126e122556c34a346@gmail.moc>
	<utkea9$31sr2$1@dont-email.me>
	<utktul$35ng8$1@dont-email.me>
	<utm06k$3glqc$1@dont-email.me>
	<utme8b$3jtip$1@dont-email.me>
	<utn1a0$3ogob$1@dont-email.me>
	<utnh5m$3sdhk$1@dont-email.me>
	<utpenn$dtnq$1@dont-email.me>
	<utq0gh$i9hm$1@dont-email.me>
	<utqaak$kfuv$2@dont-email.me>
	<20240325141628.00006170@yahoo.com>
	<utrqgp$12v02$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 25 Mar 2024 14:11:26 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ff58747de83365f3f96c18f69047f6c9";
	logging-data="1155735"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+i1wlHOTsjnJdOrHHSaQrHIp5YFkB9UE4="
Cancel-Lock: sha1:Tmiv7u5n5hTOM/7bRSbf/MHQi+I=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3197

On Mon, 25 Mar 2024 13:26:01 +0100
David Brown <david.brown@hesbynett.no> wrote:

> On 25/03/2024 12:16, Michael S wrote:
> > On Sun, 24 Mar 2024 23:43:32 +0100
> > David Brown <david.brown@hesbynett.no> wrote:  
> >>
> >> I could be  wrong here, of course.
> >>  
> > 
> > It seems, you are.
> >   
> 
> It happens - and it was not unexpected here, as I said.  I don't have 
> all these compilers installed to test.
> 
> But it would be helpful if you had a /little/ more information.  If
> you don't know why some compilers generate binaries that have memory
> mapped at 0x400000, and others do not, fair enough.  I am curious,
> but it's not at all important.
> 

I am not an expert, but it does not look like the problem is directly
related to compiler or linker. All 32-bit Windows compilers/linkers,
including gcc, clang and MSVC, by default put symbol ___ImageBase at
address 4 MB. However loader relocates it to wherever it wants,
typically much higher.
I don't know for sure why loader does it to images generated by gcc,
clang and MSVC and does not do it to images generated by lccwin and
others, but I have an educated guess: most likely, these other compilers
link by default with an option similar to Microsoft's /Fixed
https://learn.microsoft.com/en-us/cpp/build/reference/fixed-fixed-base-address?view=msvc-170

The option disables ASLR and thus can shorten app load time and make
performance just a little snappier. Still, I wouldn't make it default.

To get similar behavior with [32-bit] MSVC user can specify '/linker
/fixed' on the command line. I don't know how to do it with gcc variant
supplied with msys2. But, I'd guess, if you google for long enough, you
can find it.