|
Q: Is reusing passwords ok?
A: Oh hell no, you n00b. My grandma didn't even do that. You'll get so hax0red and pwned on every website like ever, bro. Don't do it.
Q: Is reusing ssh keys ok?
A: Of course. You can spread that junk all over the Internet like peanut butter. I mean... sure if someone gets your private key they'd have access to everything. But, omg lolz like whatever... make that key rain up in here.
I wish I could use the joke icon. 
Jeremy Falcon
|
|
|
|
|
In my junior year of college, I was hired by the university's IT department to develop and maintain all the public websites. A bit later on, I was assigned responsibility for the the development and maintenance of the school's intranet website. I lived on campus for 16 hours a day working my way through school and getting the best experience I could. It was a really fun job. The people who also worked there were interesting and fun.
What I remember most about my experience in IT is the running joke we had conjured up. The phrase was, "Welcome to the University's IT department. We have a big rack."
|
|
|
|
|
we are so wide open, we don't even know it. If you really want to know how bad it is, you'll need a TSEC clearance.
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.
|
|
|
|
|
I am convinced that all NIST approved cryptography standards are all hackable by NSA in minutes.
|
|
|
|
|
Sticky notes are not hackable. 
|
|
|
|
|
But the storage density is terrible!
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Micro-SD chip in a key-sized manila envelope.
|
|
|
|
|
Steam the envelope open, read the micro-SD card, then reseal it.
Sometimes old tech is best.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
It's the little things like this that's practically forcing me to learn to Zig. I mean... C should be getting some of this stuff so it stops falling so far behind. I mean, why leave systems languages in the dust?
Such as being able to use underscores to increase readability in long numbers. I mean C# has had it for a while now. What gives?
const jenny: u32 = 867_5309 // don't lose my number
Jeremy Falcon
|
|
|
|
|
Are you suggesting that underscore is significantly better than single quote[^]? Number formatting has been available since C++14.
Mircea
|
|
|
|
|
Does that apply to C as well? If so, I never knew that. Let me try it real quick...
Nope, just tried real quick with an online compiler. It's still a no-go for C. Which is sad IMO, would love to see C see these (say that 5 times real quick).
Jeremy Falcon
|
|
|
|
|
Never heard of that in C#. Seems pointless, so I guess they probably added it.
|
|
|
|
|
Well in C, took us over a decade to a get a bool. So ya know, it's easy to impress me. 
Back in the day if I had a large number I'd just do something like this in a comment beside it:
const int bruh = 123456789;
So, it's not like a huge lifesaver since the comment would serve the same purpose. Just wanna those neat little things.
Jeremy Falcon
|
|
|
|
|
|
We special now. 
Jeremy Falcon
|
|
|
|
|
Dagnabit, I step away for twenty years and everything changes.
Having said that... I expect that HP hasn't advanced DEC/Compaq/HP C for OpenVMS.
|
|
|
|
|
Wait, what?
Why the heck would you add commas for large numbers? It's a number. First, if you are entering large numbers like this in your code in the middle of processing, you need to have your code reviewed. This falls under a magic number. A very long time ago, and I'm being sarcastic, we'd do this:
#define _A_VERY_LARGE_NUMBER 12345678901234
Better yet, we'd so something like:
// Folks, we use metric in this code. If you introduce english units, I will haunt you from the grave.
#define SPEED_OF_LIGHT_METERS_PER_SEC 299792458
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.
|
|
|
|
|
So, you're saying I should avoid something like this? 
#include <stdio.h>
#include <math.h>
#define ONE 123
#define TWO 456
unsigned concatenate(unsigned x, unsigned y) {
unsigned pow = 10;
while(y >= pow) pow *= 10;
return x * pow + y;
}
int main()
{
printf("Bro %d", (int)concatenate((unsigned)ONE, (unsigned)TWO));
return 0;
}
Jeremy Falcon
|
|
|
|
|
lol. yup. Don't be stupid.
Decades ago, I ran a development group. I had a rule - need a book, buy it and submit an expense form. I had people with 10+ years of development experience freeze up. What, I don't need approval first? Nope, apply common sense and the intelligence I'm paying you for. My welcome intro speech was, "You shall use source control. If you have an issue with this, resign now."
Sadly, your example is code I have seen.
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.
|
|
|
|
|
Extracting magic numbers as named constants is usually a good idea, but orthogonal to the question of whether an underscore separator is helpful or not. It absolutely is helpful if you're dealing with number with mure than 7 or 8 digits. There's a reason we use commas (or periods in continental Europe) to break numbers into groups of 3 digits: it makes it much more obvious when a digit is missing (or erroneously present).
|
|
|
|
|
fair enough. So:
#define SPEED_OF_LIGHT_M_PER_SEC 299,792,458
 I understand your point, but I abhor magic numbers in code even if I know what they mean. I hate magic functions, and don't get me started on hideously complex macros that cannot be debugged.
Hex constants are okay as well, since I can transpose the bits in my head while reading - but I can see the benefit of breaking up long hex strings when you are masking say a 64 bit value.
The ultimate goal is to avoid errors.
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.
|
|
|
|
|
charlieg wrote: The ultimate goal is to avoid errors.
Yep! And I agree with you that magic numbers run counter to that, since there's no visible, verifiable logic within them - you just have to somehow know that it's correct. When I was learning 68000 assembly in the 1990s, I'd read freely-available source code and see moves to and from arbitrary memory addresses for device I/O etc, and wonder how often people accidentally used the wrong address (or one that may only be valid if your machine has exactly 512kb RAM).
Where possible I'll try to push back on the inscrutability a bit, like defining
SECONDS_PER_DAY as
60*60*24 instead of
86400 .
|
|
|
|
|
C# binary literals:
const uint bitmask = 0b0010_0000_0000_1100_0000_0001_0000_1111; The underscores are useful, no?
Software Zen: delete this;
|
|
|
|
|
I'd use hex.
modified 19-Aug-24 11:34am.
|
|
|
|
|
The binary literals are handy for hardware register bits. This is especially true when the documentation is written by a hardware engineer who documents things by bit numbers rather than masks. Defining this sort of thing with hex is okay, but it takes more time when reading.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
