The Daily WTF: Curious Perversions in Information Technology

2011-10-12 Reply Admin

Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?

2011-10-12 Reply Admin

Steve The Cynic:
gizmore:
Could this be a virus too?
seventy-two onehundredone onehundredfourteen onehundredone thirty-two onehundred-twentyone onehundredeleven onehundredseventeen thirty-two ninety-seven onehundredfourteen onehundredone thirty-three

Captcha: haero .... erm yes :)

There I am, indeed.

(What, did nobody else get it?)

http://www.youtube.com/watch?v=gvdf5n-zI14

2011-10-12 Reply Admin

More likely this: http://en.wikipedia.org/wiki/Advanced_Debugger.

Don't think Java produces core dumps.

2011-10-12 Reply Admin

Nanitus:
Now, tell me, which brand of fax machine doesn't print the page number on each page received. I don't know any ;-)

It is often possible to configure what (if anything) they print as page headers and/or footers.

2011-10-12 Reply Admin

Peter:
Nanitus:
Now, tell me, which brand of fax machine doesn't print the page number on each page received. I don't know any ;-)
It is often possible to configure what (if anything) they print as page headers and/or footers.

If the fax sheets are sent one at a time, dialing up the remote side (it is on sped dial). Insert obligatory "blonde joke" here.

2011-10-12 Reply Admin

At least Vince knew how to practise safe hex.

frits · 2011-10-12 Reply Admin

Level 2:
Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?

I think Visual Studio initialize everything to zeros if not otherwise specialized when compiling for debug. This makes undefined behavior a little more predictable because uninitialized pointers are set to zero and usually crash and burn more quickly than if the pointer is some random variable. The later condition can allow the program to appear to work correctly until some time later when you have inadvertently changed code instead of data or some other insidious change.

The flip side is that problems show up when building for release because the program was relying on some integer to be initialized to 0 or some boolean to be false implicitly.

2011-10-12 Reply Admin

u50875:
Rick here.
UNIX, C (not C++), 14 years ago. Flash drives were in the future. All floppies coming into the building went to a special department that scanned them for viruses. There was a backlog. Yes, I thought it was dumb even back then.

Normally I did my best to save Vince from his own idiocy, but that day I was feeling passive-aggressive. The suits DID take note, and asked the troops about this and several other interesting incidents.

I saw Vince coming out of his next performance review, and he was crying like a little girl. He moved on soon after that.

I don't blame you for disbelieving this story; I could scarcely believe it myself at the time.

So, mid-to-late 90's. Any chance were still using rolls of thermal paper in the fax machine? That would make it a good story.

2011-10-12 Reply Admin

pauly:
Where I work, we bill for taking a dump.

Who hasn't done a thing like this?

Steve The Cynic · 2011-10-12 Reply Admin

frits:
Level 2:
Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?
I think Visual Studio initialize everything to zeros if not otherwise specialized when compiling for debug. This makes undefined behavior a little more predictable because uninitialized pointers are set to zero and usually crash and burn more quickly than if the pointer is some random variable. The later condition can allow the program to appear to work correctly until some time later when you have inadvertently changed code instead of data or some other insidious change.

The flip side is that problems show up when building for release because the program was relying on some integer to be initialized to 0 or some boolean to be false implicitly.

Visual C++ always used to fill stack variables with 0xCC, and heap blocks with 0xCD, so that pointers were definitively both not dereferenceable and not NULL either. It also produces a set of distinctive values in integers and floating point.

Zero is, in fact, the worst possible arbitrary polluting fill value, as it creates valid-looking uninitialised variables, while seeing a long full of 0xCCCCCCCC (or any other always-the-same byte) is a dead giveaway.

2011-10-12 Reply Admin

ContraCorners:
golddog:
To me, the real WTF (and what makes the story unbelievable) is, once the Rick found that the customer wasn't a total moron, Rick and the customer didn't just say, "fax me a couple of pages of hex crap while sending me a dump electronically," so would think he won while solving the problem effectively.
Oh, that and a PM being able to stop technical people from taking the right actions. Fails smell test.
Right... then the next time this happens, Vince can say "just have them fax over the core dump. You remember how quickly that resolved the problem last time, right?"

No, people need to see the consequence of their asinine dictates. That way they'll make wiser decisions in the future.

Oh, wait... Vince was PM? I guess this is a no win situation then.

I would have gone with "If you'd prefer not to have to fax over a core dump, feel free to call the PM and tell him that he's an idiot."

Seriously, the customer should thrown around his weight at that point.

frits · 2011-10-12 Reply Admin

Steve The Cynic:
Zero is, in fact, the worst possible arbitrary polluting fill value, as it creates valid-looking uninitialised variables, while seeing a long full of 0xCCCCCCCC (or any other always-the-same byte) is a dead giveaway.

You're assuming that you'll always be able to view memory at run time from a debugger. You're also assuming a level of troubleshooting skill that I wouldn't expect from fully 70% of developers. Also, 0x00000000 is also an "always-the-same byte".

2011-10-12 Reply Admin

Level 2:
Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?

"I"s of course, every variable should be initial "I"sed.

2011-10-12 Reply Admin

Level 2:
Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?

With Zed

Steve The Cynic · 2011-10-12 Reply Admin

frits:
Steve The Cynic:
Zero is, in fact, the worst possible arbitrary polluting fill value, as it creates valid-looking uninitialised variables, while seeing a long full of 0xCCCCCCCC (or any other always-the-same byte) is a dead giveaway.
You're assuming that you'll always be able to view memory at run time from a debugger. You're also assuming a level of troubleshooting skill that I wouldn't expect from fully 70% of developers. Also, 0x00000000 is also an "always-the-same byte".

So you log a value I give you. But I give it to you from a poisoned uninitialised variable. If the poison value is zero, nobody can tell that the bug is because of that rather than a real zero until it effs up in the release build.

Or worse, the variable is a pointer (assuming an architecture where NULL is an all-zeroes bit pattern), and you do something sane-but-specific with NULL, but dereference non-NULL immediately and therefore crash if the poison value is something guaranteed to create invalid pointers (in the sense where NULL is not invalid).

The point is to make it easier to detect these errors during development, as poisoning values is costly at run-time.

And yes, indeed, zero is an all-same value. I should have been more specific.

Pop quiz: why is 0xCC a good value?

In Win32 user-space, addresses above 0x7FFFFFFF (0xBFFFFFFF in a /3GB machine) do not map to readable memory, much less writable. 0xCCCCCCCC is therefore guaranteed to cause a segfault (most likely actually an invalid page fault, but never mind) when dereferenced.

Steve The Cynic · 2011-10-12 Reply Admin

Whoa:
With Zed

"Zed's dead, honey."

Which is why it's a good value, I guess...

Severity One · 2011-10-12 Reply Admin

Bldsquirrel:
I would have gone with "If you'd prefer not to have to fax over a core dump, feel free to call the PM and tell him that he's an idiot."
Seriously, the customer should thrown around his weight at that point.

You expect the customer to get involved in a conflict between you and your manager? Oh dear.

frits · 2011-10-12 Reply Admin

Steve The Cynic:
frits:
Steve The Cynic:
Zero is, in fact, the worst possible arbitrary polluting fill value, as it creates valid-looking uninitialised variables, while seeing a long full of 0xCCCCCCCC (or any other always-the-same byte) is a dead giveaway.
You're assuming that you'll always be able to view memory at run time from a debugger. You're also assuming a level of troubleshooting skill that I wouldn't expect from fully 70% of developers. Also, 0x00000000 is also an "always-the-same byte".
So you log a value I give you. But I give it to you from a poisoned uninitialised variable. If the poison value is zero, nobody can tell that the bug is because of that rather than a real zero until it effs up in the release build.
Or worse, the variable is a pointer (assuming an architecture where NULL is an all-zeroes bit pattern), and you do something sane-but-specific with NULL, but dereference non-NULL immediately and therefore crash if the poison value is something guaranteed to create invalid pointers (in the sense where NULL is not invalid).

The point is to make it easier to detect these errors during development, as poisoning values is costly at run-time.

And yes, indeed, zero is an all-same value. I should have been more specific.

Pop quiz: why is 0xCC a good value?

In Win32 user-space, addresses above 0x7FFFFFFF (0xBFFFFFFF in a /3GB machine) do not map to readable memory, much less writable. 0xCCCCCCCC is therefore guaranteed to cause a segfault (most likely actually an invalid page fault, but never mind) when dereferenced.

Wouldn't it just be easier to initialize all values explicitly? In the case of undisciplined developers you may need to enforce this through code standards and reveiews.

BTW- What do you normally initialize pointers with (when not assigned an actual value)? The correct answer is... NULL! Should I go ahead and redefine NULL as 0xCCCCCCCC? You also haven't address the fact that by only initilizing undefined variable in debug mode, you are opening up a major can of inconsistent worms.

Steve The Cynic · 2011-10-12 Reply Admin

frits:
Wouldn't it just be easier to initialize all values explicitly? In the case of undisciplined developers you may need to enforce this through code standards and reveiews.
BTW- What do you normally initialize pointers with (when not assigned an actual value)? The correct answer is... NULL! Should I go ahead and redefine NULL as 0xCCCCCCCC? You also haven't address the fact that by only initilizing undefined variable in debug mode, you are opening up a major can of inconsistent worms.

The whole point is that it is indeed easier (well, more correct, actually) to initialise all values explicitly(*). And yes, code standards and reviews are important. But reviewers, too, are human, and poisoning stack and heap frames, done invisibly by the compiler/run-time, helps catch those cases where both the developer and the reviewer missed it.

And the correct "doesn't point to anything" value for pointers is indeed NULL, and that NULL is the value given in the compiler / library, not some arbitrary invention.

And the inconsistent worms arise in release mode where the poisoning is not done (because it causes glacial performance on a good day), so pointers will occasionally have accidentally-sane values. By running in debug mode and, you know, testing the software, you find the uninitialised code paths.

Having a compiler that can detect such things and warn you about them helps as well. GCC (spit) is not that compiler, because historically it only did that analysis in full-on optimising modes...

Addendum (2011-10-12 11:11): (*) It is more correct to assign values before use rather than initialising the variable at definition - in some cases when using C89 you cannot assign real values at definition because you have no way to calculate them until later. In such cases you have three choices: you use an extra brace-block to create a delayed definition, or you initialise with an arbitrarily-selected value solely to have an initialised variable, or you leave the variable uninitialised until the assignment.

Severity One · 2011-10-12 Reply Admin

frits:
Wouldn't it just be easier to initialize all values explicitly? In the case of undisciplined developers you may need to enforce this through code standards and reveiews.

Java enforces this for local variables. For class fields, the default value is 0/false/null, depending on the type.

2011-10-12 Reply Admin

Johnny:
progree:
Kuba:
BlackBart:
frits:
Was this C++? I would have looked for uninitialized variables before even contacting the customer. I also would have looked for stack overflows and buffer overruns. C and/or C++ is the devil's playground in most developers hands, idle or not.

Clearly this wasn't C or C++. C and C++ are not advanced enough to be configured to generate a dump file without a lot of work or adding a dump routine - which Vince would surely have disallowed as being too likely to catch a virus.
I think TRWTF is that C/C++ compilers can be at best expected to produce warnings about that. There should be a way to force a C/C++ compiler to simply initialize everything. It should only be disabled on the little (if any) code where benchmarks show significant and useful speed gains.

I respectfully disagree - c is not intended to be safe; it is intended to be a convenient step above assembly language. There are many instances where it just isn't necessary to initialize areas of data. Unsafe, yes. Necessary, no. c++... actually, c++ shouldn't exist (for various reasons). But, if you consider c++ to be a version of c which is supposed to compete with the higher-level big-boys, then maybe you have a point.

But I certainly don't expect uninitialized data in assembler to be flagged; thus, I don't expect c to flag it either.

CAPTCHA: ingenium - What ingenium thought you could take c and turn it into a real language? (apologies to stroustrap).
Horses for Courses. Any language is crap when it's abused. The "dangers" in C are what make it more powerful than many other languages. Granted, it means that you need programmers who know what they're doing, but it concerns me a little that the world seems to want to create Programming languages that can be used by Programmers who don't know what they're doing....

I've been spending the last few weeks teaching a Grad whose main experience is Java how to do things in C...Suffice it to say, the total lack of awareness about how computers actually use memory is a little concerning. I'm not (for a minute) saying the whole world should do everything in C, but rather that it shouldn't be unreasonable to expect people to know what they're doing (although I guess then we wouldn't need this site). Problems in process should not (usually) be fixed with technology. If the problem is that C fucks things up because people don't know how to use pointers, then teach them how to use pointers. Don't create languages like Java and C# that don't require the knowledge - it just creates less knowledgeable programmers.

Oh, and I've started to play with C++ (because I have to) and have realised it is nothing like C, and using it even remotely like C usually means your doing something wrong and should be using C. People who suggest that C and C++ are similat may not know what they're talking about - maybe any language that uses 'if' is mildly similar too. People who claim they are the same thing definitely don't.

Good one.

And for people who like to talk shit about C, please remember it is the only language that will still exist twenty years from now, because unlike Java, C#, ruby and others it meets its objectives : simple ASM translation - all others having various amount of fail and fancy stuff built-in, but none ultimately filling a purpose.

Java will die because it's slow (anything slower than C++ is slow), heavy(private static final ultimate final again var of doom var1=0;), useless on Windows (no comment), and overall as Johnny said, the best way to create clueless programmers by protecting them from their major mistakes and misunderstandings.

C++ will die because it's not modern enough and it's quite realistic to imagine a "better" C++.

Countless others will die . but C will remain - unless anyone has a better idea of a programming language that is as efficient as C ?

Kuba · 2011-10-12 Reply Admin

progree:
Kuba:
I think TRWTF is that C/C++ compilers can be at best expected to produce warnings about that. There should be a way to force a C/C++ compiler to simply initialize everything. It should only be disabled on the little (if any) code where benchmarks show significant and useful speed gains.

I respectfully disagree - c is not intended to be safe; it is intended to be a convenient step above assembly language. There are many instances where it just isn't necessary to initialize areas of data. Unsafe, yes. Necessary, no. c++... actually, c++ shouldn't exist (for various reasons). But, if you consider c++ to be a version of c which is supposed to compete with the higher-level big-boys, then maybe you have a point.

But I certainly don't expect uninitialized data in assembler to be flagged; thus, I don't expect c to flag it either..

I don't think there's a big deal about assembler to flag access to uninitialized data. It's no harder to do than in any high level language. You can do data flow analysis just as easily inside of an assembler as you'd inside of a C compiler. About the only problem with assembly is that you have to have some heuristics about where the contents of certain things (stack locations, registers, etc) should be presumed to become invalid.

Kuba · 2011-10-12 Reply Admin

L.:
And for people who like to talk shit about C, please remember it is the only language that will still exist twenty years from now, because unlike Java, C#, ruby and others it meets its objectives : simple ASM translation - all others having various amount of fail and fancy stuff built-in, but none ultimately filling a purpose.

C does not have a "simple" translation into assembly. In fact, legacy C is very hard to produce optimal assembly output from, due to aliasing. There are languages that are plenty easier to produce good assembly output from -- say FORTRAN or the ML family (OCaml, etc).

2011-10-12 Reply Admin

tl;dr summary of this page:

Java will DIE during slow initializing with zeroes instead of 0xCC

Kuba · 2011-10-12 Reply Admin

Level 2:
Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?

With whatever C++ would value-initialize given type by default, when initializing aggregates with partial initializers (for example). That means -- zeros. That's what C++ does, and I think it's a sane choice.

Kuba · 2011-10-12 Reply Admin

L.:
Java will die because it's slow (anything slower than C++ is slow), heavy(private static final ultimate final again var of doom var1=0;), useless on Windows (no comment), and overall as Johnny said, the best way to create clueless programmers by protecting them from their major mistakes and misunderstandings.

Java will not "die" for the same reason COBOL won't "die". There are hundreds of millions of lines enterprise code that nobody has any will to rewrite. I'm not saying those millions of lines couldn't be redone in 10x less lines in a saner language (or with better design), but try telling that to shareholders :)

2011-10-12 Reply Admin

frits:
Wouldn't it just be easier to initialize all values explicitly? In the case of undisciplined developers you may need to enforce this through code standards and reveiews.
BTW- What do you normally initialize pointers with (when not assigned an actual value)? The correct answer is... NULL! Should I go ahead and redefine NULL as 0xCCCCCCCC? You also haven't address the fact that by only initilizing undefined variable in debug mode, you are opening up a major can of inconsistent worms.

I think you missed the point there, frits.

If the compiler always automatically initialises every variable, then much of the time the variable will get initialised twice - once by the compiler to %default-value%, then again by the programmer to the value they actually want. This is quite expensive!

The worst case is things like:

for (int n=10; n>0; n--){
/*Stuff*/
}

Now you can of course build a compiler that avoids double-initialising in these trivial cases where the programmer's initialisation is instant and a constant.

What about other cases, like initialising to the result of some function call? (For example a constructor)

Should the compiler initialise the variable before calling the function? What if the programmer makes a mistake and uses the variable during that initialisation function call?

As you said, you can have a design rule for your programmers that says "Thou Shalt Initialise Everything".

Good idea - but how do you enforce that rule? Simple code review is not going to spot it in all cases - just the most obvious.

So, how about a special compiler mode that automatically initialises every variable to a particular magic number? It'll run noticably slower than the normal code, but you can test (and unit test) with it and you don't need the compiler to be very clever about it.

That way, if you ever see that magic number anywhere you can immediately raise an alarm and check whether it's a genuine value or a screwup.

To minimise false alarms and speed up checks in unit tests etc you'll want to pick a magic number that's easy to spot, unlikely to happen in 'normal running', and that will instakill the application if ever dereferenced.

Steve The Cynic · 2011-10-12 Reply Admin

Kuba:
L.:
And for people who like to talk shit about C, please remember it is the only language that will still exist twenty years from now, because unlike Java, C#, ruby and others it meets its objectives : simple ASM translation - all others having various amount of fail and fancy stuff built-in, but none ultimately filling a purpose.
C does not have a "simple" translation into assembly. In fact, legacy C is very hard to produce optimal assembly output from, due to aliasing. There are languages that are plenty easier to produce good assembly output from -- say FORTRAN or the ML family (OCaml, etc).

Rubbish. C does indeed have a simple (perhaps "simplistic" might be a better word) translation to assembly, but such a translation has little to do with "optimal".

while( 1 ) { /* loop that really is meant to run forever */ }

One compiler for 8088 that I used many moons ago used a severely suboptimal optimiser. On its most aggressive setting, it translated the above code as:

JMP bottomOfLoop topOfLoop: ; ; loop that really is meant to run forever ; bottomOfLoop: MOV AX, 1 CMP AX, 0 JNE topOfLoop

I threw the compiler out, needless to say, and replaced it with another one which performed a group of vaguely complicated FP calculations in a third of the time.

FORTRAN, by-the-way, is also plagued by aliasing in various unpleasant and hard-to-detect ways.

  SUBROUTINE F(I,J)
  ...

  CALL F( K, K )

Is the simplest example. If you only have the code for F, you cannot possibly know that it will suffer from aliasing problems. Allowing EQUIVALENCE makes it that much harder to detect.

On the other hand, I seem to recall some blither somewhere about aliasing being marked as provoking undefined behaviour in FORTRAN, so maybe it doesn't matter.

2011-10-12 Reply Admin

Jay:
At the risk of taking Vince's concerns seriously: Why did he think that printing it out and typing it back in would prevent a virus? If the original file contained a virus, then printing it out and typing it back in would result in a file that contained a virus.

Because he's a moron who doesn't know how viruses work, only that he's heard of them spreading in certain ways and faxes aren't one of them.

CAPTCHA points out that he sees no way for the virus tego through the fax machine.

Steve The Cynic · 2011-10-12 Reply Admin

Kuba:
Level 2:
Kuba:
There should be a way to force a C/C++ compiler to simply initialize everything.

With what?
With whatever C++ would value-initialize given type by default, when initializing aggregates with partial initializers (for example). That means -- zeros. That's what C++ does, and I think it's a sane choice.

No, actually, it doesn't, except for the afore-mentioned aggregates. For:

int i;

i is not initialised to anything in particular. Visual C++ has a bug-detection aid in debug mode where each function essentially begins:

int f(blah_t blah)
{
  create_stack_frame( amount );
  memset( stack_frame, 0xCC, amount );

frits · 2011-10-12 Reply Admin

Just this guy:
frits:
Wouldn't it just be easier to initialize all values explicitly? In the case of undisciplined developers you may need to enforce this through code standards and reveiews.
BTW- What do you normally initialize pointers with (when not assigned an actual value)? The correct answer is... NULL! Should I go ahead and redefine NULL as 0xCCCCCCCC? You also haven't address the fact that by only initilizing undefined variable in debug mode, you are opening up a major can of inconsistent worms.

I think you missed the point there, frits.
If the compiler always automatically initialises every variable, then much of the time the variable will get initialised twice - once by the compiler to %default-value%, then again by the programmer to the value they actually want. This is quite expensive!

The worst case is things like:
for (int n=10; n>0; n--){
/*Stuff*/
}
Now you can of course build a compiler that avoids double-initialising in these trivial cases where the programmer's initialisation is instant and a constant.
What about other cases, like initialising to the result of some function call? (For example a constructor)

Should the compiler initialise the variable before calling the function? What if the programmer makes a mistake and uses the variable during that initialisation function call?

As you said, you can have a design rule for your programmers that says "Thou Shalt Initialise Everything".

Good idea - but how do you enforce that rule? Simple code review is not going to spot it in all cases - just the most obvious.

So, how about a special compiler mode that automatically initialises every variable to a particular magic number? It'll run noticably slower than the normal code, but you can test (and unit test) with it and you don't need the compiler to be very clever about it.

That way, if you ever see that magic number anywhere you can immediately raise an alarm and check whether it's a genuine value or a screwup.

To minimise false alarms and speed up checks in unit tests etc you'll want to pick a magic number that's easy to spot, unlikely to happen in 'normal running', and that will instakill the application if ever dereferenced.

Nice troll shitbag.

2011-10-12 Reply Admin

Peter:
Nanitus:
Now, tell me, which brand of fax machine doesn't print the page number on each page received. I don't know any ;-)
It is often possible to configure what (if anything) they print as page headers and/or footers.

Yeah, they set it that way to save the ink of printing all those page numbers.

2011-10-12 Reply Admin

C is dead same way as FORTRAN.

There are some legacy code of course, but it will be eventually replaced with C#

As in operating systems (Cosmos, Singularity) and embedded (.NET Micro Framework)

C-Octothorpe · 2011-10-12 Reply Admin

Mentor:
C is dead same way as FORTRAN.
There are some legacy code of course, but it will be eventually replaced with C#

As in operating systems (Cosmos, Singularity) and embedded (.NET Micro Framework)

Ya almost had me there...

2/10 - Too obvious (people don't usually bite for the stupid ones)

Addendum (2011-10-12 12:14): What you could do next time for more internets is to go slapstick: say something like "it will be eventually replaced with Ruby or ColdFusion"

2011-10-12 Reply Admin

FORTRAN, by-the-way, is also plagued by aliasing in various unpleasant and >hard-to-detect ways.

Yes, but these don't impact optimization: FORTRAN simply optimizes as though there were no aliasing and if you introduce any it's your problem to get it right.

PedanticCurmudgeon · 2011-10-12 Reply Admin

C-Octothorpe:
Mentor:
C is dead same way as FORTRAN.
There are some legacy code of course, but it will be eventually replaced with C#

As in operating systems (Cosmos, Singularity) and embedded (.NET Micro Framework)
Ya almost had me there...

2/10 - Too obvious (people don't usually bite for the stupid ones)

Addendum (2011-10-12 12:14): What you could do next time for more internets is to go slapstick: say something like "it will be eventually replaced with Ruby or ColdFusion"

Or Haskell. I got a bite with that one earlier in the thread.

2011-10-12 Reply Admin

Here in Hyderabad, "taking dump" is youfamisim for defacation.

2011-10-12 Reply Admin

C-Octothorpe:
What you could do next time for more meth is to go slapdick: say something like "Suck it bitch! Yeah! Take my Ruby or ColdFusion all the way! Oooh! I'm about to Cum++!"

ZTFY

Coyne · 2011-10-12 Reply Admin

Steve The Cynic:
Zero is, in fact, the worst possible arbitrary polluting fill value, as it creates valid-looking uninitialised variables, while seeing a long full of 0xCCCCCCCC (or any other always-the-same byte) is a dead giveaway.

I don't know; I always thought 0xDEADBEEF was cool.

2011-10-12 Reply Admin

L.:

And for people who like to talk shit about C, please remember it is the only language that will still exist twenty years from now, because unlike Java, C#, ruby and others it meets its objectives : simple ASM translation - all others having various amount of fail and fancy stuff built-in, but none ultimately filling a purpose.

Java will die because it's slow (anything slower than C++ is slow), heavy(private static final ultimate final again var of doom var1=0;), useless on Windows (no comment), and overall as Johnny said, the best way to create clueless programmers by protecting them from their major mistakes and misunderstandings.

C++ will die because it's not modern enough and it's quite realistic to imagine a "better" C++.

Countless others will die . but C will remain - unless anyone has a better idea of a programming language that is as efficient as C ?

VB.NET is obvius going to stay.

Matt Westwood · 2011-10-12 Reply Admin

L.:
Johnny:
progree:
Kuba:
BlackBart:
frits:
Was this C++? I would have looked for uninitialized variables before even contacting the customer. I also would have looked for stack overflows and buffer overruns. C and/or C++ is the devil's playground in most developers hands, idle or not.

Clearly this wasn't C or C++. C and C++ are not advanced enough to be configured to generate a dump file without a lot of work or adding a dump routine - which Vince would surely have disallowed as being too likely to catch a virus.
I think TRWTF is that C/C++ compilers can be at best expected to produce warnings about that. There should be a way to force a C/C++ compiler to simply initialize everything. It should only be disabled on the little (if any) code where benchmarks show significant and useful speed gains.

I respectfully disagree - c is not intended to be safe; it is intended to be a convenient step above assembly language. There are many instances where it just isn't necessary to initialize areas of data. Unsafe, yes. Necessary, no. c++... actually, c++ shouldn't exist (for various reasons). But, if you consider c++ to be a version of c which is supposed to compete with the higher-level big-boys, then maybe you have a point.

But I certainly don't expect uninitialized data in assembler to be flagged; thus, I don't expect c to flag it either.

CAPTCHA: ingenium - What ingenium thought you could take c and turn it into a real language? (apologies to stroustrap).
Horses for Courses. Any language is crap when it's abused. The "dangers" in C are what make it more powerful than many other languages. Granted, it means that you need programmers who know what they're doing, but it concerns me a little that the world seems to want to create Programming languages that can be used by Programmers who don't know what they're doing....

I've been spending the last few weeks teaching a Grad whose main experience is Java how to do things in C...Suffice it to say, the total lack of awareness about how computers actually use memory is a little concerning. I'm not (for a minute) saying the whole world should do everything in C, but rather that it shouldn't be unreasonable to expect people to know what they're doing (although I guess then we wouldn't need this site). Problems in process should not (usually) be fixed with technology. If the problem is that C fucks things up because people don't know how to use pointers, then teach them how to use pointers. Don't create languages like Java and C# that don't require the knowledge - it just creates less knowledgeable programmers.

Oh, and I've started to play with C++ (because I have to) and have realised it is nothing like C, and using it even remotely like C usually means your doing something wrong and should be using C. People who suggest that C and C++ are similat may not know what they're talking about - maybe any language that uses 'if' is mildly similar too. People who claim they are the same thing definitely don't.

Good one.

And for people who like to talk shit about C, please remember it is the only language that will still exist twenty years from now, because unlike Java, C#, ruby and others it meets its objectives : simple ASM translation - all others having various amount of fail and fancy stuff built-in, but none ultimately filling a purpose.

Java will die because it's slow (anything slower than C++ is slow), heavy(private static final ultimate final again var of doom var1=0;), useless on Windows (no comment), and overall as Johnny said, the best way to create clueless programmers by protecting them from their major mistakes and misunderstandings.

C++ will die because it's not modern enough and it's quite realistic to imagine a "better" C++.

Countless others will die . but C will remain - unless anyone has a better idea of a programming language that is as efficient as C ?

FORTRAN of course, you dick.

2011-10-12 Reply Admin

This is mad, makes me want to murder someone.

PedanticCurmudgeon · 2011-10-12 Reply Admin

L.:
Countless others will die . but C will remain - unless anyone has a better idea of a programming language that is as efficient as C ?

Why not Forth?

2011-10-12 Reply Admin

Luiz Felipe:
This is mad, makes me want to murder someone.

If i ever need to work with someone like Vince. I will not be responsible for my actions.

2011-10-12 Reply Admin

the glittery unicorn ponies are especially corny.

2011-10-12 Reply Admin

Nagesh:
Here in Hyderabad, "taking dump" is youfamisim for defacation.

Here it's a euphemism for going to Hyderabad.

2011-10-12 Reply Admin

This Websense category is filtered: Freeware and Software Download. Sites in this category may pose a security threat to network resources or private information, and are blocked by your organization.

2011-10-12 Reply Admin

É¥sÇbÉu:
This Websense category is filtered: Freeware and Software Download. Sites in this category may pose a security threat to network resources or private information, and are blocked by your organization.

We r using open-sourced softwares only.

2011-10-12 Reply Admin

Johnny:
progree:
Kuba:
BlackBart:
frits:
Was this C++? I would have looked for uninitialized variables before even contacting the customer. I also would have looked for stack overflows and buffer overruns. C and/or C++ is the devil's playground in most developers hands, idle or not.

Clearly this wasn't C or C++. C and C++ are not advanced enough to be configured to generate a dump file without a lot of work or adding a dump routine - which Vince would surely have disallowed as being too likely to catch a virus.
I think TRWTF is that C/C++ compilers can be at best expected to produce warnings about that. There should be a way to force a C/C++ compiler to simply initialize everything. It should only be disabled on the little (if any) code where benchmarks show significant and useful speed gains.

I respectfully disagree - c is not intended to be safe; it is intended to be a convenient step above assembly language. There are many instances where it just isn't necessary to initialize areas of data. Unsafe, yes. Necessary, no. c++... actually, c++ shouldn't exist (for various reasons). But, if you consider c++ to be a version of c which is supposed to compete with the higher-level big-boys, then maybe you have a point.

But I certainly don't expect uninitialized data in assembler to be flagged; thus, I don't expect c to flag it either.

CAPTCHA: ingenium - What ingenium thought you could take c and turn it into a real language? (apologies to stroustrap).
Horses for Courses. Any language is crap when it's abused. The "dangers" in C are what make it more powerful than many other languages. Granted, it means that you need programmers who know what they're doing, but it concerns me a little that the world seems to want to create Programming languages that can be used by Programmers who don't know what they're doing....

I've been spending the last few weeks teaching a Grad whose main experience is Java how to do things in C...Suffice it to say, the total lack of awareness about how computers actually use memory is a little concerning. I'm not (for a minute) saying the whole world should do everything in C, but rather that it shouldn't be unreasonable to expect people to know what they're doing (although I guess then we wouldn't need this site). Problems in process should not (usually) be fixed with technology. If the problem is that C fucks things up because people don't know how to use pointers, then teach them how to use pointers. Don't create languages like Java and C# that don't require the knowledge - it just creates less knowledgeable programmers.

Oh, and I've started to play with C++ (because I have to) and have realised it is nothing like C, and using it even remotely like C usually means your doing something wrong and should be using C. People who suggest that C and C++ are similat may not know what they're talking about - maybe any language that uses 'if' is mildly similar too. People who claim they are the same thing definitely don't.

No, you are wrong. if less knowledgeable programmers are being created, the culprit is not languages like c# or java, it is some teacher that insists on too much teory and low practice. teory without pratice is futile, pratice without teory is leaky. will they insist on this disbalance, will he have more and more clueless people.

The problem is not with pointers, i have learned them from C, but my main language was basic, and it saved me from much problems when p/invoking (using API was considered black magic, and i were a magician, because i understood pointers, i have no problems with Win32). Even now, using csharp, it saved me from disposable problems when using "native" wrapped dotnet classes.

2011-10-12 Reply Admin

Luiz Felipe:
Johnny:
progree:
Kuba:
BlackBart:
frits:
Was this C++? I would have looked for uninitialized variables before even contacting the customer. I also would have looked for stack overflows and buffer overruns. C and/or C++ is the devil's playground in most developers hands, idle or not.

Clearly this wasn't C or C++. C and C++ are not advanced enough to be configured to generate a dump file without a lot of work or adding a dump routine - which Vince would surely have disallowed as being too likely to catch a virus.
I think TRWTF is that C/C++ compilers can be at best expected to produce warnings about that. There should be a way to force a C/C++ compiler to simply initialize everything. It should only be disabled on the little (if any) code where benchmarks show significant and useful speed gains.

I respectfully disagree - c is not intended to be safe; it is intended to be a convenient step above assembly language. There are many instances where it just isn't necessary to initialize areas of data. Unsafe, yes. Necessary, no. c++... actually, c++ shouldn't exist (for various reasons). But, if you consider c++ to be a version of c which is supposed to compete with the higher-level big-boys, then maybe you have a point.

But I certainly don't expect uninitialized data in assembler to be flagged; thus, I don't expect c to flag it either.

CAPTCHA: ingenium - What ingenium thought you could take c and turn it into a real language? (apologies to stroustrap).
Horses for Courses. Any language is crap when it's abused. The "dangers" in C are what make it more powerful than many other languages. Granted, it means that you need programmers who know what they're doing, but it concerns me a little that the world seems to want to create Programming languages that can be used by Programmers who don't know what they're doing....

I've been spending the last few weeks teaching a Grad whose main experience is Java how to do things in C...Suffice it to say, the total lack of awareness about how computers actually use memory is a little concerning. I'm not (for a minute) saying the whole world should do everything in C, but rather that it shouldn't be unreasonable to expect people to know what they're doing (although I guess then we wouldn't need this site). Problems in process should not (usually) be fixed with technology. If the problem is that C fucks things up because people don't know how to use pointers, then teach them how to use pointers. Don't create languages like Java and C# that don't require the knowledge - it just creates less knowledgeable programmers.

Oh, and I've started to play with C++ (because I have to) and have realised it is nothing like C, and using it even remotely like C usually means your doing something wrong and should be using C. People who suggest that C and C++ are similat may not know what they're talking about - maybe any language that uses 'if' is mildly similar too. People who claim they are the same thing definitely don't.

No, you are wrong. if less knowledgeable programmers are being created, the culprit is not languages like c# or java, it is some teacher that insists on too much teory and low practice. teory without pratice is futile, pratice without teory is leaky. will they insist on this disbalance, will he have more and more clueless people.

The problem is not with pointers, i have learned them from C, but my main language was basic, and it saved me from much problems when p/invoking (using API was considered black magic, and i were a magician, because i understood pointers, i have no problems with Win32). Even now, using csharp, it saved me from disposable problems when using "native" wrapped dotnet classes.

ps, now i write a lot of C/C++, and have no problem with pointer. i even do some assembly just for fun.

Taking a Dump

Leave a comment on “Taking a Dump”