flat assembler
Message board for the users of flat assembler.

flat assembler > High Level Languages > gif libraries / examples?

Goto page Previous  1, 2, 3
Author
Thread Post new topic Reply to topic
alexfru



Joined: 23 Mar 2014
Posts: 66
rugxulo wrote:
EDIT#2: SmallerC seems to be 20 kb (printf) and 12 kb (puts), respectively, on Win32. That is hardly world-ending (again, not using MSVCRT.DLL).

For simplicity and ease of loading/debugging it stores code and data each as an integral number of 4KB pages and also creates a 4KB header. It's not a deal-breaker though. UPX makes less than 4KB out of 12KB.

rugxulo wrote:
EDIT#3: I had to first "restore" (SmallerC's) smlrpp.exe out of MS Security Essentials' quarantine because they suck. Very annoying (yet again), but they're far from the only overzealous antivirus. If anything, they probably penalize smaller .EXEs more than others since those are easier to hide or disseminate.
I never have this problem. Perhaps, because my Smaller C project directory is excluded from search?
Post 25 Apr 2018, 02:58
View user's profile Send private message Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2311
Location: Usono (aka, USA)
alexfru wrote:
rugxulo wrote:
EDIT#2: SmallerC seems to be 20 kb (printf) and 12 kb (puts), respectively, on Win32. That is hardly world-ending (again, not using MSVCRT.DLL).

For simplicity and ease of loading/debugging it stores code and data each as an integral number of 4KB pages and also creates a 4KB header. It's not a deal-breaker though. UPX makes less than 4KB out of 12KB.


4 KB is default cluster size on NTFS anyways, so it's probably reasonable.

Although UPX triggers antiviruses too (among almost everything else, ugh), so I'm not sure how good that (or anything) is (for Win32).

alexfru wrote:

rugxulo wrote:
EDIT#3: I had to first "restore" (SmallerC's) smlrpp.exe out of MS Security Essentials' quarantine because they suck. Very annoying (yet again), but they're far from the only overzealous antivirus. If anything, they probably penalize smaller .EXEs more than others since those are easier to hide or disseminate.
I never have this problem. Perhaps, because my Smaller C project directory is excluded from search?


We already had a long conversation about bad antiviruses falsely flagging your stuff with stupid "generic" heuristics. You make it sound like you had no idea! Laughing It's not your fault, though. They just really suck (although it's also not their fault that so many d-bags exist).
Post 25 Apr 2018, 06:02
View user's profile Send private message Visit poster's website Reply with quote
vivik



Joined: 29 Oct 2016
Posts: 533
I'm fine with exe bigger than 4 kb if somebody will explain what each byte in it does.

>But when you're already relying on MSVC (which I've never downloaded, it's huge, well over 1 GB download)

Iso of vs2005 is 600 mb, https://board.flatassembler.net/topic.php?t=20359
Post 25 Apr 2018, 08:51
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 451
Location: Belarus
alexfru wrote:
These aren't good examples. If the first is a check for signed overflow, it's broken by definition, irrespective of what the compiler does. Likewise, if your code is dereferencing NULL pointers, it's broken by definition. If you don't agree with these definitions, you're not writing in C/C++ or you're not doing it right.

You’re not dereferencing NULL pointers to get into trouble. You’re just skipping a check and that gives an optimizing compiler the right to perform optimizations that don’t make sense from the human POV (although are perfectly valid). Raymond has a good article to start with.

Yes, the cases of integer overflow or NULL dereferencing are easy to avoid. But you don’t write bugless code all the time. To err is human. Some day you fall into a very rare case of UB and it stays unnoticed: either because this particular compiler version decided not to take advantage of UB here or because your test data doesn’t trigger the bug you’ve just introduced.

Standard allows a compiler to do anything in case of UB. Would you bet all your money for your code to have no UBs at all?

alexfru wrote:
As for UB in general, things would've been a bit easier and sometimes more practical on the human side of programming if the degree or effects of undefined behavior had been contained.

Exactly.

---

I see your point: many opimizations performed by C[++] compilers are not really cool tricks that stop being useful with modern processors, and many of them do not take advantage of UB.

But what I really meant is that in the optimization race C[++] folks have traded reliability for code speed by making requirements for UB treatment too relaxed, and it strikes them back now.
Post 26 Apr 2018, 21:00
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.