Index
> High Level Languages > gif libraries / examples?Goto page Previous 1, 2, 3 |
| Author |
|
|
rugxulo 25 Apr 2018, 06:02
alexfru wrote:
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:
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!  It's not your fault, though. They just really suck (although it's also not their fault that so many d-bags exist). |
|||
25 Apr 2018, 06:02 |
|
|
vivik 25 Apr 2018, 08:51
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 |
|||
|
25 Apr 2018, 08:51 |
|
|
DimonSoft 26 Apr 2018, 21:00
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. |
|||
|
26 Apr 2018, 21:00 |
|
| Goto page Previous 1, 2, 3 < Last Thread | Next Thread > |
Forum Rules:
|