as it is supposed to be guaranteed for NULL pointers, unlike dangling or garbage ones
Guaranteed by whom? I believe the C standard only guarantees undefined behavior. You seem to be suggesting that someone else is guaranteeing specific behavior.
You can just mount some IR LEDs around your plate and render the video images captures useless. Now your plates are visible to cops (so you won't get pulled over for hiding them) and yet cameras will have trouble recording them.
There's a difference between giving out your name willingly to a few people you deal with, and having it automatically associated with your email address for anyone who knows where to look.
Think of it this way: if a criminal asked you for your name, would you give it to them? What if they asked you your address and phone number too?
Some people feel the opposite. I'm happy with the way Firefox does things. If a plugin crashes, I'd rather have it isolated from the main application. I don't want Firefox crashing when a plugin makes a mistake just like I don't want Windows crashing each time an application makes a mistake. We've had virtual memory for a while now, and no one that I know of seems to think we ought to go back to the DOS memory model.
If there is some flaw in Quicktime, and IE doesn't catch it for some reason, Quicktime now has access to the running IE image - which may or may not be as dangerous as what Quicktime has access to stand-alone, but it sure isn't cut-and-dry which one is better.
A little noscript thrown in and my Firefox is more secure than your IE, simply because that malicious site can now DOS your web browsing.
The intelligence of the corporation itself, Microsoft, may not necessarilly correlate to the intelligence of the individual employees...
Said another way, a group of smart people doesn't guarantee a company or a product that is safe, secure, or even considered something that intelligent people should have been able to produce.
Don't confuse the UNIX philosophy with zero features.
Mail + spamfilter = good, if the spam filter is a separate (library | application | plugin). This means that I can use the spamfilter of my choice (or even write one) with the mail program as long as it interfaces correctly.
What is bad is a mail program with an embedded spam filter that you can't rip out and change. This sort of lock-in sucks. Better ways of doing things come along all the time, and if I have to change my mail and spam filter setup because I want to use a new encryption plugin, what's the use?
Now, I'll agree that some languages have better *libraries* for this sort of thing, and the syntax does help *some*, but really, if you had the right libraries in C, it would not be orders of magnitute easier to write, and you may get some speed benefits to boot.
It can be a double-edged sword, too. Aside from a few large applications (Windows, Office, IE), not many applications are running on tons and tons of systems. Having everyone running the same program from the same place means that if a flaw is found and not fixed quickly, *everyone* using that application is vulnerable.
It takes a few minutes to look up what language-keyword-du-jour does in the reference manual.
It takes a lot longer to build up experience and to learn best practices to avoid common problems that don't seem bad when you start programming, but can cause tons of problems down the road.
Sorry, but I disagree with you 100% - I'd rather have someone who needed to pull out a reference to see what goto did then who didn't understand O(n), program design, basic algorithms and data structures, and tons of other things that are language independent.
On the opposite side of the argument, if I had purchased a book for each topic that I have learned over the 5 years I have spent developing code and reading online resources, I would have spent a ridiculous amount of money by now.
Just because you get everything you need from your Mac doesn't mean it can replace Windows for everyone else. It's a crummy world, but some of us still rely on software that is Windows-only. As long as certain vendors still publish Windows-only software and certain business still require their use, many users will be stuck on Windows. C'est la via. No amount of "Mac does everything I need it to" will change that.
That makes a little more sense (so you are saying if I renamed it to *.txt, it wouldn't exploit the flaw in the wmf file handling because it'd open with notepad). However, I assume this works for *.jpg or *.gif because they also open with Windows Picture Viewer by default? Surely if I have *.jpg set to open with something written against a different image-reading library (gimp?) I'd be ok. Just confirming that Windows actually does use the file type on its own to determine which app to open a file with.
Here's the stupid bit - Windows DOES use the file extension for MOST files - if you double-click a.mov, QuickTime may open, but then if you rename it to a.mp3, Winamp will open. So why does Windows need to scan only some files, and screw everything up? People have been trained for the past 6 years that the file extension is the important part on Windows because it mostly is. I wonder why it isn't in this case.
A piece of code can certainly be released under as many licenses as the copyright holder desires. Each blob of code is released with a license that governs how the licensee may copy it. If you get a copy that was released under the GPL, you are free to copy it as the GPL allows. If you get a copy that was released under a commercial license, you are free to copy it as the commercial license allows.
Just because the *same code* exists somewhere else with a different license does *not* mean that the code you posess was also released under that license. Dual licensing is a simple concept that many companies use. To say it doesn't exist is simply mistaken, and to say that the licenses somehow apply to all code bases that are equal is a claim that doesn't make any sense. I'd like to see a judge agree with that argument.
The issue is short-term versus long-term. If the overall goal is short-term results (an instant answer to a question), then asking may be the best bet. I argue that long-term is better though. If I spend a little more time researching the answer, but it means I have in-depth knowledge of everything involved, I'll be able to solve all sorts of related problems 10 times faster. Which is better now?
I wonder how it would work if you used a version control system:
- Generated code on one "vendor branch" (to use CVS parlance) - Made customizations on the main branch - Re-generated updated code on the vendor branch and use
merges to pull in new generated code mixed with your old
changes
Static typing makes it impossible to change the types (not the interfaces) of public apis of libraries and utilities. You can't change everyone's code because it is everywhere. In a dynamically typed language, so long as the interface is the same, the third party code works as expected. In Java or C++, one has to change the version (or work *very* hard to maintain both the old and new interfaces using a variety of tricks).
> A pointer being NULL means that it points to memory address zero.
Wrong - a NULL pointer is a pointer that is assigned the value zero after it has been converted to the pointer type, but the actual bit pattern stored is up to the implementation. It does not have to be all zeroes in memory or registers, and it does not have to refer to address zero.
NULL is defined to zero because when the compiler sees it converted to a pointer type, it does the "right thing" (which doesn't have to mean storing a zero in memory):
void *foo = NULL;
void *foo = 0;
Please read the C standard, sections 6.3.2.3 and 7.17.
Remember folks, $ means the result is a scalar ($scalar, $array[index], $hash{key}) and @ means the result is an array (@array, @array[1..n], @hash{key1,...keyn}).
Slashdot Mirror
[Citation needed]
as it is supposed to be guaranteed for NULL pointers, unlike dangling or garbage ones
Guaranteed by whom? I believe the C standard only guarantees undefined behavior. You seem to be suggesting that someone else is guaranteeing specific behavior.
I hope you never have to grep for anything with shell meta-characters in it...
You can just mount some IR LEDs around your plate and render the video images captures useless. Now your plates are visible to cops (so you won't get pulled over for hiding them) and yet cameras will have trouble recording them.
There's a difference between giving out your name willingly to a few people you deal with, and having it automatically associated with your email address for anyone who knows where to look.
Think of it this way: if a criminal asked you for your name, would you give it to them? What if they asked you your address and phone number too?
Uh, sizeof(long) == 8 on x86-64.
Moral of this story? Know what you are talking about. I'm not saying the code is great, but it's not broken in the way you suggest it is.
-Serp
Some people feel the opposite. I'm happy with the way Firefox does things. If a plugin crashes, I'd rather have it isolated from the main application. I don't want Firefox crashing when a plugin makes a mistake just like I don't want Windows crashing each time an application makes a mistake. We've had virtual memory for a while now, and no one that I know of seems to think we ought to go back to the DOS memory model.
If there is some flaw in Quicktime, and IE doesn't catch it for some reason, Quicktime now has access to the running IE image - which may or may not be as dangerous as what Quicktime has access to stand-alone, but it sure isn't cut-and-dry which one is better.
A little noscript thrown in and my Firefox is more secure than your IE, simply because that malicious site can now DOS your web browsing.
The intelligence of the corporation itself, Microsoft, may not necessarilly correlate to the intelligence of the individual employees...
Said another way, a group of smart people doesn't guarantee a company or a product that is safe, secure, or even considered something that intelligent people should have been able to produce.
Don't confuse the UNIX philosophy with zero features.
Mail + spamfilter = good, if the spam filter is a separate (library | application | plugin). This means that I can use the spamfilter of my choice (or even write one) with the mail program as long as it interfaces correctly.
What is bad is a mail program with an embedded spam filter that you can't rip out and change. This sort of lock-in sucks. Better ways of doing things come along all the time, and if I have to change my mail and spam filter setup because I want to use a new encryption plugin, what's the use?
Would this still be true if you had CGI libraries in C?
#include <cgi.h>
#include <db.h>
int main() {
if (param("file_id")) {
char *cols[] = { "id", "file", NULL };
record *r = db_select(cols, "file_table");
if (r && row_count(r) == 1) {
do_something_with_file_data(row_value(r, "file"));
}
}
}
Now, I'll agree that some languages have better *libraries* for this sort of thing, and the syntax does help *some*, but really, if you had the right libraries in C, it would not be orders of magnitute easier to write, and you may get some speed benefits to boot.
It's not just about the language.
It can be a double-edged sword, too. Aside from a few large applications (Windows, Office, IE), not many applications are running on tons and tons of systems. Having everyone running the same program from the same place means that if a flaw is found and not fixed quickly, *everyone* using that application is vulnerable.
Whatever you say, "drinkypoo".
It takes a few minutes to look up what language-keyword-du-jour does in the reference manual.
It takes a lot longer to build up experience and to learn best practices to avoid common problems that don't seem bad when you start programming, but can cause tons of problems down the road.
Sorry, but I disagree with you 100% - I'd rather have someone who needed to pull out a reference to see what goto did then who didn't understand O(n), program design, basic algorithms and data structures, and tons of other things that are language independent.
On the opposite side of the argument, if I had purchased a book for each topic that I have learned over the 5 years I have spent developing code and reading online resources, I would have spent a ridiculous amount of money by now.
You are already at +5 funny, so I'll just mention here that I got a great laugh out of that one. Thanks!
Just because you get everything you need from your Mac doesn't mean it can replace Windows for everyone else. It's a crummy world, but some of us still rely on software that is Windows-only. As long as certain vendors still publish Windows-only software and certain business still require their use, many users will be stuck on Windows. C'est la via. No amount of "Mac does everything I need it to" will change that.
That makes a little more sense (so you are saying if I renamed it to *.txt, it wouldn't exploit the flaw in the wmf file handling because it'd open with notepad). However, I assume this works for *.jpg or *.gif because they also open with Windows Picture Viewer by default? Surely if I have *.jpg set to open with something written against a different image-reading library (gimp?) I'd be ok. Just confirming that Windows actually does use the file type on its own to determine which app to open a file with.
Here's the stupid bit - Windows DOES use the file extension for MOST files - if you double-click a .mov, QuickTime may open, but then if you rename it to a .mp3, Winamp will open. So why does Windows need to scan only some files, and screw everything up? People have been trained for the past 6 years that the file extension is the important part on Windows because it mostly is. I wonder why it isn't in this case.
Absolutely wrong. (IANAL, STTUMA, IYCRTYTTH)
A piece of code can certainly be released under as many licenses as the copyright holder desires. Each blob of code is released with a license that governs how the licensee may copy it. If you get a copy that was released under the GPL, you are free to copy it as the GPL allows. If you get a copy that was released under a commercial license, you are free to copy it as the commercial license allows.
Just because the *same code* exists somewhere else with a different license does *not* mean that the code you posess was also released under that license. Dual licensing is a simple concept that many companies use. To say it doesn't exist is simply mistaken, and to say that the licenses somehow apply to all code bases that are equal is a claim that doesn't make any sense. I'd like to see a judge agree with that argument.
The issue is short-term versus long-term. If the overall goal is short-term results (an instant answer to a question), then asking may be the best bet. I argue that long-term is better though. If I spend a little more time researching the answer, but it means I have in-depth knowledge of everything involved, I'll be able to solve all sorts of related problems 10 times faster. Which is better now?
I wonder how it would work if you used a version control system:
- Generated code on one "vendor branch" (to use CVS parlance)
- Made customizations on the main branch
- Re-generated updated code on the vendor branch and use
merges to pull in new generated code mixed with your old
changes
Seems the best of both worlds...
Static typing makes it impossible to change the types (not the interfaces) of public apis of libraries and utilities. You can't change everyone's code because it is everywhere. In a dynamically typed language, so long as the interface is the same, the third party code works as expected. In Java or C++, one has to change the version (or work *very* hard to maintain both the old and new interfaces using a variety of tricks).
Any modern distributed version control system?
> A pointer being NULL means that it points to memory address zero.
Wrong - a NULL pointer is a pointer that is assigned the value zero after it has been converted to the pointer type, but the actual bit pattern stored is up to the implementation. It does not have to be all zeroes in memory or registers, and it does not have to refer to address zero.
NULL is defined to zero because when the compiler sees it converted to a pointer type, it does the "right thing" (which doesn't have to mean storing a zero in memory):
void *foo = NULL;
void *foo = 0;
Please read the C standard, sections 6.3.2.3 and 7.17.
> $scalar
... keyn };
...keyn}).
> @array
> %hash
> $array[$index]
> $hash{$key}
> @array[0..$index]
> $#array
Don't forget my favorite:
@hash{ key1, key2,
Remember folks, $ means the result is a scalar ($scalar, $array[index], $hash{key}) and @ means the result is an array (@array, @array[1..n], @hash{key1,