Is my C++ compiler broken?

This is a discussion on Is my C++ compiler broken? within the C++ Programming forums, part of the General Programming Boards category; Originally Posted by Elysia I certainly agree that you should be unable to assign NULL to a non-pointer. Using an ...

  1. #46
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    Quote Originally Posted by Elysia View Post
    I certainly agree that you should be unable to assign NULL to a non-pointer. Using an explicit cast to make it work is an evil workaround and I'm not sure such a thing should be allowed.
    hand-holding? no thanks, if I wanted a compiler that assumes I'm stupid, I'll use javac.

    To test out the last bit of your theory:
    Code:
    #include <cstdlib>
    #include <cstring>
    int main(){ memset(0, (int)(long)(int)NULL, 0);}
    this compiles fine, so if it were overloading (int), it would have caught it there as well.

    I guess I should take this up with the gnu/mingw mailing threads... I mean what possibly logical explanation could explain why
    Code:
        memset(0, (int)(long)(int)NULL, 0); // this works
        memset(0, (int)NULL, 0); // and this does not

  2. #47
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,543
    Why are you so obsessed with this? NULL is not meant to be an integer, and nullptr even less so.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  3. #48
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,494
    > which expands to an implementation-defined null pointer constant;
    Which basically means, use it in a non-pointer context (say the 2nd param of memset), and you code is broken.

    You shouldn't care whether NULL is
    0
    (void*)0
    nullptr

    If you do, write better code. It's not like 0 is hard to write or anything.

    Likewise, all the "works for me" casts of NULL which you've found to work also add nothing to the validity of your statements.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #49
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    If it's all that important to you, though, here's the main GCC mailing list and here's the GCC bugzilla. You're welcome to bring your issue up with the people who actually write GCC. Don't be surprised if your bug is closed as WONTFIX, though.

    A better bug to bring up would be "__nullptr should warn on conversion to any non-pointer type, not just int".
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  5. #50
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    Quote Originally Posted by @nthony View Post
    hand-holding? no thanks, if I wanted a compiler that assumes I'm stupid, I'll use javac.

    To test out the last bit of your theory:
    Code:
    #include <cstdlib>
    #include <cstring>
    int main(){ memset(0, (int)(long)(int)NULL, 0);}
    this compiles fine, so if it were overloading (int), it would have caught it there as well.

    I guess I should take this up with the gnu/mingw mailing threads... I mean what possibly logical explanation could explain why
    Code:
        memset(0, (int)(long)(int)NULL, 0); // this works
        memset(0, (int)NULL, 0); // and this does not
    And? What is the point you are trying to establish? This is not a bug nor is it a logical way to write code. The problem seems to lie between the desk and chair.

  6. #51
    Registered User
    Join Date
    Jun 2005
    Posts
    6,261
    Quote Originally Posted by CornedBee View Post
    A better bug to bring up would be "__nullptr should warn on conversion to any non-pointer type, not just int".
    I agree with this. @anthony, you seem to be arguing that since the conversion is supported for char and long, it should also be supported for int. I consider it should not be supported for int either, as I cannot envisage any circumstance where a sane programmer would want to use such a construct.

    There is an important difference between a compiler that avoids excessive hand-holding, and a compiler that is designed to allow insane coding practice. The former allows things to be done practically, but relies on the programmer using the features in a sane manner; the latter simply is simply permissive to the point of insanity if done without justification. You are asking for the latter.

  7. #52
    Banned master5001's Avatar
    Join Date
    Aug 2001
    Location
    Visalia, CA, USA
    Posts
    3,685
    The only time I see this being an issue is if you have a situation like this:

    Example:
    Code:
    #define NULL_PTR  0
    #define NULL_NODE (void *)NULL_PTR
    #define INVALID_NODE_HANDLE (long)NULL_NODE
    
    // later in your code
    int i = (int)INVALID_NODE_HANDLE;
    Which is a realistic way something like this could arise. One can still argue that it is up to the programmer to write cleaner code, but the point is the programmer may not necessarily realize what happened with their casts.

  8. #53
    Registered Abuser
    Join Date
    Jun 2006
    Location
    Toronto
    Posts
    591
    Quote Originally Posted by Salem View Post
    If you do, write better code. It's not like 0 is hard to write or anything. Likewise, all the "works for me" casts of NULL which you've found to work also add nothing to the validity of your statements.
    Some people still aren't getting the point: it's not about NULL, it's about the compiler behaving inconsistently across cases where its behaviour should be identical. See below.

    Quote Originally Posted by grumpy
    I agree with this. @anthony, you seem to be arguing that since the conversion is supported for char and long, it should also be supported for int.
    That right there is the point. The consistency is lacking, albeit in a very fringe case. In lieu of response from the mailing list, I think it's safe to say the compiler is broken in that regard.

  9. #54
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,636
    Quote Originally Posted by grumpy
    The reason, as suggested by Elysia, is probably that a conversion to int has not been implemented, but a conversion to char or long has. It is possible to get the same effect fairly easily with standard C++ too.
    Compiling your example code, I found that MSVC8 did indeed emit an error, as I thought would be the case. However, both the Comeau online compiler and the MinGW port of g++ 3.4.5 did not even emit a warning. Even after consulting the C++ Standard, I am not sure who is correct, but perhaps those two compilers treated it as an implicit conversion to char (or long), followed by an explicit conversion to int.

    Quote Originally Posted by @nthony
    That right there is the point. The consistency is lacking, albeit in a very fringe case. In lieu of response from the mailing list, I think it's safe to say the compiler is broken in that regard.
    Has a bug, maybe. Broken, no, since it is only an inconsistency in generating warnings.

    EDIT:
    Then again, it does seem that MSVC8's error message is correct since both the conversion to char and the conversion to long is equally viable (as I understand the rules), so there is ambiguity. The MinGW port of g++ 3.4.5 chooses to convert to char. I do not actually have the Comeau compiler, so I cannot observe what it does.
    Last edited by laserlight; 10-12-2008 at 01:37 AM.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  10. #55
    Registered User
    Join Date
    Jun 2005
    Posts
    6,261
    Quote Originally Posted by @nthony View Post
    That right there is the point. The consistency is lacking, albeit in a very fringe case. In lieu of response from the mailing list, I think it's safe to say the compiler is broken in that regard.
    Broken may be a bit lavish.

    In any event: take CornedBee's suggestion: go to the gcc mail list or gcc bugzilla, and suggest "__nullptr should warn on conversion to any non-pointer type, not just int".

    That will make the compiler behave in a consistent manner - and be helpful to programmers who make the type of silly mistake embodied in your "fringe case".

    However, if your point is that consistency of the compiler is so important that the compiler should not report programmer errors that it can detect - which is what you seem to be suggesting - I consider you're barking up the wrong tree unless you can provide one practical example in which it is necessary to shut the compiler up in this case. By "practical example" I mean that there is a real-world problem that cannot be solved in any other way. A academic argument that "what the programmer says should go, even if the programmer is wrong" is insufficient.
    Last edited by grumpy; 10-12-2008 at 01:44 AM.

  11. #56
    Registered User
    Join Date
    Jun 2005
    Posts
    6,261
    Quote Originally Posted by laserlight View Post
    Compiling your example code, I found that MSVC8 did indeed emit an error, as I thought would be the case. However, both the Comeau online compiler and the MinGW port of g++ 3.4.5 did not even emit a warning. Even after consulting the C++ Standard, I am not sure who is correct, but perhaps those two compilers treated it as an implicit conversion to char (or long), followed by an explicit conversion to int.
    My guess would be that, for those compilers, long and int are the same types (I've yet to hear of a compiler where int and char were the same types, but suppose that is not beyond realms of possibility). Easy way to test that: add an operator int() - you will get one or more complaints from the compiler (either ambiguity, or something about duplicate operators). Alternatively, compare sizeof those types.

    Generally, if I was seeking to implement conversion operators for a class X to all integral types, I would avoid conversions to signed or unsigned int (signed/unsigned int is typically equivalent to either its short or long counterpart) or to char (it is implementation-defined whether char is signed or unsigned char).
    Last edited by grumpy; 10-12-2008 at 03:04 AM.

  12. #57
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    There is definitely no halfway recent compiler that won't be able to overload on int vs long, i.e. that treats them as canonically the same type internally.

    My guess is that GCC and Comeau automatically prefer to conversion via char because it's guaranteed to have no data loss (under the assumption that the user-supplied operator doesn't cause data loss, which the compiler cannot know).

    A check with the standard confirms this. The conversion char->int is an integral promotion, whereas long->int is a conversion. This makes Foo->char->int a better conversion than Foo->long->int, and overload resolution thus chooses the Foo->char operator.
    See 13.3.3/1 (Best Viable Function) and 13.3.3.1.1 (Standard Conversion Sequences).

    The fault lies with MSVC for not correctly implementing function overloading.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  13. #58
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Would it matter if you're compiling 32-bit vs 64-bit? Since pointers would be 64-bit but and int might be 32-bit, so then the compiler would warn you that your target type isn't big enough...
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

Page 4 of 4 FirstFirst 1234
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Compiler Paths...
    By Cobra in forum C++ Programming
    Replies: 5
    Last Post: 09-26-2006, 04:04 AM
  2. C Compiler and stuff
    By pal1ndr0me in forum C Programming
    Replies: 10
    Last Post: 07-21-2006, 11:07 AM
  3. I can't get this new compiler to work.
    By Loduwijk in forum C++ Programming
    Replies: 7
    Last Post: 03-29-2006, 05:42 AM
  4. how to call a compiler?
    By castlelight in forum C Programming
    Replies: 3
    Last Post: 11-22-2005, 10:28 AM
  5. Help With finding a compiler
    By macman in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 04-15-2005, 08:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21