- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Nice! I lol'd
Admin
Ooops! I recognise that line of code (if !this). As far as I recall I was having an issue with an object being destroyed but still having a dangling pointer to one of the functions...
You'll all be glad to know that I don't code much C/C++ these days :)
Admin
IE6 still accounts for 15% of the traffic
Or Opera 9.x masquerading as IE6
Admin
I consider the relevant point here to be which bits are written when a null pointer is stored in RAM. In the small-data 8086 models, a null pointer is still stored as an all-zero-bits. Sure, the default DS is used when accessing through the pointer, but because it is implicit, it can be ignored when discussing integer/pointer casts.
If, on the other hand, we're speaking of physical addresses, all modern platforms which do virtual memory break the expectation that a null pointer references (physical) address zero.
Not quite. In 16-bit MS-DOS, for example even in small-data models it is perfectly safe to represent the null pointer as an all-zeroes value. Such a pointer, interpreted as an address, would point to the PSP and could never clash with the address of user-declared or heap-allocated C object. Therefore the 8086 is not an example of the kind I described. It's not how it works in MS-DOS, no. I didn't claim that either. I fail to see how representing a null pointer as all-ones at run time would make a C implementation non-conforming, assuming it was properly documented by that implementation.Admin
In other words, what I think is the interesting question is whether
will print 0 or some other number (ignoring the orthogonal question of the conformance of the type-punning here).Admin
Reminds me of a comment from one of the recent articles:
Mike5
Admin
will it still work if inp="WTF"?
Admin
actually might make sense. Consider the code:
Admin
Admin
With proper stack fuck-ups, it is totally possible to have this pointer to be 0. I've seen it right before my very own eyes.
The ingredients for the magic: Symbian + function-local TReqeustStatus + asynchronous function w/ this local TRequestStatus as parameter.
Admin
A null pointer is not a dangling pointer. A dangling pointer is one that has a non-Null value that is no longer valid i.e. the object that it points to is now deleted.
Admin
Admin
Admin
33?
Admin
the real WTF is that 'nearly every function' in their C++ classes returns a boolean.
Admin
The real WTF is that so many, apparently reasonable, people who wrote posts above never heard of undefined behaviour and still claim to know C++.
C++ is doomed, but not because it is bad language. It's rather because most people using it have no clue and do not bother to lear, other than by reading sources written by other ignorants. And yes, Microsoft's own MFC sources are worst of all. Concepts of exception safety, const correctness or even some basics of the language itself never came to minds of people who wrote or maintain it. Or if they did, were pushed aside.
Microsoft invented .NET because they have too many programmers incapable of using or learning C++. And C, for that matter.
Admin
Admin
I understand the uselessness of that confirm function but can someone explain what the problem is with IE6 and "return false"? Under what conditions will IE6 f that s up? And what is the proper work around?
Admin
What's more, there are perfectly legitimate uses for it.
Example:
int format_fs(FileSys* fsobject) { // fsobject may be NULL! return fsobject->quickformat(); }
int FileSys::quickformat() { if (this==NULL) { // create new file system altogether // set default settings here, e.g. cluster size } else { // create file system with settings based on existing one } // generic format code here! }
I guess the person who chalked this up as a WTF simply hadn't considered the possibility that 'this' CAN be NULL for valid reasons (Not saying that there isn't a cleaner way to write the above code).
If in theory code may be called with a NULL 'this' pointer, I'd say it is better practice to check for it and throw an exception, rather than to segfault.
Admin
C++ is doomed if anything because it is too difficult to write properly, plus the fact that computing moved forwards and C++ as a language could never keep up.
That they are moving on to C++0x and have not included a standard threading library, that there is no standard ABI so strings are non-portable, never mind no standard GUI / graphics library and that they created obstruficated concepts of binding rather than an in-built foreach and lambdas are among the biggest WTFs.
Read any book on C++ and the first thing it will probably teach you is writing early 80s looking console programs, and even then there is no standard way to capture the keyboard input without echoing it to the screen and waiting for the user to hit the return key.
Admin
[quote user="ratchetrSo, to be pedantic: bool foo() { assert(this); if(!this) Log("NULL pointer passed to foo()); if(!this) return false; // or throw new SomeException() }
And since this is C++, you can bury all those details in some sort of VERIFYTHIS() macro if you are so inclined. [/quote] Firstly throw new SomeException() is not the correct way to throw an exception in C++.
Secondly this is completely the wrong reason for using exceptions in C++. exceptions are there to catch environmental-errors, i.e. things that happen at runtime that you do not expect, eg a file terminating early or being invalidly formatted or a network connection going down or a failed connection to a database.
For programming errors, i.e. to find bugs, you use asserts.
Where you are correct is that dying is rarely the right option. Someone having an application die on them will lose all their work. For UNIX apps you can handle this by catching SIGSEGV and SIGBUS signals. For Windows it will generally throw an access violation exception which you can catch.
The best you can often do in such a case is to save anything important and restart the process.
From a user's point of view, it is a WTF of programming that your browser dies if one of the pages you visit has a bug on it. It should simply stop running the script... However this should be implemented by using a separate process to run the script which uses its own memory space. If this process fails to complete the main process should catch this and report that there was an error on the page. This would also prevent browser "hang" when one of your tabs is taking a long time to run. You should be able to switch tabs and work on something else whilst another process is handling this slow operation.
Admin
The C language allows that code to print any value. (Even assuming that 'void *' and 'uintptr_t' are both the same sized items.) Although the difficulties this place on the compiler, and the amount of code that assumes the NULL pointer is the zero bit pattern, mean that no sane implementations use a non-zero NULL.
Admin
Keep in mind that MFC was first written for a compiler that didn't support exceptions at all, and had its own quirks. After that, you have to keep the core backward compatible somehow.
Admin
If by "die" Loren meant to stop running with no message or logging or anything, I agree that is rarely if ever the best solution. But I don't think that's what he meant. He meant "don't return an arbitrary value", i.e. DON'T "degrade gracefully", but display some sort of error message and die.
Yes, sometimes degrading gracefully is the best thing to do. Like your example of the wiper motors not working. Sure, I'd rather my car keep running without windshield wipers.
But suppose the software is a piece of medical monitoring equipment. If it loses the signal from the patient's heart beat sensor, should it just display a "default heart beat" and continue working? I think if I was the patient, I would much prefer that it display a nasty error message and alert everybody in sight that the system has failed.
Note: The above discussion may or may not have anything to do with the specific function under discussion, as we don't know what it was supposed to do or what a return of "false" means.
Admin
If your C++ compiler defines "NULL" to be "(void*)0", it's not compliant from the standard in two respects:
The standard requires NULL to be defined as 0 or 0L
The standard prohibits "foo* o = (void*)(anything)" from compiling, so "foo* o = NULL" wouldn't compile in that case.
There is actually an argument to be made for not using NULL, which is that it can be misleading. There are some cases in C and C++ where writing correct code or recognizing what a program does requires acknowledging that NULL isn't actually a pointer -- something that using '0' makes explicit.
For instance, consider three functions:
and a function call
If NULL were actually a pointer, this call would be ambiguous because either foo(int * a) or foo(char * a) would apply equally well. In fact, the call is completely unambiguous in the worst way -- it calls foo(int a).
Sure, the compiler will probably give a warning (at least GCC does, even without any additional -w flags), but depending on how studious you are about warnings, it could be easy to miss.
Even in pure C, you have a leaky abstraction. Take 'int execl(const char *path, const char *arg, ...)' from Unix. You mark the end of the arg arrays with a null point.r
Is "excel(path, arg0, arg1, arg2, NULL)" correct? Not technically. (Even if it will work on basically any reasonable platform.) Why? Because NULL isn't a pointer -- it's an integer. To be correct and portable even to Byzantine platforms, you have to say "(char*)NULL" for the final parameter.
(There are equally good arguments for using NULL on other grounds, but the debate definitely isn't one-sided.)
Admin
I think (I could be wrong) that the standard only requires that NULL be an constant of an integer type with value 0, so it could be defined as 3-3 or '\0'. Or it could be defined as some special magic integer value, in order to allow warnings when NULL is used in a non-pointer context (which is how G++ works).
Indeed. And C++0x will include a separate null pointer value to avoid this problem (I assume, though, that NULL will still be defined as an integer for backwards compatibility).
Admin
Yeah, I think you're right. (Regardless, (void*)0 is out.)
I almost edited my post to include mention of nullptr, but was too slow and just missed the 5 minute window. ;-)
(And NULL will continue to be available.)
Admin
Believe it or not, this code would prevent a crash when calling a virtual function on a null pointer. This is not a good way to deal with this, so still WTF.
Admin
Admin
if (!fist) return uppercut;
CAPTCHA: aptent I think i know what I'm gonna call my next iphone app.
Admin
So I am no SQL Guru. So how would one find all of the user ids in a table where uid1=ID1 and uid2=ID2? Granted we will ONLY find those IDs and not the rest of the row.
You know I still think ID's looks WAY better than IDs.
Admin
but this class might either not have any virtual functions or not do the test on one.
Admin
Admin
Apparently, according to what I overheard in the supermarket the other day, it should've been
Admin
Addendum (2009-05-23 05:05):
Addendum (2009-05-23 05:05): Oh, I see the Delete button doesn't work for these messages. Darn. Sorry about the mess.
Admin
This one looks like just your basic case of somebody adding some debug code and forgetting to take it out before putting it into production. A good argument for code reviews, I suppose.
Admin
to avoid the problem of people providing user ids like "' from table ; drop table accounting --"
Admin
Admin
Or they were trying to protect against dereferencing a null pointer. On a non-virtual function you can call a method on a null instance. It will fail when the function tries to access members. If it never accesses any members it will actually run just fine. (Or at least it would using old sun forte compilers on solaris 8.)