|
Oh that's some exciting crap right there.
|
|
|
|
|
As a side-effect, wouldn't it change 30000 to 0 via 30000 -> 100 -> 0 ?
|
|
|
|
|
What happens then when you try to divide a number by 100?
Just curious ^^
There are two kinds of people in the world: those who separate humankind in two distinct categories, and those who don't.
"I have two hobbies: breasts." DSK
|
|
|
|
|
I guess, if you did try to do that, you would get a 'divide by 0 error'.
Fortunately its only a small project and neither 100 or 300 were ever used as absolute values.
It loaded a int with either 300 or 100 (ie 0 or 1) then later it checked to see if that int was equal to 300 or 100 (ie 0 or 1), so it did work but not a technique I would recommend!
"State acheived after eating too many chocolate-covered coconut bars - bountiful"
Chris C-B
|
|
|
|
|
Me neither
There are two kinds of people in the world: those who separate humankind in two distinct categories, and those who don't.
"I have two hobbies: breasts." DSK
|
|
|
|
|
You forgot
#define true 0
#define false 1
#define maybe true
|
|
|
|
|
Super Lloyd wrote:
#define true 0
#define false 1
#define maybe true || false
FTFY
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Much better way of defining maybe, love it!
|
|
|
|
|
I have to also say that the sense of humor of the comments below the links are not boring at worst and humorous in general.
I would even pay a subscription for this one. Keep it going guys
Make it simple, as simple as possible, but not simpler.
|
|
|
|
|
Agreed, it's the only subscription email that I actually wait for
|
|
|
|
|
Doesn't seem like the best forum.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
I agree with Piebald: try posting it here: http://www.codeproject.com/suggestions.aspx[^] - the hamsters don't get as many "attaboy!"s as they sometimes deserve.
We will remember it is your fault if they do start charging for it though.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
The other day, a customer complained that we - sometimes, but not always - wrote the password of their Hospital Information System (HIS) in our log files in clear text.
Heh? Just another customer telling us bullshit!?
Alahs, right he is.
When our application starts, it logs some general information, e.g. hardware, OS, and Environment Variables.
And in the section of the Environment Variables, sometimes there was an entry like
HIS_PWD=CUSTOMERS_HIS_PASSWORD
The customer found then out that it did not happen when he started our application from the start menu or from its desktop item. It only happened when he started it from the HIS (as the doctors normally do: the HIS can provide us with context information like the patient the doctor is working on).
Well, a process inherits the environment from the process it was started from, including all its Environment Variables.
Do you see what happened here?
It's really a great idea to store the clear-text password as an environment variable, it is absolutely safe there.
|
|
|
|
|
What a great idea! I'm on my way to a meeting - I will drop it in as my idea of safe development and then go to sleep. It will take hours to them to figure out how to eat it...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
It's already wrong that you know the password; should have been a hash. And yes, this is the reason why I oppose linking medical systems.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Ugh. I don't know what software this is, but as far as I can tell, the way they design hospital software is to take the biggest, worst, most horrifying Microsoft Access application you've ever encountered, the sort that happens when someone who wasn't a programmer discovered Access and built a giant, awful system on it and kept at it for a decade, and then model your new medical records application on that.
|
|
|
|
|
Trajan McGill wrote: Microsoft Access
Worse, some use Cache.
You'll never get very far if all you do is follow instructions.
|
|
|
|
|
Hee hee!! I just stored a plain text password in an environment variable this morning! Only temporarily and I have since rebooted.
The password in question is generally protected inside an SSIS parameter file, but I wanted it closer to hand.
P.S. I had to keep it close to hand again today, but instead of doing SET PWD=pa$$w0rd I did pa$$w0rd=PWD for greater security!
You'll never get very far if all you do is follow instructions.
modified 12-Jun-14 18:48pm.
|
|
|
|
|
Working with date and time is known to be a source of beautiful code...
System.DateTime.Now gets the current system time, but you cannot set it. When you want to be able to set the system time, you can try SetSystemTime(ref SYSTEMTIME lpSystemTime) of kernel32.dll ; and there is also a GetSystemTime(ref SYSTEMTIME lpSystemTime) function in that dll.
When I played with these functions, I wrote some tests to make sure I got the conversion from struct SYSTEMTIME to System.DateTime and vice versa right.
[Test]
public void GetSystemTime()
{
DateTime expected = System.DateTime.Now;
DateTime actual = SystemTime.GetSystemTime();
Assert.AreEqual(expected, actual);
}
Well, that always failed: it takes a tick or two to do all the calculations.
I had to update it to allow for some delay:
[Test]
public void GetSystemTime()
{
DateTime expected = System.DateTime.Now;
DateTime actual = SystemTime.GetSystemTime();
int delta = Math.Abs(Convert.ToInt32((actual - expected).Ticks));
int maxDuration = Convert.ToInt32(2 * TimeSpan.TicksPerMillisecond);
Assert.Less(delta, maxDuration);
}
That's 2 Milliseconds for that simple code. But still it fails rather often:
Errors and Failures:
1) Test Failure : XY.SystemTimeTests.GetSystemTime
Expected: less than 20000
But was: 147763
What does the computer do during those almost 15 ms? Is this a test for catching the computer asleep?
|
|
|
|
|
Well, if yours was absolutely the only thing thing that ran on the computer, you might expect this to work consistently. Sadly, in a multi-tasking environment, you cannot guarantee that it's going to be accurate.
|
|
|
|
|
Pete O'Hanlon wrote: cannot guarantee that it's going to be accurate But 15 milliseconds?!
|
|
|
|
|
Yup. You just need a couple of expensive processes running and that would easily be the case.
|
|
|
|
|
There are a few thing you can test, first prevent switching of the CPU core by setting which core to use:
Process.GetCurrentProcess().ProcessorAffinity = new IntPtr(1); Then make sure your process is having more exclusive access to that core:
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.High;
Thread.CurrentThread.Priority = ThreadPriority.Highest;
Just don't blame me if you're messing up your system.
|
|
|
|
|
Well, thanks for the hints...
When I posted it here in the "Weird and Wonderful" - or the "Coding Horror" section as it was called previously - I chose this forum because the outcome of these simple lines of code is so "weird and wonderful".
The little hints won't have much effect: the tests are running in Virtual Machines, there are several more VMs on that host, though almost all of them are "idle" - but you what Windows can do while the machine is idle...
|
|
|
|
|
A well, I don't have a clue how ProcessorAffinity is handled on a VM, but probably wrong.
I just figured that your 15 ms was because of context switching and was simply curious.
|
|
|
|