There's not much to parameterize when you're sending to whole query as a "variable". :-) Escaping won't help much, either...
Sure it will. You just have to make sure it's done [i]once[/i].
There's not much to parameterize when you're sending to whole query as a "variable". :-) Escaping won't help much, either...
Sure it will. You just have to make sure it's done [i]once[/i].
@PhillS said:
When I read the title of this thread, I thought it was going to be something along the lines of:
"Some person did something really stupid when he / she / it should have known better"
That would be an excellent image caption for a news site to use in many cases...
Why would you expect writing zero bytes to a socket to silently do nothing?
POSIX explicitly tells you not to do this: "If nbyte is zero and the file is not a regular file, the results are unspecified."
http://www.opengroup.org/onlinepubs/000095399/functions/write.html
And you're losing packets because TCP does not preserve message boundaries. There is no requirement that each send operation result in one packet being sent. A single send operation can result in two packets being sent and two send operations can result in one packet being sent. TCP is a byte-stream protocol. (If you mean that the received byte stream did not match the sent byte stream, you did a very poor job of saying so.)
What the Hell does POSIX have to do with Java on BlackBerry?
And why would anyone complain about having [i]their[/i] data being silently dropped unless the received byte stream failed to match the sent byte stream? I think that "the received byte stream did not match the sent byte stream" is fairly obvious from what he wrote. I certainly didn't think he was complaining about TCP/IP packet merging.
A $_GET concatted into an eval string which is supposed to concat it into a SQL string?
Holy crap, what a smorgasborg of injection opportunities! Do I inject SQL, or do I inject PHP? Decisions, decisions...
Meh, female supervisors are pretty much the same as male supervisors, except they generally look better in a skirt.
They generally look better no matter what they're wearing. It's almost universally considered "unprofessional" to point this out to them, though...
On the flip side, if I'm behind with my tax, it doesn't matter when it's done, since I ask for my tax code for the next tax year to be adjusted.
Sweet. Around these parts, if you owe tax, you generally have to pay it in full on April 15.
I wish I had some screenshots, but when I was doing my taxes with a desktop app, I had a little box in the corner with my "refund status". That box went from +$7000 (Sweet!) to -$6000 (Oh crap! Where am I going to come up with $6000?) to settle around +$700 as I filled in the tax form line by line. Shouldn't it be blank if it has no freaking idea what your refund is going to be yet, instead of inducing such spurious emotional highs and lows in its unsuspecting user?
It's too bad that professors like my Software Engineering professor aren't more common.
He handed out a programming assignment. I got the thing to run flawlessly and turned it in. I got it back covered in red with a score of 25%!
I learned quite a bit about writing maintainable code from him...
@Aaron said:
Okay, so since you know how to do it, tell me how to do it. If your automated system receives a measurement of 10 cm from another automated system and 4 inches is a price break point, how do you not fail?
10 cm is less than four inches, so you charge the lower price. 11 cm is more than four inches, so you charge the higher price.
No more precision than that is needed.
Coca-cola comes in two and three liter bottles. One-liter bottled water is common in the US, as are one liter and half-liter empty water bottles.
Code that lets you select units, but doesn't convert automatically to whatever units the shipper is really using, is a definite WTF. Either pass-through whatever units you're really allowing, or convert... don't give the user two choices, one of which leads to an error message!
So I'm at a code review, and I see something like the following:
CustomKey key = ...;
CustomValue value = null;
// Find the value corresponding to the key.
Iterator it = myHashMap.iterator();
while(it.hasNext())
{
Map.Entry entry = it.next();
if ( entry.getKey().equals(key) )
{
value = (CustomValue)entry.getValue();
break;
}
}
So I point to the code and ask "how come you don't just call myHashMap.get(key)?"
The answer I got back was "I tried it like that, and it wasn't returning my value, so I put the loop in and it worked."
WTF? A hashtable lookup isn't working so, instead of trying to figure out why, you defeat the whole purpose of using a hashtable by looping through the damn thing to hunt for your key?
As it turned out, the hashtable lookup wasn't working because MyCustomKey went something like this:
class MyCustomKey
{
public boolean equals(Object other)
{
// Compare the fields...
}
// Some other methods, none of which is getHashCode
}