Feeds

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.

Page:

Silver badge
Flame

Christ on a crutch. Are there still C++ programmers out there that don't know about RAII? Presumably they've not heard of smart pointers so either their code is leaky or they are spending too much time and effort running resource monitoring tools.

0
0
Bronze badge

RAII is nice, but it's not available in C++ and that's the whole problem.

0
4
Silver badge
FAIL

RAII is nice, but it's not available in C++ and that's the whole problem.

You couldn't be more wrong. RAII originated in C++. I think you meant that it's not available in C ;)

4
0
Silver badge

I think gcc supports a variant on the idea, but then you get in to serious portability issues for a library that should be cross-platform and compilable on systems of widely varying age.

1
1
Silver badge
Thumb Up

then you get in to serious portability issues

Good point. About the only reason to still be using C would be for backward/cross compatibility.

0
0
Silver badge

@ AndrueC

"About the only reason to still be using C would be for backward/cross compatibility"

So pretty much anything resembling kernel code? And silly little things like browsers, routers, servers, telephones, home entertainment systems, and etc?

Good old K&R C is still doing the grunt-work, and will be for the foreseeable future.

4
0

Re: @ AndrueC

> Good old K&R C is still doing the grunt-work

Blimey, no. I haven't seen K&R C for decades. I suspect most C programmers don't even know the syntax. Where are you seeing it?

3
3
Anonymous Coward

Re: @ AndrueC

Where are you seeing it?

Every time he looks under the hood of his own servers

2
0
Silver badge

Re: @ AndrueC

Every time he looks under the hood of his own servers

Doubt it. Those would be full of decatrons and mercury delay lines, leaving no room for either Kernighan or Ritchie, let alone both of them together.

0
1
Anonymous Coward

If it wasn't, I wouldn't be using it. But I am. Enough said.

0
0
Silver badge

@ Phil Endecott (was: Re: @ AndrueC)

"Where are you seeing it?"

Damn near everywhere close to the hardware.

If you haven't seen K&R C "for decades", you are not a programmer that I would be interested in hiring.

1
1
Anonymous Coward

Re: @ Phil Endecott (was: @ AndrueC)

"If you haven't seen K&R C "for decades", you are not a programmer that I would be interested in hiring."

That depends on what we're describing here. If you code in the language described in the 1st edition of 'The C Programming Language', you've missed six separate revisions of the language, and are speaking a dead dialect that might or might not compile as is on modern compilers (haven't tried it, couldn't say). At least if we're talking the language as described in the 2nd edition, we're in ANSI C territory.

2
0
Anonymous Coward

Re: @ Phil Endecott (was: @ AndrueC)

"and are speaking a dead dialect that might or might not compile as is on modern compilers (haven't tried it, couldn't say)."

I found that sufficiently interesting to install a little C89 compliant compiler (TCC on Windows) and compile some examples. Everything is fine up until you use functions you've failed to declare.

That seems to be an A-OK thing to do in "The C Programming Language 1st Edition" - not so much with an ANSI C compiler. I'm sure this is the tip of the iceberg.

So, if we mean 1st edition C when we say "K&R C", that's a bad thing; I wouldn't hire you if you meant that jake ;-) If we mean C89, and its treatment in the 2nd edition, that's fine, send me a CV.

1
0
Silver badge

@ Andrew Fernie (was: Re: @ Phil Endecott (was: @ AndrueC))

Modern GCC still compiles K&R properly. Early and later ANSI, too.

The issue you are (trying to) address is programmer savvy.

Kiddies don't know how the hardware works anymore. That's the real story.

1
1
Anonymous Coward

Re: @ Andrew Fernie (was: @ Phil Endecott (was: @ AndrueC))

"Modern GCC still compiles K&R properly. Early and later ANSI, too.

The issue you are (trying to) address is programmer savvy.

Kiddies don't know how the hardware works anymore. That's the real story."

That's interesting re: gcc - the '-traditional' switch or similar I'm guessing? The point that rather remains though, is why do you feel that knowing how to program in a dialect of C that nobody uses constitutes programmer savvy, rather than enthusiasm and nostalgia? Genuine question.

1
0
Silver badge

Re: @ Andrew Fernie (was: @ Phil Endecott (was: @ AndrueC))

"The point that rather remains though, is why do you feel that knowing how to program in a dialect of C that nobody uses constitutes programmer savvy, rather than enthusiasm and nostalgia? Genuine question."

"Nobody uses K&R"? If that is a serious question, you are an interface user, not a computer user. There is a difference. Apple uses K&R in their implementation of BSD+mach based iOS (as an example). Genuine answer.

0
1
Anonymous Coward

Re: @ Andrew Fernie (was: @ Phil Endecott (was: @ AndrueC))

""Nobody uses K&R"? If that is a serious question, you are an interface user, not a computer user. There is a difference. Apple uses K&R in their implementation of BSD+mach based iOS (as an example). Genuine answer."

Right... you can cite your source, of course?.

1
0
Anonymous Coward

@ jake

---------------------

EXT - DAY:

A lone tumbleweed rolls across a featureless expanse.

---------------------

I'll take that as a 'no'.

1
0
Silver badge

@ Andrew Fernie (was: Re: @ jake)

::shakes head:: Kids these days. Some of us have work to do, and aren't connected 24/7.

The core of the non-(C+assembler)-Mach bit of Darwin is C. K&R C. The guts are BSD, after all. Yes, userland is C++, but glitter can be written in anything.

0
4
Anonymous Coward

Re: @ Andrew Fernie (was: @ jake)

"::shakes head:: Kids these days. Some of us have work to do, and aren't connected 24/7."

Said the man with nearly 6500 posts of essentially the same old shit to his name.

"The core of the non-(C+assembler)-Mach bit of Darwin is C. K&R C. The guts are BSD, after all. Yes, userland is C++, but glitter can be written in anything."

Cite your source that the Mach source is written in K&R (and by this I mean prior to C89) C.

3
0
Silver badge

Re: @ Andrew Fernie (was: @ jake)

You know, dude/tte, you are attached to TehIntraWebTubes. It has ::whisper:: "search engines". DYOFDW. You might actually learn something. But that would be scary if it completely stomped all over your (mis)conceptions, now wouldn't it?

Religions are ugly. In all forms.

0
5
Anonymous Coward

Re: @ Andrew Fernie (was: @ jake)

"You know, dude/tte, you are attached to TehIntraWebTubes. It has ::whisper:: "search engines". DYOFDW. You might actually learn something. But that would be scary if it completely stomped all over your (mis)conceptions, now wouldn't it?

Religions are ugly. In all forms."

So in summary you've been talking out of your backside, you know it, and you're falling back on your usual line of bullshit, acronyms, condescension and insult. I'm not the one making the spurious claim you are, so cite your source.

3
0
Silver badge

Re: @ Andrew Fernie (was: @ jake)

OK, I'll help you figure it out if you really need the help. Go to Wikipedia.

Search on OSX, iOS, BSD, and Mach. But ignore the Wiki articles.

Rather, follow the included links to off-site pages. Read, and try to understand. If you are capable.

That's as far as I am going to hand-feed you.

If you are trolling, that's probably the first time I've been trolled in about a decade. With the exception of ElReg's resident troll Trevor Pott, of course.

0
4
Anonymous Coward

Re: @ Andrew Fernie (was: @ jake)

Stop stalling and provide one statement, one simple link. Doesn't exist, does it? In the meantime I'll be kind enough to hand-feed you a little further.

"If you are trolling, that's probably the first time I've been trolled in about a decade. With the exception of ElReg's resident troll Trevor Pott, of course."

Sure, you're being trolled if trolling means being asked to to do one, simple reasonable thing in the context of a claim you made that you are now clearly unwilling to back up. That is to cite your.source or withdraw your claim

4
0
Silver badge

Re: @ Andrew Fernie (was: @ jake)

There is no single URL that provides "proof" in this conversation. There are many URLs that provide proof of concept, if you have any clue about reality.

You are clearly not cognizant. HTH, HAND.

0
4
Anonymous Coward

Re: @ Andrew Fernie (was: @ jake)

"There is no single URL that provides "proof" in this conversation."

I guess that's the closest I'll get to an admission that you were talking rubbish, so I'll settle for that.

2
0

Flense

There's nothing wrong with the word "flense". Removing blubber from any code is to applauded.

7
0

Re: Flense

Congratulations, Ma'am, you beat me to it by an hour.

As a fan of Moby-Dick, I love the idea of securing the code to the side of the ship, attaching a rope from a derrick to the outside, and unrolling the fat. Perhaps one day if Douglas Adams's version of virtual reality (in which the computerised accounting system involves writing things in virtual ledgers stored in virtual file cabinets) comes to pass, really advanced debuggers will cause seasickness.

3
0
Bronze badge

Flense

Should we just see comments by the likes of Linus Torvalds as the sort of robust language a harpooner on a whaling ship might use?

0
0
Silver badge
Paris Hilton

goto fail;

Forgive me my ignorance for my C++ (and most other programming) skill went titanic a comparably long time ago. Alternatively, it's early morning after a night with far too little sleep. Anyway, why bother about signedHashes when all this function does, as Verity Stob highlighted in red and bold, is goto fail?

What am I missing here? (That's my personal Paris moment for today.)

0
0
Silver badge
Go

Re: goto fail;

The problem is that C++ has a far more elegant and foolproof way of doing this. In this case you'd declare a class whose constructor allocated the buffers and whose destructor deallocated them.

Then you just create an instance of that class on the stack at the start of the function. Job done. C++ guarantees that the destructor of the instantiated class will be called when it goes out of scope (at the terminating '}'). It removes the need for 'fail' block at the end, and means instead of 'goto fail;' you just have a return. Not only is it more elegant but it's also exception safe so unless the CPU fails or the compiler generated defective code you know that the resources will be freed.

If you're a VB or C# programmer you can think of it like a finally block except that the finally code is in a destructor right next to the constructor which I think is better than having it at the bottom away from where the buffers are allocated. In fact for C# developers it's basically IDisposable only less convoluted.

Unfortunately none of this wonderful stuff is available in C. Just a shame that language is still being used for modern development :(

3
0
Silver badge
Boffin

Re: goto fail;

The problem is that C++ has a far more elegant and foolproof way of doing this. In this case you'd declare a class whose constructor allocated the buffers and whose destructor deallocated them.

Before someone points it out actually these days you'd use std::vector<>. Rolling your own RAII class isn't all that common and is usually for more complex resources like database or OS handles. The STL has mundane stuff covered off.

0
0
Silver badge

re: goto fail;

How I do step-by-step processes with clean deallocation in C++ (with apologies for the stripped indentation)

bool stepByStepProcess()

{

bool overallResult=false;

do {

AcquiredResource one;

if (false==one.checkSomething()) { break; } // will deallocate 'one'

OtherAcquiredResource two(one, "hello");

if (false==one.checkSomethingElse(two)) { break; } // will deallocate 'two', then 'one'

// getting here means everything has worked.

overallResult = true;

} while (false);

return overallResult;

}

If Bjarne hadn't said "C++ ABI and name-mangling is a matter for the implementor" back in 1985, I really don't think C would be still around now...

3
0

Re: re: goto fail;

I've seen code like this a few times:

if (false==one.checkSomething())

and I just think "why?!"

I understand the logic behind putting the constant on the left, but why explicitly compare with true or false? What's wrong with if (!one.checkSomething())?

4
0
Silver badge

Re: re: goto fail;

Legibility. ! is easily missed when you're staring at a lot of code, especially when it's as a term in a larger boolean expression.

Look at this as an example:

 if (token||!f())

I see checking for a false return as catching the "unusual" case, so I make it a little more explicit. I rarely write things like "if (true==...)"

4
2

This post has been deleted by its author

Silver badge
Go

Re: re: goto fail;

if (false==one.checkSomething())

and I just think "why?!"

It helps prod my brain into thinking a bit harder about something most programmers would gloss over. I reverse the terms and check for true/false on predicates. Yes it looks odd and yes (the intent) is that it makes you look twice both when writing it and reading it.

I've found I make far fewer mistakes that way. It's one of a number of styling choices I make that help reduce careless mistakes. Always using {}s is another. Coding shouldn't be about minimalism unless you're working in an interpreted language.

1
0

Re: re: goto fail;

Are you worried about running out of space characters?

if (token || !f())

is much more readable

2
0
Silver badge

@kraut, Re: re: goto fail;

That was a counter-example, to explain why I tend to write "false==" rather than the unary ! operator. It's not an example of code I'd ever write, although sadly it's an example of code I've had to maintain in the past.

I agree that the space character is a good thing. I also bracket boolean terms within expressions, for the time when someone decides to change a test like " if ( x<0 && y!=1 )" into "if (x&0x8000000 && y!=1)". The latter has unfortunate, almost always unintended* consequences; consequences that are avoided if the original terms were bracketed, thus: " if ( (x<0) && (y!=1) )".

I code the way I drive. Defensively, on the assumption that everyone else is either incapable, or not paying attention. (It's not that I think other people are stupid, it's that I accept that even the best coders make stupid mistakes from time to time). Brackets and spaces and indentation have zero runtime overhead, with huge "maintain-time" performance gains.

* intended consequences are worse: any coder who would deliberately exploit the more unintuitive C operator precedences like this in order to save the effort of using brackets would not last long with me.

2
0

Re: @kraut, re: goto fail;

Agree completely about braces after every conditional, even if it's just a single line.

But I guess I'm just so used to looking for logical operators when looking at conditional statements in other people's code that I much prefer not to have to evaluate odd expressions like if(false == i), or even worse, if(true != i) in my head while I'm reading code. I'd rather the more straightforward if(!i). It's like reducing algebraic expressions into the simplest form back at school.

If you really want to throw someone, try using the spelled-out versions if(not i), if(false eq i) etc!

(http://en.wikipedia.org/wiki/Iso646.h)

2
0
Silver badge

Re: @kraut, re: goto fail;

if(true != i)

Ouch. Yeah I wouldn't write that. I also tend to avoid anything that claims to return a negative (eg; I'd much prefer DatabaseWasOpened() to DatabaseFailedToOpen().

0
0
Silver badge

@Tom Re: @kraut, re: goto fail;

To be a little clearer, I generally only use that syntax when checking function returns. For comparing boolean variables in expressions, I do use the ! operator.

The reason I do this only for functions is that it's consistent with the way you'd check for numeric error-codes. (e.g, "if ( eNoErr != thisFunction() )").

I find the use a ! when checking function calls is a little too subtle, simply because about 50% of APIs I've ever used use 0 to mean "no error" and the other 50% use it to mean "not successful". (dishonourable mention here to Apple's CoreFoundation that gives no status at all for operations that can actually fail under some circumstances).

For performing "logical NOT" on variables inside expressions, of course, I do use !, but only if the variable is actually a boolean. I do not write "!x" when I really mean to ask "has the value of the counter/numeric variable x become zero". It'll all end up as the same CPU instructions, so I think it's better to say "x==0" when I mean "test if zero" and "!x" when I mean "test if not true", if only to help the maintainer later on.

Especially as the maintainer may be a future me who has completely forgotten how the code works.

2
0
Silver badge

Note to all C programmers

to me the biggest crime in bug #1 was the lack of {} around the if statements. I can never understand why some programmers write C like they are doing it on 1970 teletypes and must therefore feel they have to reduce the character count to an absolute minimum.

This seems to be the trend in a lot of open source projects, with programmers so keen to show their ability to obfuscate the code, that they forget about the poor buggers who will have to maintain it in the future

15
0
Silver badge

Re: Note to all C programmers

Yes, one of the issues is simply crappy coding style (as the author put it so well "No bug is shallow if it lives in a bug-camouflaging environment.").

That is why the likes of MISRA C/C++ guidelines were created, to get programmers doing things in ways that are robust (i.e. common/minor mistakes are easily caught or mitigated) and readable (so bugs have less opportunity to be hidden).

You can argue C++ has more elegant ways of doing safety/clean-up things, you can also argue that it has lots of interesting ways of adding bloat or doing things inefficiently. But if you know and understand those arguments, you can probably write safe code in either C or C++ anyway.

6
0
Silver badge

Re: Note to all C programmers

to me the biggest crime in bug #1 was the lack of {} around the if statements.

Certainly the style doesn't help. I'd say most of C/C++ issues come from lazy short-hand coding. In fact it's a problem with other languages where people use copy/paste or don't break code blocks out into self contained 'widgets'.

It's the biggest drawback to both languages. You can write good, safe code in both but you need to be on the ball and prepared to put the effort in. Most programmers aren't (in the latter case often because of tight deadlines). I love C++ (although these days I'm entirely C#) but I wish C had withered and died by now. The overhead of C++ isn't that bad and surely it's a rare device these days that needs the raw minimalism of C.

2
2
Silver badge

Re: Note to all C programmers

You can commit crimes against software in any language. However the less imperative the language the harder it generally gets to write bad code. On the downside I find that when such issues do occur tracking down the cause of the fault is much harder.

For example I spent a week tracking down a memory bug because C++ destructors were firing in the wrong order. In C memory allocation/deallocation is far more visible so easier to track through the free order.

2
0
Silver badge

Re: Note to all C programmers

The style definitely doesn't help - and I'm certainly not a "friend" to many of the code formatting styles out there which encourage poorly indented and defined conditional blocks.

It's an absolutely appalling bug to be in place because:

1) An automatic code formatter applied to the code would have shown the problem with ease in a visual review.

2) The compiler would have produced a warning that the code block following it is never executed. Modern compilers are helpful like that. Then utter fuckwit developers either turn off the warnings or ignore them as there are so many. Hint for the clueless: the warnings are there for a reason, deal with them.

3) Testing should have revealed this bug very quickly as the function would not have behaved as expected. To be fair what probably happened was that the code was tested, then the developer hit Ctrl-D while the cursor happened to be on the badly formatted line, duplicating it (Ctrl-D is a common shortcut on many IDEs) probably while pressing Ctrl-S to save the current source file. However again, a commit of the source and the subsequent diff should have revealed this error straight away unless it was introduced as part of a larger block of changes, in which case the unit tests should have been re-run for all cases and the fault identified.

4
0

Re: Note to all C programmers

Not just open source. The company I used to work for took on a new programmer who removed every possible bra and ket from his code "because I don't like them". Java that looks like Python is not a good idea. I am no longer around, someone else has to maintain it.

1
0

Re: Note to all C programmers

'to me the biggest crime in bug #1 was the lack of {} around the if statements'

To me there are two unacceptable issues here - the first, security related code is being given a default return of 'yay, everythings great' - so any errors that cause it to exit unintentionally will always muck up this way - you should set the default the err code to 'Zulus, thousands of em!' and only set to 'yay, everythings great' once you know everything is great - success means success, not 'I haven't noticed anything wrong'.

The second issue being nobody seems to have ever actually tested this nice important piece of behaviour. Until you know it's right, it's wrong, it just might not have demonstrated it yet.

7
0
Roo
Silver badge
Windows

Re: Note to all C programmers

"to me the biggest crime in bug #1 was the lack of {} around the if statements."

I don't see that as a crime, the compiler & language lawyers are the ultimate arbiters of that particular brand of justice. That said I tend to scatter {}'s everywhere by default too, but to be honest I find that consistent indentation is actually a bigger help, and these days there are a lot of editors out there that can fix indentation automatically, so it doesn't cost you much if any time to get the code licked into shape. ;)

I am one of those people who likes languages that denote block structure by indentation (e.g.: Python, OCCAM 2), and I came to prefer those languages because control-flow is easier to follow than sketchy if-else blocks in C(++) with a mix of indentation {}'s and no {}'s. :)

0
1

Page:

This topic is closed for new posts.