|
If you've got a system that supports dc, try this:
dc -e '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x'
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
How long do I need to wait for it to finish? 
|
|
|
|
|
It will stop when it has guessed your password and emailed it.
[I have no idea what it does]
|
|
|
|
|
Well, after about 24 hours on an ancient and very slow laptop, it hit this milestone:
99999847
99999931
99999941
99999959
99999971
99999989
100000007
100000037
100000039
100000049
100000073
100000081
100000123
100000127
100000193
100000213
100000217
100000223 I took pity on the poor beast shortly afterwards.  
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
|
I don't have a problem converting C to C++ except when it comes to interrupt handlers, they're a bit tricky.
But then again I'm not converting very complicated code...AVR devices are pretty simple.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
The Eureka moment with C++ is when you understand what features you really don't want to use because they make the code less comprehensible. like multiple inheritance from multiple classes with a common base class.
That being said, I once wrote a co-operative multitasking OS for an embedded system in less than 15K of binary in Turbo C++. All the task and timer lists were automatically set up by the class initializers at startup. Just link it in and it got scheduled.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
My issue comes largely from my finicky-ness. I do a lot of C++ programming, and while I hesitate to say I'm proficient at C++, on balance I'd be lying if I said I didn't think I was.
What I mean by being picky is that I don't keep C-isms in my C++ code. I port macros to ifs on constexpr values, and I use templates a lot, like for pin assignments in this case, but it means restructuring code, which means understanding it.
Real programmers use butterflies
|
|
|
|
|
C++ is my favorite language because it does not force you to do anything. That does include making it readable, which is the original author's fault not the language. Languages that force you to make your code readable will inevitably loose some (potentially very useful) features in order to make that happen, like #define for example.
I admit I am guilty of intentionally making code less readable, only because I am forced to run it through a painfully awful "security" code scanner. The program is a web api in c# and the only way we can take any kind of data from the db and return it to the caller without the scanner whining is to store the data in a dictionary (dynamic) and then retrieve it back again, so that's been wrapped up in a pair of methods: return obfuscator.get<typenamehere>(obfuscator.insert(db.runProc("ProcName", args, or, whatever)))
|
|
|
|
|
I agree with you. I would say my complaint - if anything - I mean, I LOVE C++, is that it makes it easy to do The Wrong Thing(TM), and that includes hiding intent. Showing intent is everything, particularly in C++ where there are a billion ways to skin a million cats. However, that takes practice, is not always possible without comments, and is easy to ignore if you get lazy.
Real programmers use butterflies
|
|
|
|
|
I would say that the PEEKs and POKEs, segmented memory addressing, and gotos in my youthful program studies, were more intent-hiding than almost any of the C++ code I've seen since then! Some early Basic programs had me head scratching a lot!
|
|
|
|
|
#ifndef SCANNER_LIVE
doInjection(args);
#endif
|
|
|
|
|
Unfortunately the scanner isn't intelligent enough to know what ifdef means. We just took all the unit tests out of the repo because it was complaining about using assert, among other things. So now jenkins has to pull 2 repos to run the tests.
|
|
|
|
|
Memtha wrote: only because I am forced to run it through a painfully awful "security" code scanner.
...and because you are working for a company that doesn't know what they are doing. Or perhaps an individual up the authority chain that doesn't.
|
|
|
|
|
working for a company that doesn't know what they are doing
Close. The company is very good, but the client is... government. Need I say more?
Some battles just aren't worth the effort. We had to teach the "security lead" how to use git to get the zip and upload it to the scanning service they have forced on us. It's not even the government personnel that chose the scanner, it's a rival contractor that loves to tout the sheer number of "vulnerabilities" that "they" "addressed" by forcing us to add try/catch/throw on every single method.
|
|
|
|
|
Memtha wrote: but the client is... government. Need I say more?
lol - nope.
|
|
|
|
|
honey the codewitch wrote: The code is evil. It's absolutely terrible to read, almost as if they were *trying* to hide intent.
I am now responsible for a piece of code that's been part of our business for over thirty years. This software handles rendering our proprietary printer language into bitmaps, and then shipping those bitmaps out to be printed. It was originally written by a guy who I'll call BK. BK worked on this one code base for 25 years. It had been 'stable' (bugs are features at that point) for quite a while, and they tried to reassign BK to another project. After six months of doing absolutely nothing he decided to retire when he was confronted.
When this landed in my lap, we had not even recompiled this stuff in over ten years. I looked through the source code a few times to answer questions, but hadn't needed to really understand it. Last fall we had a piece of customer-specific hardware go obsolete so we needed to design a replacement. I started looking through the code to see what would need changed.
Good ![Elephant | [mastadon]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/elephant.gif) ing grief. This code was written explicitly so that only a single person could maintain it. It was in C. Function prototypes weren't used. Header files didn't define the functions or data in the corresponding .C source file. There were numerous global structs, variables, and #define's with 3, 2, and yes even 1! character names. I think the best bit of numb ery was a group of #define's he'd added before #include <windows.h> which changed the definition of a number of values in the Windows headers which his comment (one of the few) claimed "Microsoft got wrong".
I spent over 100 manhours identifying precisely the changes I needed to make and where. My replacement took less than a day from the time I started writing it to when it was compiled, tested, and ready for a trial on customer equipment.
This code is [in]famous for something else. I'm a vulgar man, and I swear a lot in casual conversation with people I know, including my coworkers. That said, I've never cussed or used foul language in my source code. It just didn't seem professional. Until. This. Crap. There is now a comment block in this code following my modifications which looks something like this:
Software Zen: delete this;
|
|
|
|
|
Gary R. Wheeler wrote: I am now responsible for a piece of code that's been part of our business for over thirty years...Function prototypes weren't used. Header files didn't define the functions or data in the corresponding .C source file. There were...
So at least 1992. So yes that was par for the course for C code then. Things like prototypes sort of came about probably associated with C++ (perhaps not entirely but for the same reason that C++ added them.) Someone used to the the older style would not have used them. Globals were something that any C app would be using. Single char variable names were common.
Gary R. Wheeler wrote: a group of #define's he'd added before #include <windows.h> which changed the definition of a number of values in the Windows headers which his comment (one of the few) claimed "Microsoft got wrong".
Could not speak specifically to that but as I recall there were a lot of problems with the early Microsoft C++. I know for a fact that for years after the ANSI C++ spec was released the Microsoft scored very poorly on implementing it. That was back when people could actually post comparisons of software without getting sued.
|
|
|
|
|
In some circumstances what you're saying could be true. This code was adapted to Windows in the early 2000's, so function prototyping was the norm. No excuse there.
jschell wrote: Could not speak specifically to that but as I recall there were a lot of problems with the early Microsoft C++. I know for a fact that for years after the ANSI C++ spec was released the Microsoft scored very poorly on implementing it. That was back when people could actually post comparisons of software without getting sued.
This is a case where BK was redefining constants for arguments to and return values from Windows API functions, thereby guaranteeing they would not work as documented.
BK was an asshole.
Software Zen: delete this;
|
|
|
|
|
C gets you rather close to the machine, but it keeps you there. Meaning there isn't really a way in C NOT to hide intent as you'd be rather busy spelling out mechanics of the "how" explicitly, burying the intent.
I very much agree with you on C++ making it way easier to spell out the intent, letting the library do the how, or at least abstracting it away.
|
|
|
|
|
The one line C contest is holding on line 1. It would like a word.
Real programmers use butterflies
|
|
|
|
|
Quote: I'm poring over C code right now - C really isn't that much better, but fortunately you can do less with it. The code is evil. It's absolutely terrible to read, almost as if they were *trying* to hide intent.
How do you hide intent in C? No overloaded operators, no overloaded functions, no implicit calls to constructors that need explicit calls to destructors, no symbols with identical names in different namespaces ...
The amount of "magic happens implicitly behind the scenes" things in C is ridiculously small.
|
|
|
|
|
By making your code do something that is non-obvious.
Real programmers use butterflies
|
|
|
|
|
but to be honest, that can be done in any language.
I'm reading through "learning python" and just hit the description of formatting strings.
I don't know what that guy was smoking when they came up with their approach, but I want some.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Yeah it can be done in any language it just seems like some languages make it easier to write incomprehensible code than others.
Real programmers use butterflies
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
