Linked by MOS6510 on Thu 10th Jan 2013 23:25 UTC
Thread beginning with comment 548431
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: C == Security Exploits by design
by saso on Sat 12th Jan 2013 01:04
in reply to "RE[4]: C == Security Exploits by design"
I didn't say they [Algol 60, PL/I] were top quality, only better than C.
And here we go with the blanket statements again, asserted without proof.
According to epoch documentation many companies did license languages on those days.
Yep, they did, but Bell Labs obviously didn't feel the needed to.
I only care about the Computer Science definition and C does not offer that.
http://en.wikipedia.org/wiki/Modular_programming
http://en.wikipedia.org/wiki/Modular_programming
Oh really? Then I quote from the linked Wikipedia page you linked:
Modules are typically incorporated into the program through interfaces. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface.
Since 1989 C has had rigorous support for this kind of compartmentalization (.h interface files, .c implementation files) and virtually every single project I've ever laid eyes on has used it. Of course it's rudimentary, but there are higher constructs on top which provide most, if not all of the features you would expect.
Usually more features tend to improve programmer's productivity.
By that logic, more controls on a car means better/safer/more productive driving. In actuality, Einstein's famous (possibly apocryphal) quote captures reality much better: "Everything should be made as simple as possible, but not simpler."
Well, actually English grammar was originally simplified thanks to the Normand occupation:
http://geoffboxell.tripod.com/words.htm
http://geoffboxell.tripod.com/words.htm
I said 'often times', not 'always'. Obviously at times languages expand in complexity to incorporate new necessary concepts and there's nothing wrong with that.
I have seen enough code like str[index] = NULL to make that statement. Not everyone writes str[index] = '\0', specially the ones that like to turn off warnings.
These programmers deserve a kick in the nuts for the above construct. This will produce warnings (implicit cast of void * to char) and is indicative of the fact that the author doesn't actually understand how computers work. I personally prefer str[index] = 0; Same meaning, less text, clearer.
Too many scars of off-shoring projects.
Ah well, if you buy cheap product, don't be surprised when it turns out to be shoddy. I have the same experience with offshore. Having a "safer" language means they will just provide you with dumber code monkeys.
I imagine any security expert would agree, but I might be wrong.
Security is not a simple yes/no game - the most secure computer is one that is off. It's all about finding middle ground. Some code warrants your approach, some doesn't. Making blanket statements, however, will guarantee that at times you will throw the baby out with the bathwater.
Should I now give a CS lecture about classes of static typing?
If you can't support your claims, don't make them. But before you dig into it, take a look at: https://en.wikipedia.org/wiki/Strong_typing#Variation_across_program...
Note that some of these definitions are contradictory, others are merely orthogonal, and still others are special cases (with additional constraints) of other, more "liberal" (less strong) definitions. Because of the wide divergence among these definitions, it is possible to defend claims about most programming languages that they are either strongly or weakly typed.
So any statements you present will most likely just express your personal opinions on the matter. Oh and I have an MS in CS, so I've heard them before (including "C sux", "C rocks" and "Let's code everything in Prolog").
I am well aware of that Wikipedia page.
There many more C vendors than what Wikipedia lists and many customers don't let you choose the compiler to use.
There many more C vendors than what Wikipedia lists and many customers don't let you choose the compiler to use.
If your hands our bound by your customer, then I suspect you have other problems in your project, not just with the language.
Well, have you ever done a 300+ developers multi-site project?
I was talking about things like X.org, KDE, the Linux kernel, Illumos, etc. These are humongous code bases with tons of external dependencies and when doing a project that uses them, I don't have the time to go through each and every piece and fix a maintainer's bad assumptions about build environments, often times just to test a solution. That's why I said -Werror is good for development, bad for distribution.
To expert C coders, you mean.
Agree, it's probably news to you. GCC, for instance, supports -W and -Wall, both of which together activate lots of helpful static code analysis in GCC (unused variables, weird casts, automatic sign extensions, etc.).
Just stating my opinion.
No problem there - when you clearly state something as personal opinion, I have no problem. It's only the assertions and blanket statements that make my blood boil. We could probably understand each other over a beer much better than over the Intertubes.
RE[6]: C == Security Exploits by design
by moondevil on Sat 12th Jan 2013 09:25
in reply to "RE[5]: C == Security Exploits by design"
"I didn't say they [Algol 60, PL/I] were top quality, only better than C.
And here we go with the blanket statements again, asserted without proof. "
Sure asserted without proof.
It is based on my understanding what a better language is, by looking at the epoch documentation that I had access to, during my degree.
For me, a languages that allow the developer to focus on the task at hand are always better than those that require them to manipulate every little detail.
Usually that detail manipulation is only required in a very small percentage of the code base.
In the end I guess it is a matter of discussing ice cream brands.
If you can't support your claims, don't make them. But before you dig into it, take a look at: https://en.wikipedia.org/wiki/Strong_typing#Variation_across_program.....
So any statements you present will most likely just express your personal opinions on the matter. Oh and I have an MS in CS, so I've heard them before (including "C sux", "C rocks" and "Let's code everything in Prolog").
So any statements you present will most likely just express your personal opinions on the matter. Oh and I have an MS in CS, so I've heard them before (including "C sux", "C rocks" and "Let's code everything in Prolog").
And I one with focus in compiler design and distributed computing.
Usually static languages with strong typing don't allow for implicit conversion among types, forcing the developers to cast in such cases.
Overflow and underflow are also considered errors, instead of being undefined like in C.
Pointers and arrays are also not compatible, unless you take the base address of the array.
Enumerations are their own type and do not convert implicitly to numeric values, like in C.
Since 1989 C has had rigorous support for this kind of compartmentalization (.h interface files, .c implementation files) and virtually every single project I've ever laid eyes on has used it. Of course it's rudimentary, but there are higher constructs on top which provide most, if not all of the features you would expect.
Well let me quote another section of the article.
Languages that formally support the module concept include Ada, Algol, BlitzMax, COBOL, Component Pascal, D, Erlang, F, Fortran, Haskell, IBM/360 Assembler, IBM RPG, Java (packages are considered modules in the JLS), MATLAB, ML, Modula-2, Modula-3, Morpho, Oberon, NEWP, OCaml, Pascal, Perl, PL/I, Python, and Ruby.[citation needed] The IBM System i also uses Modules in CL, COBOL, and RPG when programming in the Integrated Language Environment (ILE). Modular programming can be performed even where the programming language lacks explicit syntactic features to support named modules.
Somehow I don't see C listed as a language that supports modules.
Sure you can do modular programming by separate compilation, but that is not the same as having language support for it. I have done it for years.
For example, in some languages that support modules, the compiler has builtin linker and is also able to check dependencies automatically and only compile required modules.
The types are also cross-checked across modules. In C,
some linkers don't complain if the extern definition and the real one don't match.
If your hands our bound by your customer, then I suspect you have other problems in your project, not just with the language.
In the Fortune 500 corporate world, usually there isn't too much developer freedom.
"To expert C coders, you mean.
Agree, it's probably news to you. GCC, for instance, supports -W and -Wall, both of which together activate lots of helpful static code analysis in GCC (unused variables, weird casts, automatic sign extensions, etc.). "
I am aware of it.
As I answered in another thread, I have done C programming between 1992 and 2001, with multiple compilers and operating systems.
Since then, most of the projects I work on rely on another languages.
"Just stating my opinion.
No problem there - when you clearly state something as personal opinion, I have no problem. It's only the assertions and blanket statements that make my blood boil. We could probably understand each other over a beer much better than over the Intertubes. " [/q]
Yeah, it would be surely a better way to discuss this.





Member since:
2005-07-08
Because, if you had even read the few Wikipedia pages on C, you'd know that C derives from Algol 60. The line is roughly this: Algol -> CPL -> BCPL -> B -> C. Each of those steps had its reasons and I'm not going to list them here. Your attempt to portrait the designers of C as conceited merely shows that you carry a personal grudge that *your* language of choice didn't become ubiquitous (I presume it's Pascal, since you mentioned it so fondly - I've met a few FreePascal enthusiasts and they are argue quite similarly to you). "
Well yes.
I never used FreePascal though.
I am old enough to have used C and Pascal when the first compilers were being made available in ZX Spectrums.
I didn't say they were top quality, only better than C.
According to epoch documentation many companies did license languages on those days.
Either they are modules (albeit in primitive form), or they aren't. You've managed to contradict yourself in a single sentence - good job. It's also sweet that you try to declare your definition of a module as authoritative. Have you ever considered that perhaps not everybody agrees with your definition? "
I only care about the Computer Science definition and C does not offer that.
http://en.wikipedia.org/wiki/Modular_programming
Wow, FreePascal on Windows user, I presume. "
Never used Free Pascal.
Windows is just another operating system among many.
Why do you think that "more features" = "progress"?
Usually more features tend to improve programmer's productivity.
Well, actually English grammar was originally simplified thanks to the Normand occupation:
http://geoffboxell.tripod.com/words.htm
NULL is actually a macro typically defined to ((void*)0), but I understand if your case-insensitive eyes don't see the difference.
Offhand remarks get offhand responses. "
I have seen enough code like str[index] = NULL to make that statement.
Not everyone writes str[index] = '\0', specially the ones that like to turn off warnings.
Too many scars of off-shoring projects.
Yes, your personal opinion on the matter is really insightful. "
I imagine any security expert would agree, but I might be wrong.
This is a pretty slimy tactic to try and shift the burden of proof onto me. I'd now have to provide an extensive list to show that other static type checking languages out there have more relaxed rules, never mind even how one would qualify what "weak" and "strong" static type checking means. I don't play this way. You claimed C type checking is weak, it's yours to prove, not mine to disprove. "
Should I now give a CS lecture about classes of static typing?
Oh my, is support really that bad?! Oh wait, you just pulled that one straight out of your behind:
https://en.wikipedia.org/wiki/C99#Implementations "
I am well aware of that Wikipedia page.
There many more C vendors than what Wikipedia lists and many customers don't let you choose the compiler to use.
That assertion was because many think that gcc and clang are the only compilers that matter.
Obviously you've never built any bigger product somebody else coded from source, have you? "
Well, have you ever done a 300+ developers multi-site project?
Other platforms have other static analyzers. But UNIX has been the platform of birth for C, so I just wanted to show you that what you say here is not news to native C coders. "
To expert C coders, you mean.
So you think forcing people is the proper approach? Have you ever considered that some people might not like that? Of course not, you are beyond error (see "arrays shouldn't be treated as pointers" comment above). "
No, I am just a meaningless person in this world.
Just stating my opinion.
Except that ISO Extended Pascal didn't exist when Kernighan and Ritchie designed C, so your citation of Ritchie to support your case misses the chronological order in which these languages appeared. According to Wikipedia, the first Pascal compiler in the US was written for the PDP-11, much later than UNIX appeared and probably even after C. "
Point taken.
I never said so, but it's history is intertwined with C, so knowing about UNIX gives you a good idea how C developed. "
Agreed.