back to article Today's bugs have BRANDS? Be still my bleeding heart [logo]

In view of the ongoing security-holed far-too-open source situation, I have decided to convene an emergency meeting of ERCOCC, the El Reg Committee Of Competent Coders, to review what has occurred and how we should go forward. No time for chitter-chattering. Settle down everybody, and juice up the PowerPoint projector please …

COMMENTS

This topic is closed for new posts.

Re: Note to all C programmers

"surely it's a rare device these days that needs the raw minimalism of C."

I agree with many of the comments that you've made so far, but I'm afraid that this is simply wrong. I am still writing performance critical code for devices that use 64 MHz CPUs with 16 MB of RAM. In the embedded world, that is Maserati-style resources but still the additional memory overhead and performance reduction of C++ rules it out in favour of C. The vast majority of embedded work will be done on slower processors with an order of magnitude less RAM so C will be required for many years to come.

4
0
Silver badge

@mccp Re: Note to all C programmers

Well, there's also Embedded C++ - it removes the performance-hurting parts of the language (dynamic allocation, virtual functions, exceptions...), and leaves you with a "C with better data structures and naming". No virtual functions, no polymorphism, but you've still got constructors and destructors, and RAII still works, and the code will be as fast and as small as C.

C++11 also has a whole slew of features that make it very useful for low-level, embedded and performance-critical systems; stuff like constructing objects over existing memory (i.e., no allocation overhead), and elimination of class/structure copying allows you to write less code, but keep the performance. "Constant Expressions" are another great idea (that could go into C too), where you get the compiler to calculate invariants and replace them with constants rather than waste your precious CPU cycles doing it; the advantage over a macro or #define is that if the situation changes to require a runtime-calculation of the expression, the code change is as small as the removal of a single keyword.

3
2

Re: Note to all C programmers

"In the embedded world, that is Maserati-style resources but still the additional memory overhead and performance reduction of C++ rules it out in favour of C."

I'm not so sure, as a 20+ embedded programmer, I've used C++ right down to in a few K of RAM and a dozen or two kilobytes of ROM/Flash. Albeit different memory management, but definately C++ (not C in C++).

For very tiny platforms (e.g <1K of RAM) then C or assembler, maybe - but you can do the C in a C++ compiler and get some C++ strictness.

1
1
Silver badge

Re: Note to all C programmers

> The company I used to work for took on a new programmer who removed every possible bra and ket from his code

A problem that could have been fixed with a judicious application of tar and feathers. Braces are for everywhere, not just for holding up your trousers, and no tabs, anywhere, not ever. Everything else I'm flexible on but not those. And if you're about to ask about the tabs, can I politely request you shove your shiny IDE up your arse while the rest of us fire up a shell and get on with some real work.

2
0
Coat

Re: A problem that could have been fixed

I'm familiar with tar, but "man -k feathers" returns no results.

7
0
Silver badge

Re: Note to all C programmers

> And if you're about to ask about the tabs

You simply tell them set their IDE to convert a press of the tab key into x white spaces. There everyone happy.

0
0
Silver badge

Re: Note to all C programmers

Also C programmers are in denial, or they would not be C programmers.

This is totally obvious from the comments and votes.

Makes me despair about the chance of better SW. Yes, C is flexible. It's also like using nitroglycerine to dig the flowerbed.

1
4
Silver badge

Re: Note to all C programmers

I am still writing performance critical code for devices that use 64 MHz CPUs with 16 MB of RAM. In the embedded world, that is Maserati-style resources but still the additional memory overhead and performance reduction of C++ rules it out in favour of C

And yet Turbo C++ was initially released for MSDOS and could target 8086 processors. If I could write software in C++ when I barely had 500kB of RAM to use, less than 64kB of stack and pitiful 8086 how come you can't with all that hardware?

2
1

Re: Note to all C programmers

Braces around single lines make the code really ugly and sometimes less readable. In this particular case, they should be avoided.

0
5

Re: @mccp Note to all C programmers

Correct me if I'm wrong, but you could construct and destruct objects over existing memory in older C++. You had also support for that in std. And constexprs don't do much either, compilers were able to optimize that already; constexpr is for the programmer to _enforce_ him to write code that can be actually optimized at compile time. If he writes something that can't be optimized, the compiler won't just switch to 'do it at runtime' mode, but will yell.

0
0

Re: Note to all C programmers

<quote>the additional memory overhead and performance reduction of C++ rules it out in favour of C.</quote>

What memory overhead and performance reduction would that be, pray tell?

Bjarne went to a lot of trouble to make sure that you don't pay for features unless you use them. So you can get all the benefits of - e.g, - moderate type safety, exceptions and RAII without paying the (small) runtime overhead of virtual functions.

0
2

Re: Note to all C programmers

Braces around single lines make the code really ugly and sometimes less readable. In this particular case, they should be avoided.

No, no and a million times no. If you want to get rid of braces, go and write Python.

2
0
Silver badge

GOTO be GONE?

> Because nobody uses goto in real code, right

Actually EVERYBODY uses goto's - they just turn a blind eye to it.

Look under the safety-blanky of your favourite compiler and you'll see the assembler which is produced is absolutely infested with goto statements.

I think what is meant is that nobody (again, incorrect) writes GOTO statements in their source code. The problem isn't actually the goto statement: which is so useful there would be no practical software without it. No: the issue is partly mere fashion/snobbery, but mostly the problem of documenting it: the lack of a complimentary, high-level, COMEFROM statement to tell the poor little debuggerer how the program-counter ended up at a certain point in the code.

Though if you debug your stuff with a logic analyser, or trace/emulator, working out where the GOTO came from is generally quite easy. There's nothing about a GOTO to sneer at or to be scared of.

3
10
Silver badge

Re: GOTO be GONE?

There are occasions where a goto might be the most elegant option (e.g. breaking out of multiple nested loops) but the problem I see is when you look at a goto target, just how did I get there?

0
0
Silver badge
Meh

Re: GOTO be GONE?

but mostly the problem of documenting it

But in the real world documentation frequently ends up out of date if it exists at all. The problem with documentation is that the compiler doesn't get to see it or in the case of comments doesn't act on it. Documentation in code or out can say what it wants but it means diddly-squat as far as the actual generated code.

Logic analysers are good but that's still catching the problem after the mistake was made.

Good coding style and use of proven idioms help avoid the mistake being created in the first place. So yes do all three things but don't dismiss good style as unimportant. It's the first place where mistakes can be addressed and the earlier you address a mistake the cheaper it is to fix. Good style has the potential to prevent mistakes in the first place ;)

1
0
Silver badge

Re: GOTO be GONE?

GOTO statement still have some relevance, but in general in higher languages it should be avoided. An algorithm can usually be written in a more structured, clearer manner where a GOTO statement is no longer required.

I would much prefer to see a GOTO statement than a "BREAK <n>" statement where you have to work through the layers of conditionals and loops to work out how many levels are actually being skipped out of in the parameterised version of the BREAK statement. "COMEFROM" would be clearer :)

Lower level, of course, you will see the exact functionality of GOTO everywhere because it is a fundamental control structure - JUMP and (conditional) BRANCH operators are key to assembly language processes. It's just that with progress we've abstracted their use away to reduce the number of problems they cause.

1
0
Silver badge

Re: GOTO be GONE?

You seem to misunderstand why we have high level languages. It's deliberately to hide the CPU assembler / machine instructions. Every CPU I can think of uses Goto. Some like low end PIC only have stack for saving address etc due to Interrupt, they even use Gotos with parameters in an address to reuse code to simulate a function or procedure.

3
0

Re: GOTO be GONE?

To be pedantic all assembler have some thought of Jmp statement which GOTO's, If and loops compile down to.

However assembler has a load of instruction which I wouldn't expect to see in well written high level code because the purpose of such languages is to hide complexity not to praise it

1
0

Re: GOTO be GONE?

In Structured Programming (without GOTOs) the idea was that each block had one entry and one exit to make the code easier to debug, etc.

An idea which came in with Java, is you write the code as if there are no errors, so as not to hide the algorithm with error handling, then catch all the errors/exceptions at the end. The garbage-collection would clean up any unreferenced resources.

The 'IF' statement causes problems, especially a sequence of if-them-else statements which hides what is going on and the switch-case statement(s) can easily become unwieldy. However the logical and && and logical or || can be a camouflaged if-then-else statement or conditional branch or goto. The and && loosely the then part and the or || the else part. The 'and' && becomes; if the left side is false, return false, if the left side is true, then return the right side. The 'or' || becomes; if the left side is true, return true, else return the right side.

0
0

This post has been deleted by its author

Silver badge

Ta, Stob.

Some of us remember why Dr. Dobbs Journal existed in dead-tree form. Keep doing your thing, my friend. Hopefully at least one kiddie will grok.

GOTO is an an anathema when it comes to RealWorld[tm] code.

8
0
jai

A new Stob article? oh joy!

This is officially my favourite Thursday of the month so far :)

3
0
Silver badge
Mushroom

Once again

Excellent Ms Stob

I was shouting in an enraged fashion the other day at the wall :

Why are the Security Mailing lists full of the same old Array Bounds Violations, lack of input sanitising and cross site scripting vulnerabilities?! (or is it !?)

Why nearly 30 years after C++ coming to DOS and every other platform from AT&T UNIX are people still using C?

I know it's too much to expect people to use Modula-2. But everyone has had time to learn how to program in C++ and port it to everything.

Why is the GUI and Web pages getting prettier but tools to develop Web Sites are like 1970s? Code if anything seems poorer than 1980s.

Verity should look at the unholy mix for ONE web page the source files mix of Java, Javascript, PHP, SQL, CSS, HTML, Oracle SQL-PL, and BOTH kinds of Adobe's Cold Fusion (Java style and XML style), often examples or fragments of all in the same source file.

You have to run it on the server and view with several browsers to even discover if it looks like you intended. Whole chunks of "code" may even be missing without warning. You have to "run" it to get ANY checking or diagnostics.

Don't let me get started on "Frameworks" for PHP etc.

2
4
Anonymous Coward

Re: Once again

There was someone earlier this week suggesting that joining together lots of small applications was a better way of scaling than producing proper enterprise software. You've just explained some of the downsides.

1
1
Silver badge

Re: Once again

What is really frightening is that many programmers don't even understand what I'm talking about. Or see the problem with source that can only be checked by running it. Or that in the source page text it's impossible to see what actually happens without mentally running a browser inside your head.

Or why Includes that are just text isn't real structure, objects/classes and can create bugs.

0
0
Silver badge

Re: Once again

Of course designing your giant application as lots of small ones (in separately compiled and tested files) with a clearly defined APIs/Interfaces/layers whatever so they are separately testable "black boxes" that implementers of other parts need know nothing about the innards is a good idea. Actually the ONLY way to do bigger projects with more than two developers.

But copy & paste of small "apps" to make a big one is probably a bad idea.

2
0
Silver badge

Re: Once again

Mmm, I code in C. Didn't really take to C++, but that's probably not a surprise since I also write stuff in ARM assembler.

I'm not certain that the issue is that C is inherently bad (certainly other things are better) as much as clueless/lazy programmers making the same fundamental mistakes, such as using strcpy() with no idea if the source string is larger than the destination buffer. There exists a call in the standard library - strncpy() so this bug should never happen....yet it does. Rinse and repeat for dozens of other "oh my god, not that again" failures to validate input / allocate memory / reuse pointers / etc.

Once upon a time good software used to be supplied in a mask programmed ROM. While quirks/bugs still occurred, getting that wrong could break a company. So a lot of testing went into making sure the program was solid and did what it was supposed to do. Now? There is less impetus to get it right the first time. From downloadable patches to FlashROM updates, instead a company can "be the first" to get whatever rubbish they have created out the door. There's no time for proper testing, there's no time for a code review, you gotta be joking if you think we're going to resolve all these dumb compiler warnings, we have a half-working half-assed implementation and management has promised the world that the product will ship on Friday. And so it will. At least...something will ship on Friday...

3
0

Re: Once again

such as using strcpy() with no idea if the source string is larger than the destination buffer. There exists a call in the standard library - strncpy() so this bug should never happen

Except that strncpy() has fundamentally broken semantics, and cannot be used safely for its intended purpose unless you already know the source string fits in the destination (in which case strcpy is suitable and should perform better) or explicitly terminate the destination after copying (in which case you have an additional step to perform after the call, creating another opportunity for programmer error, and you may be unnecessarily touching a page).

strncat() has the correct semantics - it always terminates the destination provided the copy length is at least 1 - but to use it as a safer strcpy you have to initialize the first byte of the destination (and to use it as a safer strcat you have to understand the semantics of the length parameter, which many people get wrong).

Thinking that strncpy is ever the right answer, regardless of what your problem is, is a perfect example of the dangers of C. The C standard library has a number of traps for the unwary. (The %n format specifier for the printf family is another example.) In its defense, at least the C specification is short enough to be read and understood by most C programmers, which certainly can't be said for the ponderous tome that is the C++ standard.

(Richard Heathfield, longtime regular of comp.lang.c, was of the opinion that the strn* functions were undesirable anyway. In his view, you always need to know whether the source fits in the destination, so you can perform proper error handling; silently truncating the string is just lazy programming. And if you already know both lengths, you might as well use memcpy and save a few cycles.)

It is possible to write good C code. It is unfortunately very difficult to do so, and many of the people who think they can do not, in fact, understand the language well enough.

1
0
Silver badge

And another thing...

Much more evil than Macros, or not sanitising input or not checking array bounds or GOTO are Macros.

Macros are for assembler. They are an absolute evil in a High Level Language, Don't use a Macro, EVER.

0
3
Facepalm

Re: And another thing...

Utter Bollox... How else do youy get TRUE and FALSE in C?

Also can be a convenient way for the pre-compiler to do the tedious work of determining which byte you need to write to GPIO. Besides, you can always look at the output of the pre-processor..

1
1
Anonymous Coward

Re: And another thing...

Utter Bollox... How else do youy get TRUE and FALSE in C?

By using a version of C that's less than fifteen years old? That's how long the language has supported a boolean type, making Verity appear a bit foolish when she wrote:

He didn't even bother to change the return type of his function to bool... oh wait, he's writing in C, so he couldn't. Bummer.

Also, her slagging off goto statements only highlights her background as a Pascal programmer, since it's an elegant way to do error cleanup in C if used carefully.

1
4
Silver badge

Re: And another thing...

TRUE and FALSE in C?

Easy-peasy, enumerated types.

See K & R, 2nd edition, 1988. I hope enumerations have not been removed by a subsequent "advance" in language design.

2
0
Silver badge

Re: And another thing...

Why are you using C?

It was designed to make porting UNIX easily. It's not fit for purpose since late 1980s. Been using C++ since 1987.

Besides you don't need Macro to define True and False.

0
6

Re: And another thing...

<quote>Also, her slagging off goto statements only highlights her background as a Pascal programmer, since it's an elegant way to do error cleanup in C if used carefully.</quote>

Which is rather the point. It seems we have two choices, then:

1. Stop using gotos

2. Shoot all the programmers who aren't careful enough to use them

I suspect C programmers would quickly become an endangered species if we went for option 2

0
0

D & E

Although it refers to C++ in an earlier state, I do recommend 'The Design and Evolution of C++' by Stroustrup.

Very few books about programming / software development are any good in my experience (in accord with Sturgeon's Law), and D & E is a timeless classic.

It makes it clear (more so than the main C++ book) where Stroustrup was coming from with C++, and why it is as it is.

1
1
Anonymous Coward

Re: D & E

It makes it clear (more so than the main C++ book) where Stroustrup was coming from with C++, and why it is as it is.

Along with the "Effective C++" and "Exceptional C++" series of books it also make it clear that C++ should be avoided at all costs. A language implemented by a lunatic who has attracted other lunatics, Alexandrescu in particular, to further his evil.

4
2
Thumb Up

Re: Once again

The key phrase here is "But everyone has had time to learn how to program..." and they haven't done so. All the bugs ranted about (and Ms. Stob, I've enjoyed your work since .EXE) are clearly mistakes/crap programming. The language used doesn't matter if one's thinking is clear; recall that the structure/Bohm-Jacopini theorem suggests that only three control structures are actually needed to program. C++ and all the rest are simply personal expressions by someone as to how *they* think this should be accomplished.

0
0

Bring back Ada

After Heartbleed I found myself reading up on Ada --- the original safe programming language. And you know what? It's *really nice*, and I say this as an old-school C hacker. It compiles into real machine code, it's suitable for writing both the really low-level stuff (you can specify the exact bit layout of structures, for example) as well as the high-level stuff (generics and object-oriented code support on a par with C++'s); it's got a beautiful concurrency model that makes juggling threads not just safe but *really easy*; it's got robust support for programming by contract --- preconditions, postconditions etc; and on top of all this it's fast: CLBG shows it to be about equivalent to C++ performance-wise. It even has pointers! But the type system makes them impossible to misuse...

I did a writeup: http://cowlark.com/2014-04-27-ada

I'm becoming increasingly convinced that there is simply *no excuse* for writing stuff in C (and C++) any more. There's just better ways to do it these days.

3
0
Silver badge

Re: Bring back Ada

I think Modula-2 is nicer than Ada, but sadly most people don't understand Modules and Co-Routines to implement Objects and Concurrency. But C++ is preferable to C except when people use a C++ compiler to write C. Strustrup didn't want the amount of backward compatibility there is, but AT&T insisted.

JAL is best for 16F & 18F PIC. Doing them with C or BASIC is plain daft. They don't have the right architecture for pointer rich C or C++ (nor very suitable for Modula-2, Pascal, Ada, Java/C# etc).

I think we are stuck with C++ and Java (C# is really MS Java), but no excuse for C or C like programming styles. Or BASIC which is a cut down Fortran (I regard properly used VB5 & VB6 as closer to Visual Pascal or Visual Modula-2 than BASIC. VB.net on the other hand is C# pretending to be BASIC, so utterly pointless).

0
3

Re: Bring back Ada

The new Go language is efficient and type-safe, and is excellent for the sort of web software that has been botched in these examples. It's easier to learn than C and has nice concurrency baked in. See golang.org

Go generates machine code, and is garbage collected, which has only one bad side-effect in practice. You can't call Go code from C or C++ code in a way that you like. The other way around works very well.

We need a nicer type-safe language for writing critical code modules that can be linked in as libraries (static or dynamic) to existing C/C++ programs. Will ADA do that?

0
0
Silver badge

Re: Bring back Ada

The heartbleed bug could be merrily implemented in any language that supports memory access, it was an algorithm error, not a bounds violation of any form.

Modula-2 might be ok but it was ruined by the inane insistence of the designer that it was going to be a single-pass compilation process. In reality this just doesn't work and you either wind up with horrible kludges to the code or progressively more unwieldy development environments.

I'm becoming increasingly convinced that there is simply *no excuse* for writing stuff in C (and C++) any more. There's just better ways to do it these days.

No one language is so superior to all the others that it is usable at all levels, from device driver all the way to up to user script level. As a general rule: the closer you get to the hardware, the lower the level of language that is appropriate for use. Efficiency really matters at the lower level, while wasting thousands of CPU cycles with boilerplate and support code is almost acceptable at the application level, it most definitely is not for an API call that could be called hundreds of thousands of times a second. Like everything there are always trade offs balancing code security and with efficiency.

1
0

Re: Bring back Ada

I'm becoming increasingly convinced that there is simply *no excuse* for writing stuff in C (and C++) any more.

Of course there's an "excuse". There are even very good reasons to continue using C, C++, or whatever other language enrages the demagogue of your choice.

First there is the need to maintain existing code. This ought to be blindingly obvious to anyone in the industry; I don't know why I even mention it. There are ample case studies and other research showing that the cost of "rip & replace" conversions of large existing code bases to another language tends to be enormous, and such projects are even more prone to failing than typical large IT efforts.

Second there are the costs of developer training - both direct financial costs and indirect ones, like opportunity costs (oh, let's just halt all our development for a few months while our staff learns a new language) and resistance from staff (because programmers are not always the most compliant employees). Just replace them with new hires? Where's this pool of Ada experts waiting to come on board? And do they magically already share all the domain knowledge of existing staff? Didn't think so.

Third, there's no consensus that this wildly expensive radical change will produce any significant improvement. Many people have a pet "better" programming language or method or what have you that they believe will save the world; so far, few have been successful at convincing more than a small group of adherents. And for good reason, since more than one observer has come to agree with Fred Brooks that there is no silver bullet.

2
0

Wasn't it John-Paul Sartre who said..

...'hell is other people's C++' ?

6
0

Boolean types in C

C99 has a bool type. Mind you the standard is only 15 years old so I can see why most people still don't use it.

(That was sarcasm)

6
0

You All Use GoTo

Whenever you use break or continue you're really saying goto. Ever used a switch block? That's just compiler candy for a bunch of if blocks separated by goto. if {foo()} else {bar()} is just if {foo() goto;} {bar()}. You all use it, you just don't like to talk about it!

2
3
Silver badge

Re: You All Use GoTo

There's a huge difference between break, continue and else; and goto.

break is used to exit the current code block, and can only cause the execution to move forward towards the end of the current function. Similarly, continue can't move execution to any point before the enclosing loop was defined, and else can only cause execution to move forward.

goto can explicitly put the execution pointer anywhere in the current function. That's why it's considered such a dangerous tool.

In scoped languages, there's another difference - when you issue a 'break;' you are cleanly leaving the current symbol scope (which means that anything created within that scope will be cleanly disposed of). goto doesn't guarantee anything.

The argument that an if is just a goto is silly, because that's exactly the point of "if". The reason there's an if/else construct at all is to replace the loose cannon of "goto" with something safer and more descriptive (and remember that compilers produce better code when you give them more to work on).

5
0

Re: You All Use GoTo

I was being somewhat facetious, maybe I need to use the Joke Alert. Nevertheless when you look at unoptimised assembly output (and often with more simple code even optimised output) they are often indistinguishable.

1
0

Re: You All Use GoTo

Gah. Eternal September is eternal.

1
0
Silver badge

Anyone who doesn't know when to use a goto, why they should always brace ifs even though there's only one statement, or how to return values from functions in C won't know how to use RAII in C++.

Doesn't make either C or C++ intrinsically bad, one of those programmers would make a mess of it in any language. The question is why are these people being let near encryption libraries?

1
0
Silver badge

Open Source is where seasoned professionals made their early mistakes...

The projects are always short of coders, and meanwhile colleges and universities are always looking for ways of exposing their students to "real" code.

There's a lot of free software that was written by people who, until they wrote it, knew very little about the subject, or even about programming.

The worst examples get weeded out by diligent maintainers, but sometimes code slips through, and then hangs around so long that people think it's a model solution. Definitely the "million eyeballs" collaborative development model encourages the fallacy that "old code is robust code" even without any evidence that the code in question has been examined.

Commercial practices aren't much better, mind, but there's always the threat of lawsuit or being fired to encourage a little more diligence from devs. Plus, by the time you're hired to do a coding job, you've made a lot of your naive mistakes already... on some Open Source project.

3
1
This topic is closed for new posts.

Forums

Biting the hand that feeds IT © 1998–2017