11–20 of 55 posts
Ridiculous! This is like saying that we shouldn't use parentheses because all C++ programmers should know order of operations! Not only that, but it's probably optimized out by the compiler (and if not, it is a quite insignificant speedup). Better to be safe using sizeof(x) than sorry ...
I actually disagree - while sizeof(char) might always be 1, code isn't just to communicate to a compiler, it's to communicate to another developer . When I see "sizeof(char) * strlen(foo)", I know that they want to allocate 'n' characters and that this is a string buffer: even though as a dev I certainly could've figured out, making code read like you think makes it far faster for others to interpret the intent of th…
"[P]rograms must be written for people to read, and only incidentally for machines to execute." -- Abelson & Sussman, Structure and Interpretation of Computer Programs [1], strangely misquoted by Paul Graham [2]
[1] http://mitpress.mit.edu/sicp/full-text/sicp/book/node3.html
OK, I'm not exactly a professional C programmer, but among those who are: is the use of sizeof(char) here more important than the copy operation that is going to write the terminating null past the area actually malloc'ed? Because that sounds suspiciously like "potentially exploitable" to me.
(2) A terminating null character is placed at the end of strings, not at the end of allocated memory. malloc does not alter the memory before it returns a pointer to it; it is up to the programmer to ensure he is writing in the proper area.
OK, I'm not exactly a professional C programmer, but among those who are: is the use of sizeof(char) here more important than the copy operation that is going to write the terminating null past the area actually malloc'ed? Because that sounds suspiciously like "potentially exploitable" to me.
(1) sizeof is evaluated at compile time, so it would evaluate to (1 * strlen(params->text)), which the compiler would then optimize to just strlen(params->text). So, sizeof() is not exploitable. (2) A terminating null character is placed at the end of strings, not at the end of allocated memory. malloc does not alter the memory before it returns a pointer to it; it is up to the programmer to ensure he is writing in t…
One thing I know -- that person is dangerous. How do I know? I was (perhaps still am) that person. It was a bad habit and I am still trying to get rid it. It is a veiled show of immaturity and arrogance.
OK, I'm not exactly a professional C programmer, but among those who are: is the use of sizeof(char) here more important than the copy operation that is going to write the terminating null past the area actually malloc'ed? Because that sounds suspiciously like "potentially exploitable" to me.
The casting of the malloc() return value is something reasonable people can disagree about (by which I mean nerds can endlessly flame each other about). But here are some points:
* In C++, which Mozilla is written in, it is a compile time error to not cast, so most likely this blog post is just wrong. Conceivably, the file could have been a C file in an otherwise C++ project, but even in that case, it's at least understandable why the cast is there.
* If you have a macro that takes the type as a parameter:
#define alloc(type) ((type *)malloc(sizeof(type)))
* It is true that if you forget to include the stdlib.h header, the cast will silence a useful warning about converting int to pointer.
But it is rather a legacy nowadays. No one should use it.
I actually disagree - while sizeof(char) might always be 1, code isn't just to communicate to a compiler, it's to communicate to another developer . When I see "sizeof(char) * strlen(foo)", I know that they want to allocate 'n' characters and that this is a string buffer: even though as a dev I certainly could've figured out, making code read like you think makes it far faster for others to interpret the intent of th…
This also applies to the bit in the article about coercing return values, which I disagree with. Funnily enough, he mentions that K&R also recommend coercion, even though they have a small note that it's not necessary any more. Still makes for clearer programs.
Many things equal one. I like to specify which one I'm talking when I'm writing code.