|
I'm researching UK Universities' Contact Directories for work and think I just destroyed the University of Manchester's search site by searching for "*" in the contact directory. It churned for a while and now won't respond at all. Nevermind that it looks really vulnerable for SQL injection too.
|
# ? Apr 29, 2009 10:18 |
|
|
# ? May 16, 2024 17:37 |
|
How about "Coding annoyances: post the code that bothers you" I see numbers needlessly defined in hex all the time. E.g. int numberOfApples = 0x05; What's wrong with a simple int numberOfApples = 5;
|
# ? Apr 29, 2009 12:27 |
|
Wheany posted:How about "Coding annoyances: post the code that bothers you" As long as it's a number under 16 it doesn't hurt readability very much. Though I would be pretty pissed if I saw "int A_MILLION = 0xF4240;" without a very good reason.
|
# ? Apr 29, 2009 18:51 |
|
Wheany posted:How about "Coding annoyances: post the code that bothers you" 'Cause what they're really typing is this: int numberOfApples = 0x05;
|
# ? Apr 29, 2009 19:18 |
|
The Prefuse (link) visualization library for Java is actually pretty neat. In its current setup, however, you end up registering data using a String identifier, indexing those data via that same identifier. Sounds pretty standard. Every field of that data is given a String name, too. Data gets nested in more data. Eventually, you end up with monstrous amounts of string constants code:
code:
|
# ? May 1, 2009 18:13 |
|
From the iPhone dev thread:Unparagoned posted:
|
# ? May 1, 2009 22:11 |
|
We employed a guy who was trying to learn Python. The code we had him working on was all text manipulation. We showed him the magic of python's printf-esque print statement and let him go. He would do things like this: code:
note: what he wrote isn't technically wrong but .. why not just do: "print a" ?
|
# ? May 4, 2009 03:02 |
|
spankweasel posted:printf If you've been doing c for long enough you start to get certain habits.
|
# ? May 4, 2009 03:08 |
|
fritz posted:If you've been doing c for long enough you start to get certain habits. If you've been doing C for long enough you start to write code with format string vulnerabilities in it? twodot fucked around with this message at 05:52 on May 5, 2009 |
# ? May 4, 2009 16:15 |
|
twodot posted:If you've been doing C for long enough you start to write code with format string vulnerabilities in it? Congrats, you don't know printf.
|
# ? May 4, 2009 16:31 |
|
twodot posted:If you've been doing C for long enough you start to write code with format string vulnerabilities in it? Wait what?
|
# ? May 4, 2009 16:36 |
|
If print were actually printf, then print a would indeed have format-string vulnerabilities. But it isn't; the printf-like thing in that code is python's % operator, which is essentially sprintf. EDIT: VV I think my reading is correct and twodot just doesn't understand the python code, but I will sharpen the idiot hat nonetheless. rjmccall fucked around with this message at 18:31 on May 4, 2009 |
# ? May 4, 2009 18:23 |
|
rjmccall posted:If print were actually printf, then print a would indeed have format-string vulnerabilities. But it isn't; the printf-like thing in that code is python's % operator, which is essentially sprintf. I think he is trying to assert that, in C, printf("%s",s); has a format-string vulnerability. Which is false.
|
# ? May 4, 2009 18:25 |
|
scanf("%s",f);printf(f); certainly has a format string vulnerability though. But in that context, no, none.Unparagon posted:pointer mishaps and SQL abuse
|
# ? May 4, 2009 22:01 |
|
The fact that you are printf'ing a string stored in a variable and not a literal means that the value could change in the future without even looking at or knowing about the existence of the printf in question. If it changes to a string which contains a %, it introduces undefined behaviour that could have easily been prevented. It even specifically states this in K&R (page 155). On the other hand, there's no point in doing it in the python code since there's no vulnerability to start with.
|
# ? May 4, 2009 23:22 |
|
necrobobsledder posted:I am never downloading an app from the app store again. OH GOD Unparagon's poorly named variables are going to magically corrupt all of your data and send your SSN to North Korea.
|
# ? May 5, 2009 04:05 |
|
Avenging Dentist posted:I think he is trying to assert that, in C, printf("%s",s); has a format-string vulnerability. Which is false.
|
# ? May 5, 2009 05:51 |
|
Just now found a classic: code:
|
# ? May 8, 2009 23:34 |
|
Presto posted:Just now found a classic: Well hey, at least it isn't code:
|
# ? May 9, 2009 01:15 |
|
Volte posted:The fact that you are printf'ing a string stored in a variable and not a literal means that the value could change in the future without even looking at or knowing about the existence of the printf in question. If it changes to a string which contains a %, it introduces undefined behaviour that could have easily been prevented. It even specifically states this in K&R (page 155). But nobody did that. The only person that did was in the example above you. The Python code is 100% valid and safe, because the formatting part is a literal.
|
# ? May 9, 2009 02:47 |
|
Ran into this at work in a college's code. It took me a while to figure out what this was actually doing thanks to a very oddly overloaded operator(*) plus incredible terseness:code:
Chuu fucked around with this message at 11:04 on May 9, 2009 |
# ? May 9, 2009 10:54 |
|
ymgve posted:But nobody did that. The only person that did was in the example above you. The Python code is 100% valid and safe, because the formatting part is a literal. That was just an explanation how to possibly get it wrong in C, because defending against that is what the dude did in Python. The joke is not that the python guy did something unsafe, it is that he used formatting operations to protect against a danger that does not even come with Python's print function.
|
# ? May 9, 2009 13:07 |
|
Chuu posted:Ran into this at work in a college's code. It took me a while to figure out what this was actually doing thanks to a very oddly overloaded operator(*) plus incredible terseness: What's going on here? What did he make his operators do?
|
# ? May 10, 2009 15:15 |
|
Steve French posted:Well hey, at least it isn't Both statements have undefined behavior unless those are overloaded operators. Post or pre-increment doesn't matter, assuming C or C++, that is.
|
# ? May 10, 2009 17:36 |
|
That Turkey Story posted:Both statements have undefined behavior unless those are overloaded operators. Post or pre-increment doesn't matter, assuming C or C++, that is. I get why post/pre doesn't matter, but why is the overall behaviour undefined? To my (admittedly untrained) eyes, assuming i and j are numbers, that line increments i by one then ensures it didn't just grow larger than j, wrapping around to 0 if so. Did I get that wrong?
|
# ? May 10, 2009 20:03 |
|
It just is undefined, since both the assignment itself and the ++ modify i, which is illegal because there is no sequence point inbetween.
|
# ? May 10, 2009 20:25 |
|
pokeyman posted:I get why post/pre doesn't matter, but why is the overall behaviour undefined? To my (admittedly untrained) eyes, assuming i and j are numbers, that line increments i by one then ensures it didn't just grow larger than j, wrapping around to 0 if so. Did I get that wrong? With a few exceptions, the order of execution of side-effects within expressions is not specified in C/C++, so it is permitted for the increment to logically happen after the assignment. The major exceptions are the comma operator (left before right), the ternary operator (condition before chosen expression), and call-like operations (function and arguments (in any order) before call). (n.b. this list is not guaranteed to be exhaustive)
|
# ? May 10, 2009 20:30 |
|
no this is not "who knows what the value of i is going to be afterwards", this is literally undefined behaviour you do not have to argue why it is because it just says in the standard not to do that poo poo
|
# ? May 10, 2009 20:32 |
|
Vanadium posted:no this is not "who knows what the value of i is going to be afterwards", this is literally undefined behaviour oh poo poo guys demons just flew out of my nose what do i do
|
# ? May 10, 2009 20:38 |
|
I agree with you? But we can argue if you like, I am not picky. I just thought people might care why x = 7, ++x was well-defined and this wasn't.
|
# ? May 10, 2009 21:42 |
|
rjmccall posted:With a few exceptions, the order of execution of side-effects within expressions is not specified in C/C++, so it is permitted for the increment to logically happen after the assignment. The major exceptions are the comma operator (left before right), the ternary operator (condition before chosen expression), and call-like operations (function and arguments (in any order) before call). (n.b. this list is not guaranteed to be exhaustive) Thanks for the explanation. Vanadium posted:no this is not "who knows what the value of i is going to be afterwards", this is literally undefined behaviour Calm down champ, nobody's trying to stir up poo poo but you. "Literally undefined behaviour" and "not specified in C/C++" mean the same thing to me, and either way I got the point: the result of this expression is not defined, and thus a coding horror. I didn't know it was undefined in C/C++ so I didn't see why it was a horror. Following along? Great.
|
# ? May 11, 2009 00:03 |
|
Patashu posted:What's going on here? What did he make his operators do? i is a pointer to a custom iterator class. First operator is deference to get the actual iterator object. Second is to get the object the iterator is pointing to, which is NULL if it's out of range. ++ overloaded to increment the iterator's internal reference. It's a pretty natural way to write the code if you know what's going on but it makes people who maintain your code want to stab you. I am still a neophyte to C++ but seeing "++*x" is also a little offputting at first glance. (I guess * isn't that oddly overloaded, but seriously, if you are going to write an iterator class, making it behave differently than STL iterators is a bad thing.) Chuu fucked around with this message at 04:04 on May 11, 2009 |
# ? May 11, 2009 03:59 |
|
necrobobsledder posted:
I admit my pointer understanding is a bit limited, could you explain the pointer mishaps.(I didn't even know I was using pointers, except for maybe for the nsstring). Also what about the sql abuse?
|
# ? May 11, 2009 10:14 |
|
Chuu posted:(I guess * isn't that oddly overloaded, but seriously, if you are going to write an iterator class, making it behave differently than STL iterators is a bad thing.) If it's different to STL iterators then it is wrong. There are well defined behaviors people are going to expect if it looks like an iterator, if these are violated anything could happen. This is almost as bad as overloading && to delete it's arguments.
|
# ? May 11, 2009 13:22 |
|
Zombywuf posted:This is almost as bad as overloading && to delete it's arguments. Where do people come up with this insanity? Is it really that hard to code in a sane and understandable manner?
|
# ? May 11, 2009 13:56 |
|
code:
|
# ? May 11, 2009 15:26 |
|
So, what's it trying to do? It's too verbose...
|
# ? May 11, 2009 15:33 |
|
Seth Turtle posted:Where do people come up with this insanity? Is it really that hard to code in a sane and understandable manner? Given that people make functions called doit or run in Java, yes.
|
# ? May 11, 2009 17:12 |
|
Triple Tech posted:So, what's it trying to do? It's too verbose... 1. There should be comments on what it actually does. There is a map/grid, with an array with a single index. The function basically just finds all the squares next to a given square and performs a couple of functions on it. It can be replaced with a couple of for loops and if statments.
|
# ? May 11, 2009 17:23 |
|
|
# ? May 16, 2024 17:37 |
|
Unparagoned posted:1. There should be comments on what it actually does. Not to mention the use of NSArray to store integers makes me want to scratch my eyes out, since it means you have to wrap them in NSNumbers and make everything even more verbose by boxing/unboxing them. I refuse to actually look too closely at the code, but there's the potential for NSIndexSet to be a better fit here for a collection of integers.
|
# ? May 11, 2009 19:34 |