Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!news.misty.com!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail From: fir Newsgroups: comp.lang.c Subject: Re: > fails. Because heaps are unlimited whilst stacks are not. Date: Wed, 20 Mar 2024 17:57:37 +0100 Organization: i2pn2 (i2pn.org) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 20 Mar 2024 16:57:36 -0000 (UTC) Injection-Info: i2pn2.org; logging-data="2642529"; mail-complaints-to="usenet@i2pn2.org"; posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0"; User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 In-Reply-To: X-Spam-Checker-Version: SpamAssassin 4.0.0 Bytes: 4563 Lines: 91 fir wrote: > bart wrote: >> On 20/03/2024 14:02, fir wrote: >> >>> i know somewhat how it looks like in win32 : >>> >>> generally the addres space aplication have os from 0x0000 0000 to >>> 0x7fff ffff - which is only 2 gigabytes >>> >>> (hovever i like it and still prefer writing my windows programs on >>> win32 than win 64, 2 gigabytes of ram is enough for me) >>> >>> your program is by default placed at 0x0040 0000 (which is 4MB from >>> start of adres space).. >> >> That's no longer the case with 64-bit machines, not if you use products >> like gcc. This program: >> >> #include "stdio.h" >> int main(void) { >> printf("%p\n", main); >> } >> >> displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using >> `gcc -m32`, it shows 0076155c. >> >>> >>> at least this is what i know >>> >>> >>> the stack in turn is betwwwen your app start that +4MB and the >>> starting point, im not exactly syre but its probably something about >>> +3M down do +1M approximatelly >>> >>> stack could be set to bigger in your exe heder your exe has 9may be >>> modified by -something switch in gcc comandline) and i not tested it >>> afair (or rather tested but forgot the strict conclusions) but i dont >>> se nthing specially wrong even in setting this stack to 100 MB >>> >>> 2 MB by default is silly and if you have 10 GB of ram putting 100 MB >>> for stack is not even a waste becouse if it is not used it only >>> consumes "logical" ram pages afair but reall ram is not even attached >> >> I don't think using a giant stack just one for the benefit of one >> badly-designed function in one library inside a big application is a >> good approach. >> > > but you call this function badly designed becouse it can overflow stack > > - if it cant it is not badly designed then (unles you say on something > other) > > this recursion in fact is not badly designed imo - you only need to be > aware of constraints of data you used it to (and if you care of > constraints of your code you could also somewhat care of constraints on > data) > > its suboptimal as to speed but i wouldnt cal it "badly designed" > > as i said in another thread the error may be to declare stack size, > it not necessarely need to be declared maybe - then you use stack until > the ram will end - as today people use normal ram, nearly none > application is ready to situatuion that ram ends and heap alocations > fail..so with stack may be tha same > > > >> Maybe the routine is never called. Or it's called once then never called >> again but the stack is now committed. >> >> Your floodfill routine uses 48 bytes per call (with my compiler; it >> varies). To floodfill all the pixels in a 3000x4000 pixel image for >> example, would need nearly 600MB of stack, and would involve calls >> nested 12 million deep. >> >> > > there was an shortcut in it you dont need to pass the 2 colors in calls > so i think it rather should use int x int y and ret adress it is 12 > bytes (on 32 bit, i compile 32 bit only) > i wouldnt say its badly designed but for sure its kinda brute-force but not in kinds of like cpu and iterations (like counting milion objects collisions with another milion objets) but more bruteforce in stack usage - but brute force methods are so nice..they just dont work becouse of big numbers possibly there may be written a method of thi recolorisation wich uses 50 bytes of ram, but here i wonder if use even 300 Mb of ram for a blink of an eye time is not standable