- How all the cool kids are getting array lengths from C++11 onwards - 3 Updates
- Why I can't split a static library? - 3 Updates
- The next technological singularity .. coming soon - 1 Update
- Users needed - 2 Updates
- Thread must sleep forever (Try to double-lock mutex?) - 2 Updates
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 25 03:38PM On Thu, 2019-10-24, David Brown wrote: ... > (My money is still on the fishing term - it fits the usage very > accurately, and is confirmed by people who have used Usenet pretty much > since its conception.) The fishing term, boosted by the mythological creatures. I bet a less catchy (pun unintended) fishing term wouldn't have become so popular. > Rather than argue further, I recommend you take a couple of hours break > from Usenet and watch this film. It is time well spent! > <https://en.wikipedia.org/wiki/Trollhunter> Haven't seen it, but this one is nice, after a fashion: https://en.wikipedia.org/wiki/Border_(2018_Swedish_film) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Keith Thompson <kst-u@mib.org>: Oct 25 12:03PM -0700 > hours, but that's far less harmful than what you've been doing for a > few years (including your personal email follow-up's). > With that said, I don't think you realise what you're doing. Since you haven't responded to my email, I'm going to assume that you're not interested in explaining further. Feel free to email me if you want to discuss this. Meanwhile, I'll just ignore your vague insults. Everyone, please don't increase the signal-to-noise ratio by posting further about this here. Anyone who insists on doing so will have to change the followup headers. -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Real Troll <Real.Troll@Trolls.com>: Oct 25 04:50PM -0400 On 25/10/2019 20:03, Keith Thompson wrote: > Everyone, please don't increase the signal-to-noise ratio by posting > further about this here. Anyone who insists on doing so will have > to change the followup headers. People wants to discuss the meaning of Troll so where else can they discuss this? Follow up to alt.idiots |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 25 03:18PM On Fri, 2019-10-25, Frederick Gotham wrote: > My program would be too easy to reverse-engineer if I linked the > library dynamically, so I'm linking it statically and obfuscating it > as best I can. I'll not comment on obscurity as a technique for security, but what you write is orthogonal to what Ian Collins wrote. You don't have to commit libfoo.a binaries to SCM in order to link statically. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| David Brown <david.brown@hesbynett.no>: Oct 25 05:20PM +0200 On 25/10/2019 15:31, Frederick Gotham wrote: > product, and so after I produce my binary executables and libraries, > I run them through a decompiler and try to see how difficult it would > be to reverse-engineer. My initial thoughts are that obfuscating your code is a bad idea, a misunderstanding of what is important for security, and even if it was a good idea, then it does not sound like a good way to achieve this. My initial thoughts may be wrong, as I don't know anything more than the short paragraph above, but "security by obscurity" is rarely a good idea. > My program would be too easy to reverse-engineer if I linked the > library dynamically, so I'm linking it statically and obfuscating it > as best I can. My recommendation would be to avoid the library altogether - certainly do not consider it a separate item to be produced and checked into an SCM (the clue is in the name - "Source Control Manager"). Rather, you should consider using link-time optimisation. With link-time optimisation, high compiler optimisation levels, no debugging information, careful control of elf symbol visibility, and stripped executables, your generated code will be incomprehensible. I doubt if any other kind of obfuscation would make a measurable difference - and yet you still have clear and maintainable source code. (You might also want to disable RTTI.) |
| Vir Campestris <vir.campestris@invalid.invalid>: Oct 25 09:36PM +0100 On 25/10/2019 16:18, Jorgen Grahn wrote: > I'll not comment on obscurity as a technique for security, but what > you write is orthogonal to what Ian Collins wrote. You don't have to > commit libfoo.a binaries to SCM in order to link statically. Put the sources in the SCM. You'll need them next time you do a rebuild. And your security will last until two things happen: - You protect something of sufficient importance - About 3 more weeks pass. Been there, done that, got the tee shirt. We were making several releases a year. Luckily security of a few weeks was saleable. Andy |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Oct 25 08:36PM +0100 Hi! The sequel to Google's "quantum supremacy" technological singularity in the form of "neos" my universal compiler than can compile ANY programming language is coming soon. https://neos.dev /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Bryne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| David Brown <david.brown@hesbynett.no>: Oct 25 05:11PM +0200 On 25/10/2019 13:11, Juha Nieminen wrote: >> want to advertise your commercial company, do it elsewhere. > To be completely honest, I think you are being a bit too harsh, > probably based on his past behavior in this newsgroup. As I understand it (and I hope he'll correct any mistakes I make), he is running a company based on software services, including this "middleware". He does not charge any money for this serialisation library or the use of his "online generator", but is presumably hoping that people who use it will pay for other development services. He has offered sponsorship money and time resources to anyone using the middleware - this is clearly a business prospect, with the expectation that the user will pay for other services or at least provide a reference as advertising for other customers. His post is therefore an unsolicited commercial post - spam. If one of the more helpful posters in the group were to make a small, one-off announcement of a new and exciting product they had made, I think many people would not object. But a substantial proportion of Brian's posts are spam like this, or direct requests for other people to support his commercial work with reviews, suggestions, and other help - often such spam hijacks other people's threads. (I am quite happy with his on-topic posts and discussions about C++.) No, I don't think I am being too harsh - and yes, this is because of his past behaviour in this newsgroup. >> have to offer heavy bribes to have any chance of getting a single user, >> then you should be questioning the business sense of the project.) > But you may have a point there. My advice here was given sincerely. I don't think it is right for him to post spam in this group, but I am still happy to give suggestions to help his business. |
| Keith Thompson <kst-u@mib.org>: Oct 25 11:47AM -0700 David Brown <david.brown@hesbynett.no> writes: [...] > His post is therefore an unsolicited commercial post - spam. [...] Spam needn't be commercial. (This is a small quibble, not affecting your main point.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst> Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */ |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 25 04:07PM On Fri, 2019-10-25, Scott Lurndal wrote: > red floyd <no.spam@its.invalid> writes: >>On 10/24/19 1:46 AM, Jorgen Grahn wrote: ... >>loop: >> for (;;) pause(); > raise(SIGSTOP); The exec() solution has one more benefit: it frees up virtual memory. But we're pretty far offtopic now; I brought it up as a reminder that platform-specific features are sometimes the best tool for the job. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| scott@slp53.sl.home (Scott Lurndal): Oct 25 04:22PM >>> for (;;) pause(); >> raise(SIGSTOP); >The exec() solution has one more benefit: it frees up virtual memory. Although the only overhead associated with virtual memory is the page tables. The OS can always reclaim the physical memory by swapping out dirty pages and replacing clean pages owned by the SIGSTOP'd process. |
| 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