• OldCoder (unregistered) in reply to SCJP
    SCJP:
    shadowman:
    I don't get the String.format() one.
    Splitting the SQL string into four parts first and let String.Format() put it together afterwards is somehow senseless.
    D'oh! You don't need the SQL at all, since all it selects is two fields which are the same as the values it supplies.
  • Jamie (unregistered) in reply to OldCoder
    OldCoder:
    SCJP:
    shadowman:
    I don't get the String.format() one.
    Splitting the SQL string into four parts first and let String.Format() put it together afterwards is somehow senseless.
    D'oh! You don't need the SQL at all, since all it selects is two fields which are the same as the values it supplies.

    You do if you want to find out if it is actually in the database... But that's not the way to do it!

  • SCJP (unregistered) in reply to OldCoder
    OldCoder:
    SCJP:
    shadowman:
    I don't get the String.format() one.
    Splitting the SQL string into four parts first and let String.Format() put it together afterwards is somehow senseless.
    D'oh! You don't need the SQL at all, since all it selects is two fields which are the same as the values it supplies.
    Hehe, that's right! Didn't look at the semantics, just at the syntax. Now, that's really ridiculous.
  • Tom (unregistered) in reply to Code Dependent

    That is what I was thinking. I just wanted to make sure I wasn't missing something else, because I know I'd written similar crap when I first started.

  • (cs)

    Smut [image]

  • (cs) in reply to Médinoc
    Médinoc:
    kastein:
    I bet whoever wrote the "do I exist" C++ class defense noticed that that was checked after "new <whateverclass>" every time, so he figured hey, I can put this code in one place and stop duplicating it! Either that, or it's from some abomination of a mixed-language application and the class is used through some strange wrapper from another language and might not be trusted to actually set the "this" pointer while calling. Either way, WTF?
    Unlike Java, it's possible in C++ to call a class member function from a null pointer. If the function is not virtual, the program will not crash before entering it, and it won't crash inside the function either if no member variables are accessed.

    An Example from a well-known UI class library:

    HWND CWnd::GetSafeHwnd()
    { return this ? m_hWnd : null; }

    Yikes, how the hell did I forget that you could cast a null pointer to the class and call its methods? I've been writing C and assembly for too long...

    (and I don't really know Java)

  • soup (unregistered) in reply to Médinoc
    Médinoc:
    kastein:
    I bet whoever wrote the "do I exist" C++ class defense noticed that that was checked after "new <whateverclass>" every time, so he figured hey, I can put this code in one place and stop duplicating it! Either that, or it's from some abomination of a mixed-language application and the class is used through some strange wrapper from another language and might not be trusted to actually set the "this" pointer while calling. Either way, WTF?
    Unlike Java, it's possible in C++ to call a class member function from a null pointer. If the function is not virtual, the program will not crash before entering it, and it won't crash inside the function either if no member variables are accessed.

    An Example from a well-known UI class library:

    HWND CWnd::GetSafeHwnd()
    { return this ? m_hWnd : null; }

    "I invented the term Object-Oriented and I can tell you I did not have C++ in mind." -- Alan Kay

  • Weps (unregistered) in reply to Pedant
    Pedant:
    Bjarne Stroustrup uses "if (this==0)" twice on page 605 of "Programming: Principles and Practice using C++". It isn't needed in every method, but it isn't automatically a WTF.

    If he meant "if (this==NULL)" then it's definitly a wtf.

  • (cs) in reply to Pedant

    Having assert(this) might make sense(But I would really like my compiler to always do that in debug mode. Having to add the code to all my methods by 'hand is' is stupid).

    but having if(!this) return false is a wtf because it transform a 'fast fail' into something that return an arbitrary value, thus causing a hell for debugging later.

    Or maybe the code is supposed to 'work correctly' when called on a null pointer, but that would be its own wtf(And would depend on the exact way the compiler would generate code).

  • Anonymous Cowherd (unregistered)

    Here's the thing:

    In very very very early C++ days, there were no static methods. So if you wanted to define one, you'd have to do it as a free function -- but if you did, you lost access to any private static members. So instead, the idiom for a static method was to do ((Foo *)(0))->blah(). If you look at sufficiently old books, this is still used in some places.

  • Loren Pechtel (unregistered)

    The problem with the !this is not the test, it's what's done about it. On occasion it might make sense to return false if called on a null but that certainly shouldn't be the normal result. The desired result generally should be to die.

    I could believe this started from somebody getting blamed for crashes due to someone else's code and they did this so the blowups wouldn't be in their code and then it somehow became standard practice.

  • anon (unregistered) in reply to Médinoc
    Unlike Java, it's possible in C++ to call a class member function from a null pointer. If the function is not virtual, the program will not crash before entering it, and it won't crash inside the function either if no member variables are accessed.

    An Example from a well-known UI class library:

    HWND CWnd::GetSafeHwnd() { return this ? m_hWnd : null; }

    That depends on your definition of "possible". The code will compile all right, so by one definition it's "possible". At runtime, however, you've just entered undefined territory, and it may well NOT be "possible" to make that call at run time. Worse, it's legal for that call to now format your hard drive (yeah, I'm being pedantic, as no implementation is going to do this, but the point stands).

    Many implementations allow that call, so it's debatable whether or not checking if "this == 0" is ever something to consider doing. I think most would side on the act being a WTF, though, especially if you do anything other than cause some sort of immediate failure (and returning a value, even an error code, doesn't fit that definition). The GetSafeHwnd() is a WTF, though it was there for a reason. Always doing a "return false" is a WTF, and there can't be a defensible reason.

  • (cs) in reply to CAT
    CAT:
    The Real WTF are sites which rely on JS (or Flash, Java, ...) for basic functionality.
    What, like Google Maps?

    np: Prefuse 73 - Half Up Front (Everything She Touched Turned Ampexian)

  • Pedant (unregistered) in reply to Loren Pechtel
    Loren Pechtel:
    The problem with the !this is not the test, it's what's done about it. On occasion it might make sense to return false if called on a null but that certainly shouldn't be the normal result. The desired result generally should be to die.

    Wrong.

    Link* Link::insert(Link* n) { if (n==0) return this; if (this==0) return n; ... }

    from Bjarne Stroustrup, "Programming: Principles and Practice Using C++", p. 605.

  • Pedant (unregistered) in reply to Weps
    Weps:
    Pedant:
    Bjarne Stroustrup uses "if (this==0)" twice on page 605 of "Programming: Principles and Practice using C++". It isn't needed in every method, but it isn't automatically a WTF.

    If he meant "if (this==NULL)" then it's definitly a wtf.

    What are you talking about? NULL and 0 are synonymous in C++.

  • paulm (unregistered) in reply to SCJP
    SCJP:
    For those not familiar with Java:
    Boolean answer = new Boolean(inp);
    ...simply does the trick.

    Although,

    Boolean answer = Boolean.valueOf(inp);

    is even better, as it avoids pointlessly creating extra Boolean object instances.

  • Long (unregistered) in reply to shadowman
    shadowman:
    Tom:
    Someone explain to me the javascript one. Is the WTF that the comment and the if (!confirmed) don't match? I'm going crazy trying to see what is wrong with this (maybe just because it is Friday...)

    The whole function is an unnecessary wrapper around

    var confirmation = confirm(message);

    It doesn't add anything beyond that one line.

    What if confirm() returns FILE_NOT_FOUND?

  • Single User (unregistered) in reply to Pedant
    Pedant:
    Loren Pechtel:
    The problem with the !this is not the test, it's what's done about it. On occasion it might make sense to return false if called on a null but that certainly shouldn't be the normal result. The desired result generally should be to die.

    Wrong.

    Link* Link::insert(Link* n) { if (n==0) return this; if (this==0) return n; ... }

    from Bjarne Stroustrup, "Programming: Principles and Practice Using C++", p. 605.

    ((Link*)0)->insert(NULL) might cause problems, no? Frankly, code like that shouldn't even compile.

  • jj (unregistered)
    Boolean answer = new Boolean( inp.equals("true") ? new Boolean(true) : new Boolean(false)).booleanValue();

    This is even more amazing if you understand autoboxing and notice the operations the compiler will add in. The final result is something like

    Boolean answer = Boolean.valueOf(
      new Boolean(inp.equals("true")
        ? new Boolean(true).booleanValue()
        : new Boolean(false).booleanValue()
      ).booleanValue())
    

    wow.

  • voyou (unregistered) in reply to paulm
    paulm:
    SCJP:
    For those not familiar with Java:
    Boolean answer = new Boolean(inp);
    ...simply does the trick.

    Although,

    Boolean answer = Boolean.valueOf(inp);

    is even better, as it avoids pointlessly creating extra Boolean object instances.

    What's the difference? I would have thought they both created exactly one Boolean instance (but I don't have any great level of understanding of how Java's boxing works).

  • ratchetr (unregistered) in reply to Loren Pechtel
    Loren Pechtel:
    The problem with the !this is not the test, it's what's done about it. On occasion it might make sense to return false if called on a null but that certainly shouldn't be the normal result. The desired result generally should be to die.
    Sudden death is hardly ever a good design decision. Software should degrade gracefully even when faced with impossible errors. (I'm assuming !this isn't an expected condition...that WOULD be a WTF.)

    What if the code in question is part of an engine management system? Do you want your car to just die while you're merging into rush hour traffic? Even if the class in quesion is CRearWiperControl and the function is EnableMotor()? return false works for me here.

    I've written a number of Windows services in my career, and 'just die' is never an option. (Same would apply to a *nix daemon process). The service/daemon should keep running, even it it hits an 'impossible' error processing a single request.

    Even in a simple web app, 'just die' isn't very elegant. The customer sees a blank page. Support has no clue what went wrong. Developers dismiss the bug report because they can't reproduce it.

    if(!this) return false; certainly is a WTF, but not because it's too defensive. It's not defensive enough. As already mentioned, you really want an assert here so you can catch these things during development. And throwing an exception is probably better than return false, assuming you have an exception handler in place somewhere up the stack. And make sure you log it if you can. assert is great but it disappears in your release build. Customers run release builds.

    So, 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.

  • sota (unregistered) in reply to lolwtf
    lolwtf:
    Code Dependent:
    Blob:
    Jerry:
    Josh's predecessor seemed to miss out on the fundamentals the request/response paradigm.
    ... while Josh, in turn, missed out on the fundamentals the English grammar.
    "of" has been deprecated
    Yes, "the" is now used in its place.
    What a load the nonsense. I'd rant about it, but I have to log thef.

    I see what you did there.

  • SubSubDelimit (unregistered) in reply to voyou
    voyou:
    paulm:
    SCJP:
    For those not familiar with Java:
    Boolean answer = new Boolean(inp);
    ...simply does the trick.

    Although,

    Boolean answer = Boolean.valueOf(inp);

    is even better, as it avoids pointlessly creating extra Boolean object instances.

    What's the difference? I would have thought they both created exactly one Boolean instance (but I don't have any great level of understanding of how Java's boxing works).

    The original test included inp.equals("true") so probably inp is of type String.

    Boolean answer = inp.equals("true"); // autoboxing

    or even better

    Boolean answer = inp.equalsIgnoreCase("true");

  • (cs) in reply to voyou
    voyou:
    What's the difference?

    Boolean.valueOf doesn't create any objects. The Boolean class has two static instances of Boolean (Boolean.TRUE and Boolean.FALSE). Boolean.valueOf returns one of the already existing objects.

  • Simon (unregistered)

    Some C++ compilers, if told not to use exceptions, will not return a null pointer if new fails - that function is explicitly defined to return an exception on error. It mainly comes up if you're overriding the memory allocation / deallocation functions for some reason, eg to track leaks or to deliberately corrupt memory or simulate tight constraints to make the code more robust.

    What tends to happen, at least under gcc 4, is that you end up with the stupid compiler calling an object's constructor even on a failure, because it expects you to be throwing an exception to stop it instead. But if you've got a product that requires legacy platform support then you generally can't use exceptions because they're not supported by all older C++ compilers. Not to mention that they make it harder to read code, and much more difficult to isolate things like memory leaks if you're not careful.

    Thus there are perfectly legitimate situations where checking that the this pointer isn't null is necessary. Probably putting it everywhere is overkill but it certainly won't be something the optimiser will remove.

  • Weps (unregistered) in reply to Pedant
    Pedant:
    Weps:
    Pedant:
    Bjarne Stroustrup uses "if (this==0)" twice on page 605 of "Programming: Principles and Practice using C++". It isn't needed in every method, but it isn't automatically a WTF.

    If he meant "if (this==NULL)" then it's definitly a wtf.

    What are you talking about? NULL and 0 are synonymous in C++.

    I guess you mean that NULL is defined as 0 (not always true), which is, I hope, done for a reason. Defining NULL, not it being equal to 0.

    Why not just say zero-pointer instead of null-pointer? Why invent the term null at all?

    Anyways, the wtf is knowing what the (pre)compiler makes of it and then applying that knowledge in the code, completely screwing any related human language agreement/convention.

  • Rob (unregistered)

    The "if (!this) return false" case is checking for method calls on null pointers. It's paranoid, probably eliminates some optimizations, and doesn't work when multiple inheritance is involved.

  • (cs) in reply to Weps
    Weps:
    Why not just say zero-pointer instead of null-pointer? Why invent the term null at all?
    The term “null” (used to indicate a pointer or reference that does not refer to an extant entity) has been around for a long time; it certainly predates C++ and may well predate C. In early systems, the null pointer was not necessarily a zero pointer; that's a later development...
  • Ahto (unregistered) in reply to Weps
    Weps:
    Pedant:
    Weps:
    Pedant:
    Bjarne Stroustrup uses "if (this==0)" twice on page 605 of "Programming: Principles and Practice using C++". It isn't needed in every method, but it isn't automatically a WTF.
    If he meant "if (this==NULL)" then it's definitly a wtf.
    What are you talking about? NULL and 0 are synonymous in C++.
    I guess you mean that NULL is defined as 0 (not always true), which is, I hope, done for a reason. Defining NULL, not it being equal to 0.

    Why not just say zero-pointer instead of null-pointer? Why invent the term null at all?

    Anyways, the wtf is knowing what the (pre)compiler makes of it and then applying that knowledge in the code, completely screwing any related human language agreement/convention.

    I guess you haven't really studied C++.

    Clause 4.10 of the current C++ standard says

    A null pointer constant is an integral constant expression (expr.const) rvalue of integer type that evaluates to zero. A null pointer constant can be converted to a pointer type; the result is the null pointer value of that type and is distinguishable from every other value of pointer to object or pointer to function type. Two null pointer values of the same type shall compare equal. The conversion of a null pointer constant to a pointer to cv-qualified type is a single conversion, and not the sequence of a pointer conversion followed by a qualification conversion (conv.qual).
    In fact, mostly the same holds for modern versions of C. Clause 6.3.2.3 of the current C standard says
    An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant.[55] If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
    Your claim applies only in pre-ANSI standard versions of C.

  • SCJP (unregistered) in reply to voyou
    voyou:
    paulm:
    SCJP:
    For those not familiar with Java:
    Boolean answer = new Boolean(inp);
    ...simply does the trick.

    Although,

    Boolean answer = Boolean.valueOf(inp);

    is even better, as it avoids pointlessly creating extra Boolean object instances.

    What's the difference? I would have thought they both created exactly one Boolean instance (but I don't have any great level of understanding of how Java's boxing works).

    You're right. There's no "extra" instance. Just the one the reference of which is assigned to the variable.

    You only have the choice between...

    * ...creating the instance explicitly, as it always has been in Java (with new) and assigning its reference to a variable

    * ...performing some function (valueOf, equals, equalsIgnoreCase) assigning a primitive value to an object reference(!) and let Java's implicit often spurned autoboxing create the object and assign its reference to the variable

    * ...deciding which code is more readable and quicker

  • Loren Pechtel (unregistered) in reply to ratchetr
    ratchetr:
    Loren Pechtel:
    The problem with the !this is not the test, it's what's done about it. On occasion it might make sense to return false if called on a null but that certainly shouldn't be the normal result. The desired result generally should be to die.
    Sudden death is hardly ever a good design decision. Software should degrade gracefully even when faced with impossible errors. (I'm assuming !this isn't an expected condition...that WOULD be a WTF.)

    What if the code in question is part of an engine management system? Do you want your car to just die while you're merging into rush hour traffic? Even if the class in quesion is CRearWiperControl and the function is EnableMotor()? return false works for me here.

    I've written a number of Windows services in my career, and 'just die' is never an option. (Same would apply to a *nix daemon process). The service/daemon should keep running, even it it hits an 'impossible' error processing a single request.

    Even in a simple web app, 'just die' isn't very elegant. The customer sees a blank page. Support has no clue what went wrong. Developers dismiss the bug report because they can't reproduce it.

    if(!this) return false; certainly is a WTF, but not because it's too defensive. It's not defensive enough. As already mentioned, you really want an assert here so you can catch these things during development. And throwing an exception is probably better than return false, assuming you have an exception handler in place somewhere up the stack. And make sure you log it if you can. assert is great but it disappears in your release build. Customers run release builds.

    So, 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.

    Throwing an exception IS a means of dying. Maybe something up the chain will handle it. Anything that MUST keep on going (your embedded systems example) certainly will handle it at the top.

    However, in general it's a lot better for a program to terminate than to continue on with obviously bad instructions.

  • SCJP (unregistered) in reply to SCJP
    SCJP:
    * ...performing some function (valueOf, equals, equalsIgnoreCase) assigning a primitive value to an object reference(!) and let Java's implicit often spurned autoboxing create the object and assign its reference to the variable
    Correction: Boolean.valueOf returns a reference to the static Boolean.TRUE or Boolean.FALSE, so doesn't create a new object.
  • grumpy (unregistered) in reply to Weps
    Weps:
    I guess you mean that NULL is defined as 0 (not always true), which is, I hope, done for a reason. Defining NULL, not it being equal to 0.

    Why not just say zero-pointer instead of null-pointer? Why invent the term null at all?

    Anyways, the wtf is knowing what the (pre)compiler makes of it and then applying that knowledge in the code, completely screwing any related human language agreement/convention.

    Nope, the C++ standard explicitly states that the constant expression 0 is a null pointer. And that is why NULL is, and will always be, #define'd as 0.

    Where it gets funky is that a null pointer may not necessarily correspond to the address zero. But if you assign zero to a pointer, that pointer becomes a null pointer. Even if this operation is implemented by storing a non-zero address into the pointer. And that is why it is not called a zero-pointer. As far as the language is concerned, it is not "a pointer to the address zero", but "a pointer that points nowhere".

    "I invented the term Object-Oriented and I can tell you I did not have C++ in mind." -- Alan Kay
    That quote has always annoyed me. It is a fundamental misunderstanding to assume that C++ is *meant* to be an object-oriented language. He might as well have said that he didn't have LISP, Haskell or Prolog in mind when he invented the term. It'd be true, and pretty uninformative in either case.

    I think one of C++'s biggest strengths is that it is not a strict OOP language.

  • (cs) in reply to Pedant
    Pedant:
    The real WTF is that someone thinks that "!this" is a WTF in C++. Please do us a favor and stay far away from C++ until you learn what you are doing.

    Bjarne Stroustrup uses "if (this==0)" twice on page 605 of "Programming: Principles and Practice using C++". It isn't needed in every method, but it isn't automatically a WTF.

    But it's not safe! You're not protecting yourelf from anything if you test for !this. You only create a false sense of security. Look.

    myclass* p; p->function();

    A common mistake. Now since pointers are not automatically initialised to 0, the "this" in the function has a random value. It doesn't help to test for !this.

  • Matt.C (unregistered)

    The best defense is a good offense!

  • (cs) in reply to grumpy
    grumpy:
    "I invented the term Object-Oriented and I can tell you I did not have C++ in mind." -- Alan Kay
    That quote has always annoyed me. It is a fundamental misunderstanding to assume that C++ is *meant* to be an object-oriented language. He might as well have said that he didn't have LISP, Haskell or Prolog in mind when he invented the term. It'd be true, and pretty uninformative in either case.

    I think one of C++'s biggest strengths is that it is not a strict OOP language.

    I'm pretty sure he had LISP in mind, since the first object systems were written in LISP.

    C++ was meant to be an object oriented language with support for a templating type system. You can read all about it on Bjarne's homepage.

    http://www.research.att.com/~bs/oopsla.pdf

    The ironically titled paper "Why C++is not just an Object-Oriented Programming Language" explains why. Most of the features Bjarne says make C++ "not purely object oriented" are now considered object-oriented. From the abstract:

    This paper briefly presents key programming styles directly supported by C++and argues that the support for multiple styles is one of its major strengths. The styles presented include: traditional C-style, concrete classes, abstract classes, traditional class hierarchies, abstract classes and class hierarchies, and generic programming. To provide a context for this overview, I discuss criteria for a reasonable and useful definition of ‘‘object-oriented programming.’’

    Which of the features Bjarne pointed out as not being OO do you not consider OO? Keep in mind you can write "C-style" code in any language. Even Haskell, a purely functional language.

    Generic programming is merely quantification over classes.

  • (cs) in reply to Pim
    Pim:
    Pedant:
    The real WTF is that someone thinks that "!this" is a WTF in C++. Please do us a favor and stay far away from C++ until you learn what you are doing.

    Bjarne Stroustrup uses "if (this==0)" twice on page 605 of "Programming: Principles and Practice using C++". It isn't needed in every method, but it isn't automatically a WTF.

    But it's not safe! You're not protecting yourelf from anything if you test for !this. You only create a false sense of security. Look.

    myclass* p; p->function();

    A common mistake. Now since pointers are not automatically initialised to 0, the "this" in the function has a random value. It doesn't help to test for !this.

    While it may be true that !this does not catch wild pointers (which are not guaranteed to be null), you should be initializing your pointers explicitly anyway (via myclass* p=NULL;, myclass* p=new myclass(<insert ctor args here>);, myclass* p=SomeFunctionThatReturnsAMyclassPointer();, etc.).

  • Weps (unregistered) in reply to grumpy

    I wrote "not always true" to indicate that in some versions NULL is defined as 0, and in some as a void* cast blabla something. It all means the same essentially. I know.

    Actually, I don't care what it is defined as, and neither should anybody. As long as I know that I can use NULL to test for null-pointers.

    But hey, I'm probably alone this....

    So to recap:

    Lets agree on pointers that point nowhere to call them null-pointers and not zero-pointers. Hell, let's make a define for NULL as well.

    And then, let's NOT use the define for NULL, but 0 in the code. Heck, it saves us 4 keypresses everytime!

    Hooray, we made things a lot more clearer now.

  • (cs)

    3!

  • (cs) in reply to 008
    008:
    Pim:
    myclass* p; p->function();

    A common mistake. Now since pointers are not automatically initialised to 0, the "this" in the function has a random value. It doesn't help to test for !this.

    While it may be true that !this does not catch wild pointers (which are not guaranteed to be null), you should be initializing your pointers explicitly anyway (via myclass* p=NULL;, myclass* p=new myclass(<insert ctor args here>);, myclass* p=SomeFunctionThatReturnsAMyclassPointer();, etc.).
    Yes. That's what you should do. And you should always call class members only when they're in valid instances. And you should refrain from using objects after "delete" has been called on the pointers to them. I know. We should, but we don't. We're all human. That's when defence mechanisms like that come in handy. I was just trying to say that it doesn't always work, and if people think it does, they're sticking their head in the sand.

  • (cs)
    if (!this) return false;
    As strange as it may sound, some versions of the Microsoft C++ compiler can have have a null this when you call a method on a null object pointer.

    Of course it might have been more helpful had it simply thrown an exception instead of masking the problem.

  • anon (unregistered) in reply to grumpy
    grumpy:
    Where it gets funky is that a null pointer may not necessarily correspond to the *address* zero. But if you assign zero to a pointer, that pointer becomes a null pointer. Even if this operation is implemented by storing a non-zero address into the pointer. And that is why it is not called a zero-pointer. As far as the language is concerned, it is not "a pointer to the address zero", but "a pointer that points nowhere".
    Just out of curiosity: How do you create a pointer to address 0 -- and what happens if you decrement a pointer to address 1?
  • (cs) in reply to anon
    anon:
    Just out of curiosity: How do you create a pointer to address 0 -- and what happens if you decrement a pointer to address 1?
    First, read something like http://en.wikipedia.org/wiki/C_memory_model. Then, use a far pointer.

    To decrement a NULL pointer, it helps to think of pointers as unsigned. So they don't have -1. They can be 0xFFFF, 0xFFFFF or 0xFFFFFFFF, depending on the memory model. Or even more Fs, if you have 64 bit addres space. (What's the name of the 64 bit memory model? It must be bigger than "huge".)

    Addendum (2009-05-17 05:43): Oh, I see I misread your second question. If you have a long pointer to the physical address 1, decrementing it would result in the physical address 0. That's not so hard.

    On the other hand, you have to keep the environment in mind. For instance, your C compiler might start to complain loudly if you want to make a pointer to an address that is not on a doubleword boundary. Or decrementing it would result in 0xFFFFFFFD. (MSVC 8 does the latter, but has no problems with the former.)

  • (cs) in reply to Weps
    Weps:
    I wrote "not always true" to indicate that in some versions NULL is defined as 0, and in some as a void* cast blabla something.
    Well, that's the problem - you're incorrect. And starting from an incorrect premise, the rest of your argument is worthless.

    In C++, unlike in C, in no case is NULL permitted to be defined as a void*. This is explicitly stated in the standard.

    18.1 Types, para 4: "The macro NULL is an implementation-defined C++ null pointer constant in this International Standard (4.10).180)

    1. Possible definitions include 0 and 0L, but not (void*)0."

    The reason for this is that defining NULL as ((void*)0) would break a large proportion of existing code, since such simple statements as char* ptr = NULL; would break.

  • ysth (unregistered) in reply to Pim
    Pim:
    3!
    6
  • Henning Makholm (unregistered) in reply to anon
    anon:
    Just out of curiosity: How do you create a pointer to address 0 -- and what happens if you decrement a pointer to address 1?
    That's implementation-defined as best -- everything that concerns actual addresses is.

    On most platforms that any programmer will ever meet, a null pointer is the same thing as a pointer to the address zero. It's just that the C standard does not guarantee that this will be the case, so an implementation that did it differently could still claim to implement ISO C.

    A hypothetical scenario where this might be desired would be if one had a platform where the system linker sometimes puts a variable at actual address zero (which arguably would be WTF, but imagine that we're stuck with the ABI). Because the address of a defined object must not be null, the C compiler would have to use another bit pattern for null pointers, for example by xoring with 0xFFFF at each cast between pointer and integer types.

  • Liel D (unregistered) in reply to Long
    Long:
    shadowman:
    Tom:
    Someone explain to me the javascript one. Is the WTF that the comment and the if (!confirmed) don't match? I'm going crazy trying to see what is wrong with this (maybe just because it is Friday...)

    The whole function is an unnecessary wrapper around

    var confirmation = confirm(message);

    It doesn't add anything beyond that one line.

    What if confirm() returns FILE_NOT_FOUND?

    In JavaScript confirm() will always display "OK" / "Cancel" buttons and return TRUE or FALSE. If I got the last part of the Custom_Confirm function described earlier right it works as a reverse confirm (returns true on Cancel and false on OK). The sad fact is you can always use ! to check for the opposite response, writing a function for this is... utterly stupid in real world systems).

  • Liel D (unregistered) in reply to Liel D
    Liel D:
    Long:
    shadowman:
    Tom:
    Someone explain to me the javascript one. Is the WTF that the comment and the if (!confirmed) don't match? I'm going crazy trying to see what is wrong with this (maybe just because it is Friday...)

    The whole function is an unnecessary wrapper around

    var confirmation = confirm(message);

    It doesn't add anything beyond that one line.

    What if confirm() returns FILE_NOT_FOUND?

    In JavaScript confirm() will always display "OK" / "Cancel" buttons and return TRUE or FALSE. If I got the last part of the Custom_Confirm function described earlier right it works as a reverse confirm (returns true on Cancel and false on OK). The sad fact is you can always use ! to check for the opposite response, writing a function for this is... utterly stupid in real world systems).

    Thinking a little bit more on the issue it seems to be a flaw in the User Interface thinking... confirm() should be used only to CONFIRM an action taken by the user, clicking Cancel should do exactly that (return false the the default action and therefor canceling it action).

    A simple use of this would be to confirm a link being clicked while a form has been edited but not saved ("You have unsaved changes, Dismiss and continue?")

  • Weps (unregistered) in reply to Bellinghman
    Bellinghman:
    Weps:
    I wrote "not always true" to indicate that in some versions NULL is defined as 0, and in some as a void* cast blabla something.
    Well, that's the problem - you're incorrect. And starting from an incorrect premise, the rest of your argument is worthless.

    Wake me up when you find the premise. If ever.

  • (cs) in reply to Henning Makholm
    Henning Makholm:
    On most platforms that any programmer will ever meet, a null pointer is the same thing as a pointer to the address zero.
    True, these days. But there was a time when a data pointer could be a 16-bit pointer into the 16-bit data segment, which didn't necessarily reside at physical location 0000:0000. I mean, an address like 3E00:0000 would be a NULL address.
    Henning Makholm:
    A hypothetical scenario where this might be desired would be if one had a platform
    Hypothetical? No, no. Real! 8086!
    Henning Makholm:
    the C compiler would have to use another bit pattern for null pointers, for example by xoring with 0xFFFF at each cast between pointer and integer types.
    So 65535 would become a NULL pointer? No, that's not how it works, sorry.

Leave a comment on “Defensive Programming and a Whole Lot More”

Log In or post as a guest

Replying to comment #:

« Return to Article