it should be written in a way that reading it left-to-right makes sense
Come now. If writing "x == y" makes sense, surely writing "y == x" still makes sense, regardless of what x and y are. I'll go out on a limb here and suggest that if "x x" also makes sense.
you cannot disprove the rule "don't kill" by saying that Jack the Ripper has already set a killing precedent
I can disprove the rule "don't kill" by saying that one is occasionally forced to kill in order to survive, no matter ho immoral killing might be. Similarly, one is occasionally forced to read in a right-to-left style in C, therefor you cannot dismiss a construct simply/because/ it is read right-to-left.
But whatever. You can amend your poor analogy by specifying what sort of organism we're killing, to which my response is simple. Comparing programming style to murder is obscene.
I didn't say it was good or bad. I said that it is precedent for stating things "backwards" (to avoid ambiguity, I mean "right-to-left") in C and C++. In particular, I was responding to someone who asserted that code/should/ be read left-to-right; they were demonstrably wrong.
The issue isn't whether or not to use parens, but whether one should code defensively to avoid forgetting them. Parens are necessary either way:
test(CONSTANT == (var = func())) versus
test((var = func()) == CONSTANT)
The the detractors claim that it reads unnaturally. The proponents note that if you accidentally forget the parens
test(CONSTANT == var = func()) is a syntax error, whereas
test(var = func() == CONSTANT) is a logic error.
That often breaks shop coding guidelines which come down from on high. I've considered writing that way myself, and I do so on occasion (when the while condition would be really complicated), but in general I think using the idiomatic style really is the best. Plus, it doesn't step on the toes of structured programming pedants.
Oh, also, "while(1)" flags a warning in GCC, so it *must* be evil.:-P
It's ugly, and it's a hack. Specifically, adding top-level parentheses never changes the meaning of an expression, and programmers shouldn't pretend it does. Though frankly, I should expect no less of people who think that "compiling without errors" is a good thing. It's people who think that way that cheapen casts, eg
int foo = dbl1 * dbl2;
If the conversion is what you want, that doesn't need a cast, thankyouverymuch, no matter what the compiler warns. Adding a cast doesn't "make the code clearer", it "makes it clear the coder doesn't know C".
Besides, a compiler is free to issue a warning that there are starving children in China. Warnings aren't part of C and shouldn't *govern* the way you write code. (Guide maybe, govern no.)
I consider this whole discussion to be about C and the common subset of C and C++. So pointing out that it's in that it's from that subset is not only immaterial, it strengthens my point.
a) The technique is commonly used to avoid duplicate code in a loop with priming read. Duplicate code is worse than a slightly more complicated line, as it doubles the work required by a maintenance programmer.
b) One is a habit, the other is a typo. I've been writing in English for far longer than C++, and I still create typos in English every once in a while. The idea that a smart C++ programmer would never accidentally spell a common idiom wrong is absurd.
A smart C++ programmer is one who recognizes common mistakes (*especially* those which might be made by another programmer on his team who isn't as savvy) and adjusts his coding style to make such mistakes less likely, especially when it costs you nothing (it doesn't even increase the character count).
Two reasons: a) The called function _cannot_ modify the argument. This becomes important to the code surrounding the function call.
T x(...);
foo(x);// did x get changed?
If foo is declared "void foo(T const&)", then you *know* that x has not changed. If instead it's declared as taking a plain reference, you can't know.
b) You can pass const objects or objects with limited lifetimes.
foo(T());// legal if foo takes a T const&, but not a T&
I can logically deduce from your statement that almost all the code you ever see is production code. In which case, I don't think your opinion matters very much.
I consider the backwards comparison to be good C style. It turns a certain broad class of typo from a silent logic error into a compiler error. How many times have you seen
if(x = foo() != -1)
when the programmer meant
if((x = foo()) != -1)
?
If you write your comparisons with the constant first, the compiler will tell you. In particular,
if(-1 != x = foo())
results in a compile-time diagnostic. It's not about "being unfamiliar with C++ syntax". Quite the opposite, someone who writes that way is so familiar with C and C++ syntax that they know how to avoid the common mistakes without batting an eyelash.
Yes and no. You're right that political speech is the type of speech that is considered "most free" in the US justice system. But it's still not completely free (read: unregulated), as the McCain-Feingold Act proves.
However, other forms of speech are awarded certain degrees of protection. Advertisement, for example, is protected but at a lesser degree than political speech.
You are incorrect that shouting "fire" in a crowded theater is unprotected because it is non-political speech. Rather, it is illegal because it presents a/clear and present danger/ to people. Any speech or action which does so is illegal, regardless of the content. This is why, for example, a book arguing for young people to rush into government buildings with armed explosives strapped to their torsos is illegal. Holmes' C&PD test supercedes any freedom that the political speech of revolution might have.
I mostly agree with you, but I also think you're forgetting that a lot of nasty bugs originate from the horrid situation that exists wrt checking for error status in C programs. There's little standardization across libraries as to what constitutes an error indicator. Further, many functions use errno to report errors, and to preserve that mechanism requires throwing re-entrancy out the window.
The worst thing, I think, is that C doesn't provide a good place to implement "clean up" code, like C++ does (in destructors). Often, logic flow is complex enough to require a resource to be released in multiple branches, and it's very hard to verify that it gets released exactly the number of times it should (no more and no less). C++ provides much better mechanisms, but it doesn't make you follow them. Any class that directly allocates more than one object dynamically probably has a memory leak, and how many people follow that guideline? How many people really code for strong exception safety? How many even know what that *means*?
I don't think the problem is that programmers are too lazy but that security really isn't that important. I think the problem is that vulnerabilities don't affect the people who release the code. Make commercial entities that release buggy code financially liable for their products' failures, and we'll see the quality increase astronomically.
Yeah, we have them, but no one uses them for much. Too bad, really, and I'm trying to change that... but I don't have a whole lot of influence, relatively speaking.
I've no idea if you're right about the motives, but 1920x1200 isn't even a 16:9 aspect ratio. And it's called "1080-line" because there are... well, 1080 lines. So it's (1080x16/9)x1080 == 1920x1080. You got the 1920 part right and then fucked up the simple part.
However, the problem does not lie with the parts that think in ones and zeros.
Yes, it does. Currently, when you send an e-mail, *anyone* can read it and *no one* can verify who actually sent it. This is a ones-and-zeroes problem inherent in the e-mail protocol that simply cannot be fixed in a non-technical manner. We have a technical solution available, we're just not using it.
The test had nothing to do with encryption schemes, nor with the type of system that processes the phish...
The particular attack used in the article did not. To pretend that encryption isn't necessary for addressing other types of attacks is reckless idiocy.
It had *everything* to do with releasing information to an unknown entity
We have the capability to ensure every official e-mail is from a known entity (allowing us to ignore the unknown ones). We just don't use it.
Basic COMSEC principles teach that you do not release *any* information unless the recipient has a valid need to know.
That is impossible with plain e-mail. Another problem (and here's where encryption comes in) is that people other than the recipient can read e-mail traffic.
If you can't positively identify the requester, how can you validate the need to know?
You're thinking from the wrong side of the problem. The problem as I see it is not one of sending information to an unauthenticated source but of receiving information from an unauthenticated source.
OPSEC principles teach that it's generally not the one "Golden Goose" piece of information that kills. It's many small pieces that, when put together, tank the plan.
That's exactly the kinds of things I'm worried about. Someone could send an e-mail "from the vice wing commander" saying that one of the gates will be closed for construction the next day. This is a fairly common type of thing that gets sent out by e-mail, so it won't set off warning flags.
The result is a traffic snarl the next morning coming onto base through the other gates. Maybe a key delivery gets delayed or someone is able to slip through due to more strained security at those gates. People show up to work late, maybe something important doesn't get done on time.
Routine information is disseminated via e-mail. But small pieces of routine information can have a large impact in a coordinated attack.
As a post-script, I would like to add that it's not uncommon for folks to e-mail OTHER PEOPLE's social security numbers around in an unencrypted format. The question is not whether the person in the "to" line is supposed to have them. The question is who else is monitoring the network connection? It just so happens that the same solution that provides us with strong authentication also provides us with strong encryption necessary for solving this problem.
Don't send orders via e-mail. Right. So how would you propose doing it instead... over the phone?
An order can be something as simple as "you have to show up for a dental exam on Monday morning". Sure, more sensitive stuff is treated more delicately (like munitions, as mentioned elsethread), but the problem comes in to where the mundane turns into a threat.
Opening an attachment is a pretty mundane activity with possibly disastrous consequences.
Slashdot Mirror
it should be written in a way that reading it left-to-right makes sense
/because/ it is read right-to-left.
Come now. If writing "x == y" makes sense, surely writing "y == x" still makes sense, regardless of what x and y are. I'll go out on a limb here and suggest that if "x x" also makes sense.
you cannot disprove the rule "don't kill" by saying that Jack the Ripper has already set a killing precedent
I can disprove the rule "don't kill" by saying that one is occasionally forced to kill in order to survive, no matter ho immoral killing might be. Similarly, one is occasionally forced to read in a right-to-left style in C, therefor you cannot dismiss a construct simply
But whatever. You can amend your poor analogy by specifying what sort of organism we're killing, to which my response is simple. Comparing programming style to murder is obscene.
I didn't say it was good or bad. I said that it is precedent for stating things "backwards" (to avoid ambiguity, I mean "right-to-left") in C and C++. In particular, I was responding to someone who asserted that code /should/ be read left-to-right; they were demonstrably wrong.
The issue isn't whether or not to use parens, but whether one should code defensively to avoid forgetting them. Parens are necessary either way:
test(CONSTANT == (var = func()))
versus
test((var = func()) == CONSTANT)
The the detractors claim that it reads unnaturally. The proponents note that if you accidentally forget the parens
test(CONSTANT == var = func())
is a syntax error, whereas
test(var = func() == CONSTANT)
is a logic error.
That often breaks shop coding guidelines which come down from on high. I've considered writing that way myself, and I do so on occasion (when the while condition would be really complicated), but in general I think using the idiomatic style really is the best. Plus, it doesn't step on the toes of structured programming pedants.
:-P
Oh, also, "while(1)" flags a warning in GCC, so it *must* be evil.
It's ugly, and it's a hack. Specifically, adding top-level parentheses never changes the meaning of an expression, and programmers shouldn't pretend it does. Though frankly, I should expect no less of people who think that "compiling without errors" is a good thing. It's people who think that way that cheapen casts, eg
int foo = dbl1 * dbl2;
If the conversion is what you want, that doesn't need a cast, thankyouverymuch, no matter what the compiler warns. Adding a cast doesn't "make the code clearer", it "makes it clear the coder doesn't know C".
Besides, a compiler is free to issue a warning that there are starving children in China. Warnings aren't part of C and shouldn't *govern* the way you write code. (Guide maybe, govern no.)
EOF is *defined* to not be a _possible value_ of /any/ character in an input stream. Care to rethink that point?
I consider this whole discussion to be about C and the common subset of C and C++. So pointing out that it's in that it's from that subset is not only immaterial, it strengthens my point.
C and C++ already have precedent for reading things backwards: /* foo is an immutable pointer to an immutable integer */
int const *const foo;
(Ignoring the typo)
More like still perfectly understandable this sentence is.
a) The technique is commonly used to avoid duplicate code in a loop with priming read. Duplicate code is worse than a slightly more complicated line, as it doubles the work required by a maintenance programmer.
b) One is a habit, the other is a typo. I've been writing in English for far longer than C++, and I still create typos in English every once in a while. The idea that a smart C++ programmer would never accidentally spell a common idiom wrong is absurd.
A smart C++ programmer is one who recognizes common mistakes (*especially* those which might be made by another programmer on his team who isn't as savvy) and adjusts his coding style to make such mistakes less likely, especially when it costs you nothing (it doesn't even increase the character count).
Two reasons: // did x get changed?
// legal if foo takes a T const&, but not a T&
a) The called function _cannot_ modify the argument. This becomes important to the code surrounding the function call.
T x(...);
foo(x);
If foo is declared "void foo(T const&)", then you *know* that x has not changed. If instead it's declared as taking a plain reference, you can't know.
b) You can pass const objects or objects with limited lifetimes.
foo(T());
In what way is "EOF != (c = getc(stdin)) less readable that "(c = getc(stdin)) != EOF"?
An if perhaps wasn't the best example. In a while, though, it can avoid duplicate code.
I can logically deduce from your statement that almost all the code you ever see is production code. In which case, I don't think your opinion matters very much.
I consider using ((x=1)) to supress the warning to be even worse than leaving the warning in.
I consider the backwards comparison to be good C style. It turns a certain broad class of typo from a silent logic error into a compiler error. How many times have you seen
if(x = foo() != -1)
when the programmer meant
if((x = foo()) != -1)
?
If you write your comparisons with the constant first, the compiler will tell you. In particular,
if(-1 != x = foo())
results in a compile-time diagnostic. It's not about "being unfamiliar with C++ syntax". Quite the opposite, someone who writes that way is so familiar with C and C++ syntax that they know how to avoid the common mistakes without batting an eyelash.
Yes and no. You're right that political speech is the type of speech that is considered "most free" in the US justice system. But it's still not completely free (read: unregulated), as the McCain-Feingold Act proves.
/clear and present danger/ to people. Any speech or action which does so is illegal, regardless of the content. This is why, for example, a book arguing for young people to rush into government buildings with armed explosives strapped to their torsos is illegal. Holmes' C&PD test supercedes any freedom that the political speech of revolution might have.
However, other forms of speech are awarded certain degrees of protection. Advertisement, for example, is protected but at a lesser degree than political speech.
You are incorrect that shouting "fire" in a crowded theater is unprotected because it is non-political speech. Rather, it is illegal because it presents a
I mostly agree with you, but I also think you're forgetting that a lot of nasty bugs originate from the horrid situation that exists wrt checking for error status in C programs. There's little standardization across libraries as to what constitutes an error indicator. Further, many functions use errno to report errors, and to preserve that mechanism requires throwing re-entrancy out the window.
The worst thing, I think, is that C doesn't provide a good place to implement "clean up" code, like C++ does (in destructors). Often, logic flow is complex enough to require a resource to be released in multiple branches, and it's very hard to verify that it gets released exactly the number of times it should (no more and no less). C++ provides much better mechanisms, but it doesn't make you follow them. Any class that directly allocates more than one object dynamically probably has a memory leak, and how many people follow that guideline? How many people really code for strong exception safety? How many even know what that *means*?
I don't think the problem is that programmers are too lazy but that security really isn't that important. I think the problem is that vulnerabilities don't affect the people who release the code. Make commercial entities that release buggy code financially liable for their products' failures, and we'll see the quality increase astronomically.
Ebay uses ISAPI applications, which is probably written in C or maybe C++, but definitely not Java.
Try Kubuntu. It's just Ubuntu with the KDE packages installed by default instead of the Gnome packages. It's what I run, and I love it.
So, um... Germany's not sovereign?
Yeah, we have them, but no one uses them for much. Too bad, really, and I'm trying to change that... but I don't have a whole lot of influence, relatively speaking.
I've no idea if you're right about the motives, but 1920x1200 isn't even a 16:9 aspect ratio. And it's called "1080-line" because there are... well, 1080 lines. So it's (1080x16/9)x1080 == 1920x1080. You got the 1920 part right and then fucked up the simple part.
However, the problem does not lie with the parts that think in ones and zeros.
Yes, it does. Currently, when you send an e-mail, *anyone* can read it and *no one* can verify who actually sent it. This is a ones-and-zeroes problem inherent in the e-mail protocol that simply cannot be fixed in a non-technical manner. We have a technical solution available, we're just not using it.
The test had nothing to do with encryption schemes, nor with the type of system that processes the phish...
The particular attack used in the article did not. To pretend that encryption isn't necessary for addressing other types of attacks is reckless idiocy.
It had *everything* to do with releasing information to an unknown entity
We have the capability to ensure every official e-mail is from a known entity (allowing us to ignore the unknown ones). We just don't use it.
Basic COMSEC principles teach that you do not release *any* information unless the recipient has a valid need to know.
That is impossible with plain e-mail. Another problem (and here's where encryption comes in) is that people other than the recipient can read e-mail traffic.
If you can't positively identify the requester, how can you validate the need to know?
You're thinking from the wrong side of the problem. The problem as I see it is not one of sending information to an unauthenticated source but of receiving information from an unauthenticated source.
OPSEC principles teach that it's generally not the one "Golden Goose" piece of information that kills. It's many small pieces that, when put together, tank the plan.
That's exactly the kinds of things I'm worried about. Someone could send an e-mail "from the vice wing commander" saying that one of the gates will be closed for construction the next day. This is a fairly common type of thing that gets sent out by e-mail, so it won't set off warning flags.
The result is a traffic snarl the next morning coming onto base through the other gates. Maybe a key delivery gets delayed or someone is able to slip through due to more strained security at those gates. People show up to work late, maybe something important doesn't get done on time.
Routine information is disseminated via e-mail. But small pieces of routine information can have a large impact in a coordinated attack.
As a post-script, I would like to add that it's not uncommon for folks to e-mail OTHER PEOPLE's social security numbers around in an unencrypted format. The question is not whether the person in the "to" line is supposed to have them. The question is who else is monitoring the network connection? It just so happens that the same solution that provides us with strong authentication also provides us with strong encryption necessary for solving this problem.
Don't send orders via e-mail. Right. So how would you propose doing it instead... over the phone?
An order can be something as simple as "you have to show up for a dental exam on Monday morning". Sure, more sensitive stuff is treated more delicately (like munitions, as mentioned elsethread), but the problem comes in to where the mundane turns into a threat.
Opening an attachment is a pretty mundane activity with possibly disastrous consequences.