- A question about if constexpr - 15 Updates
- Obfuscate Assembler (Remove Function Calls, Unroll Loops) - 2 Updates
- Linker discards redundant .o inside .a - 7 Updates
| "Öö Tiib" <ootiib@hot.ee>: Nov 29 04:41PM -0800 On Friday, 29 November 2019 18:35:35 UTC+2, Mr Flibble wrote: > > revisit that decision after every release. What is reasonable > > now may become backwards few years later. > Utter tosh. if constexpr is far more than a "performance optimization"; it is especially useful in template code. Utter jive, it was warning C4127 under discussion not usefulness of if constexpr. What is the value warning C4127 "consider hinting me that we can performance-optimize here."? |
| "Öö Tiib" <ootiib@hot.ee>: Nov 29 04:52PM -0800 On Friday, 29 November 2019 18:33:53 UTC+2, Mr Flibble wrote: > VC++ is correct to warn about while(2+2 == 4) and not for(;;) the later being the only acceptable why to do an endless loop (I don't agree that while(true) is just as good as it is syntactically less clean). It was while(1) versus for(;;) last I saw anyone bothering to discuss those and these are still as apparently equivalent as these were back then. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 29 05:15PM -0800 On Friday, 29 November 2019 10:38:18 UTC+2, David Brown wrote: > <https://en.cppreference.com/w/cpp/language/if> > One other point is that since the discarded part is discarded, any > identifiers it uses do not need to be defined or linked in with the code. I'm in doubt about that other point. I noticed it long time ago that the implementations do not link useless functions. It was like 2004 or maybe 2007. I did delete unused functions after refactoring and since there was tens of such I used impossibility to set breakpoints in those as heuristic that these are now unused. However my program became ill-formed since I had erased one that was optimized out but not because it wasn't called but because it was called only in branch that was impossible to take. So compilers did not need if constexpr back then for it ... why these suddenly started to need it now? |
| Paavo Helde <myfirstname@osa.pri.ee>: Nov 30 08:19AM +0200 On 30.11.2019 3:15, Öö Tiib wrote: > was called only in branch that was impossible to take. > So compilers did not need if constexpr back then for it ... why > these suddenly started to need it now? You answered that yourself: constexpr is needed to make your ill-formed program well-formed again. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Nov 30 12:24AM -0600 Paavo Helde wrote: > > these suddenly started to need it now? > You answered that yourself: constexpr is needed to make your ill-formed > program well-formed again. No. What would make his program well formed is the removal of that "branch that [is] impossible to take". (HTF doesd one *write* such a branch?) |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 02:13AM -0800 On Saturday, 30 November 2019 08:24:49 UTC+2, Ned Latham wrote: > > program well-formed again. > No. What would make his program well formed is the removal of that > "branch that [is] impossible to take". +1 That did make it. > (HTF doesd one *write* such a branch?) It was the effect of evolution. About like that one developer wrote a new feature, other fixed some issue in it and third implemented an improvement. Details in if condition did change during the process so it turned into always false. Neither those programmers nor reviewers of their pull requests did notice that. Perhaps there was some mile- stone pressing as it often is. Then it was released, real data arrived (with what performance of it was weak) and that refactoring took place. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Nov 30 04:56AM -0600 嘱 Tiib wrote: > > No. What would make his program well formed is the removal of that > > "branch that [is] impossible to take". > +1 That did make it. Glad to help. You've erased the function it called as well? > so it turned into always false. Neither those programmers nor reviewers > of their pull requests did notice that. Perhaps there was some mile- > stone pressing as it often is. I've been there. The commercial environment is hostile to thoroughness. > Then it was released, real data arrived > (with what performance of it was weak) and that refactoring took place. I have some difficulty with the mindset behind program development these days; IDEs provide features that make routine programming easier, but get in the way of the unorthodox approach; compilers do the same; even operating systems can be a nuisance. I cut my teeth on assembly-language programming on CP/M machines; thoroughness is productive in that environment, and it translated well for me into HLLs. |
| David Brown <david.brown@hesbynett.no>: Nov 30 12:03PM +0100 On 30/11/2019 01:52, Öö Tiib wrote: > It was while(1) versus for(;;) last I saw anyone bothering to discuss > those and these are still as apparently equivalent as these were back > then. I always use "while (true)" - and all my programs have that at least once, being small embedded systems. I have never liked the look of "for (;;)" - and I fear that some email programs will turn it into a rather weird smiley! |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 03:20AM -0800 On Saturday, 30 November 2019 12:56:59 UTC+2, Ned Latham wrote: > > > "branch that [is] impossible to take". > > +1 That did make it. > Glad to help. You've erased the function it called as well? That happened in previous step: 1) Compiler left it out from executable, 2) I erased it from code since break-point was impossible to set in it, 3) I erased the worthless branch that stopped to compile. > I cut my teeth on assembly-language programming on CP/M machines; > thoroughness is productive in that environment, and it translated > well for me into HLLs. Yes, it has gone harder since all tools have became easier to use but also the targets are more complicated. It is tried to solve by adding more programmers but synchronizing their effort is also an effort. At the end everybody's vision of what is going on is naive but things get somehow done. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Nov 30 05:38AM -0600 嘱 Tiib wrote: > Ned Latham wrote: ----snip---- > by adding more programmers but synchronizing their effort is also > an effort. At the end everybody's vision of what is going on is > naive but things get somehow done. That "somehow" bothers me. It's what started the over-complication of the programming environment in the first place, IMO, and it continues to influence development in all areas. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 03:47AM -0800 On Saturday, 30 November 2019 13:04:07 UTC+2, David Brown wrote: > > then. > I always use "while (true)" - and all my programs have that at least > once, being small embedded systems. For me it is just style and it is not business of compiler to regulate style. Especially annoying is the warning when someone had wrapped function-like macro's body into do { } while(false) and then compiler starts to whine about while(false). Until there are features available only in preprocessor we need to use macros at places and so also safe idioms with those. > I have never liked the look of "for (;;)" - and I fear that some email > programs will turn it into a rather weird smiley! Pasting to modern chats does it more likely than not. I just thought that in woodbrian's style of prefixing std with :: we can get trigraph <:: in vector<string> that some eldery compilers still support. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 04:57AM -0800 On Saturday, 30 November 2019 13:39:12 UTC+2, Ned Latham wrote: > That "somehow" bothers me. It's what started the over-complication > of the programming environment in the first place, IMO, and it > continues to influence development in all areas. It has been going on for long time. Notice that the project was in mid 2000's. Currently teams of teams of programmers of random skill levels are doing any (even embedded) projects. It is more like norm. So piles of such somehow made stuff is of what our economies consist of. But what can we do? Imagine that we organize some kind of "order of masters" to fight with garbage and for virtue of master. Imagine that we gain power and popularity. Then some monster (Google, Microsoft, Amazon, SAP, Oracle, Apple or combo of such) will figure out how to weaken it, buy it, fill with weasels and noobs and use it for producing and marketing of even more garbage. ;) It is hard to do something that is tricky to hack with power of monsters. But maybe worth to try? :D |
| David Brown <david.brown@hesbynett.no>: Nov 30 03:08PM +0100 On 30/11/2019 12:47, Öö Tiib wrote: >> once, being small embedded systems. > For me it is just style and it is not business of compiler to > regulate style. Agreed. Some prefer "while (true)", some prefer "for (;;)", and some prefer other variations. Still, it is not unreasonable for a compiler to suppose that "while (2 + 2 == 4)" is more likely to be a programmer mistake. Sometimes the line between "unusual, inconsistent or lazy style" and "probable mistake" is not sharp, and a warning can be helpful - like a compiler warning on inconsistent indentation on nested if/else statements. > Especially annoying is the warning when someone had wrapped > function-like macro's body into do { } while(false) and > then compiler starts to whine about while(false). That one would quickly get annoying. |
| Ned Latham <nedlatham@woden.valhalla.oz>: Nov 30 09:46AM -0600 嘱 Tiib wrote: > for producing and marketing of even more garbage. ;) > It is hard to do something that is tricky to hack with power of > monsters. But maybe worth to try? :D Funny you should mention that. I have a project XBNF, which is an eXtended Backus Naur Formalism (like EBNF but extended a little more), and a co-project xbnf, which is a machine reader for XBNF. If you give xbnf the XBNF definition of the syntax of a programming language and the XBNF definition of syntax errors in that language, and matching error messages, it will check the syntax for you and emit error messages. You can give it other XBNF definitions too; matching program commands and High Level Language Productions (HLLP), to emit the first stage of a compilation. XBNF can also define the syntax matching HHLPs with Assembly Language Productions, and OS Productions, and Machine Architecture Productions; with all that xbnf becomes a full-flown compiler capable of running on any machine it can be compiled for, and capable of compiling code in any programming language whatever, for any OS whatever, and to run on pretty much on any machine whatever. Configuration (writing all those syntax files) will be a bitch without a share setup, and as a compiler, it'll be pretty simple, but you'll be able to define (say) C++ with or without things like constexpr as suits you. We'll be free of the tyranny of the compiler-writers. It's a hacker's wet dream. And it's open source. Anyone who gets a copy is an obstacle to the corporates that would sabotage it. If I can get it done. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 11:09AM -0800 On Saturday, 30 November 2019 17:47:15 UTC+2, Ned Latham wrote: > any machine it can be compiled for, and capable of compiling code in > any programming language whatever, for any OS whatever, and to run on > pretty much on any machine whatever. Sounds like you are also claiming doing what Mr Flibble is claiming doing. Very interesting. If neither Mr Flibble nor you are just trolling then may be you should try to cooperate or to compete or something like that. > be able to define (say) C++ with or without things like constexpr as > suits you. We'll be free of the tyranny of the compiler-writers. It's > a hacker's wet dream. However to produce a translator of sophisticated modern programming language (by programming or by configuring something) it will take years of work of decent specialists. > And it's open source. Anyone who gets a copy is an obstacle to the > corporates that would sabotage it. > If I can get it done. Yeah ... and then there is "one ring" of Sauron open sourced. :D I meant with "master" people who are willing to learn to be aware of what they have produced into this world and also to learn capability to carry the weight of responsibility for it. Since monsters apparently don't care about it. |
| David Brown <david.brown@hesbynett.no>: Nov 30 12:00PM +0100 On 29/11/2019 18:18, Scott Lurndal wrote: >> Once your LTO-optimised binary is stripped of all extra symbols, it will >> be very difficult to follow by examination of the object code. > Until you run it under QEMU and get a full instruction/register trace. It will still be difficult to follow there. LTO generally results in a lot of inlining, including partial inlining - code from all over the project can get merged together into huge blocks of assembly with no clear structure. With -O3 you get unrolling, re-arrangement of loops, function cloning, and more. Certainly QEMU or similar tools are a big aid to tracing the functionality of code (and they pretty much neutralise things like code encryption), but they won't make it an easy job here. Even for more complex obfuscation techniques, like self-modifying code, extra jumps added all over, extra dummy code, etc., there are tools available for picking out the real code flow - though they may be hard to find and expensive to get. That is why complex obfuscation is pointless here, but LTO is a simple and easy way to get block casual inspection of the code. |
| scott@slp53.sl.home (Scott Lurndal): Nov 30 07:03PM >project can get merged together into huge blocks of assembly with no >clear structure. With -O3 you get unrolling, re-arrangement of loops, >function cloning, and more. I spend every day debugging processors that run such code; for which it is necessary to understand what the code is trying to accomplish, often without source. Simulation tools and in-circuit emulation can be quite powerful. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Nov 30 02:37AM -0800 > symbol prompted them to be included) > from an archive is in the link map > (assuming you ask for one). -M Thank you. Looks like I need to tell gcc to pass the "--print-map" flag to ld. gcc -Wl,--print-map main.c -o prog -l:libmonkey.a |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Nov 30 02:38AM -0800 Scott said: > An archive (.a) is simply a 'folder' of object files. I thought everyone called. these .a files "static libraries". |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 02:48AM -0800 On Saturday, 30 November 2019 12:39:00 UTC+2, Frederick Gotham wrote: > > An archive (.a) is simply a 'folder' of object files. > I thought everyone called. > these .a files "static libraries". That is fancy term about some .o (object) files combined into .a (archive) file. . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Nov 30 05:37PM On Sat, 2019-11-30, Öö Tiib wrote: >> these .a files "static libraries". > That is fancy term about some .o (object) files combined into > .a (archive) file. I don't know about "fancy"; as far as I can tell "static library" is the term people use for libraries which aren't shared libraries. But they /are/ implemented as archive files on Unix: something similar to a tar archive containing object files, and often a symbol table for faster linking. Anyway, the main point upthread was that they aren't called "static shared libraries". /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Nov 30 07:12PM +0100 On 30/11/2019 11:38, Frederick Gotham wrote: >> An archive (.a) is simply a 'folder' of object files. > I thought everyone called. > these .a files "static libraries". Yes - but not "static /shared/ libraries". "Shared libraries" generally means libraries that are shared at run time - ".so" files on Linux, ".dll" files on Windows. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 30 10:25AM -0800 On Saturday, 30 November 2019 19:37:16 UTC+2, Jorgen Grahn wrote: > > .a (archive) file. > I don't know about "fancy"; as far as I can tell "static library" > is the term people use for libraries which aren't shared libraries. Correct. > But they /are/ implemented as archive files on Unix: something similar > to a tar archive containing object files, and often a symbol table for > faster linking. So these can be distributed as 1) folder of source code or 2) as that archive file and folder of header files or even 3) just folder of header files (then it is "header-only statically-linked library" or just "header-only library"). > Anyway, the main point upthread was that they aren't called "static > shared libraries". I fully agree with that. I was attempting to add a pedantry point to the mix in sense that calling that .a file alone (IOW wihout headers) as "shared library" is becoming a bit extravagant. Sorry for confusion if I caused any. |
| scott@slp53.sl.home (Scott Lurndal): Nov 30 07:00PM >> An archive (.a) is simply a 'folder' of object files. >I thought everyone called. > these .a files "static libraries". That's not the term you used. I'm not sure why you felt it necessary to snip that part of your response. Frederick Gotham <cauldwell.thomas@gmail.com> writes: >I compile this library to produce a static shared library. All of the objec= >t files are gathered together into an archive (In Linux, this is a ".a" fil= >e). Careful with your terminology. An archive file is not a 'static shared library'. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment