3 ms·

That would be pretty surprising if true, but it's not: #include <unistd.h> int main() { execlp("ls", "ls", nullptr); } g++ -std=c++11 -o x x.cpp "cpp cpp.c

by fnj 10y ago

That would be pretty surprising if true, but it's not: #include <unistd.h> int main() { execlp("ls", "ls", nullptr); } g++ -std=c++11 -o x x.cpp "cpp cpp.cpp cpp.cpp~ cryptkeeper q q.c q.c~ q.cpp q.cpp~ x x.cpp x.cpp~"

CJefferson 10y ago
Apologises, I mis-remembered the rule -- it is only C++ types which have a non-trivial destructor which cause an abort when you pass them to a variadic funciton. HOWEVER. This is still undefined behaviour. nullptr is an object of type std::nullptr_t. When you pass it to execlp, it just gets pushed through as a bit-pattern (as with any type passed to a variadic C function), and there is no guarantee what comes out looks like a "true" (void*)0 C-style null pointer. EDIT: On further inspection, both g++ and clang++ on mac (and I'd guess on linux) choose to pass 'nullptr' to variadic functions as an 8-byte all-0 value. That makes sense -- it makes it easier to implement nullptr I guess if you treat it as a null pointer! But, that's not required behaviour by the standard, I could make nullptr internally be any mess of values I like.
- palunon 10y ago
  >But, that's not required behaviour by the standard, I could make nullptr internally be any mess of values I like. But compiler writers usually aren't trying to go out of their way to trip you up. Can you provide an example of a compiler where nullptr doesn't have a 0 bit pattern ?
  - CJefferson 10y ago
    No, but once you start invoking undefined behaviour, all bets are off. For example, there are compilers that print nothing for the following function, with uninitialised 'i', whereas some programmers assume that i must take "some value", so one of A and B will be printed. int func() { int i; if(i > 0) printf("A"); if(i <= 0) printf("B"); }
- jjnoakes 10y ago
  > When you pass it to execlp, it just gets pushed through as a bit-pattern No, it doesn't. It goes through a proper conversion to a pointer. > [passing nullptr and getting 0 out of va_arg is] not required behaviour by the standard Yes, it is. See C++11 and C++14 standards, section 5.2.2 paragraph 7. You've been all over this thread shouting at people about how wrong they were, and even in your correction you are still mistaken. Please try to refrain from that in the future; lots of people reading these threads are going to be very confused about what is technically correct here, and I'm not willing to go reply to all of them. Perhaps some edits and/or deletes are appropriate?
  - CJefferson 10y ago
    You are right, I learnt this stuff in a C++0x draft, and it has been notably improved. I'm not discussing C++ minutiae in future, I've learnt my lesson. Ycombinator allows neither edits or deletions after a short amount of time it seems.
    - jjnoakes 10y ago
      > I learnt this stuff in a C++0x draft, and it has been notably improved. I guess the lesson is: don't yell at people if you aren't up-to-date on what you are yelling about :)
      - CJefferson 10y ago
        Yes, yes, I agree. In my defence, I thought I was up to date. I did know all about how C++ and varargs interact, I was just unaware there was a specific addition to varargs just for nullptr, and I'll be honest it didn't even occur to me to check! While I agree it's a sensible feature, it's also (for me) been the final straw on giving up on understanding C++ (not using, but understanding...)

by fnj 10y ago

CJefferson 10y ago

Apologises, I mis-remembered the rule -- it is only C++ types which have a non-trivial destructor which cause an abort when you pass them to a variadic funciton. HOWEVER. This is still undefined behaviour. nullptr is an object of type std::nullptr_t. When you pass it to execlp, it just gets pushed through as a bit-pattern (as with any type passed to a variadic C function), and there is no guarantee what comes out looks like a "true" (void*)0 C-style null pointer. EDIT: On further inspection, both g++ and clang++ on mac (and I'd guess on linux) choose to pass 'nullptr' to variadic functions as an 8-byte all-0 value. That makes sense -- it makes it easier to implement nullptr I guess if you treat it as a null pointer! But, that's not required behaviour by the standard, I could make nullptr internally be any mess of values I like.

palunon 10y ago
>But, that's not required behaviour by the standard, I could make nullptr internally be any mess of values I like. But compiler writers usually aren't trying to go out of their way to trip you up. Can you provide an example of a compiler where nullptr doesn't have a 0 bit pattern ?
- CJefferson 10y ago
  No, but once you start invoking undefined behaviour, all bets are off. For example, there are compilers that print nothing for the following function, with uninitialised 'i', whereas some programmers assume that i must take "some value", so one of A and B will be printed. int func() { int i; if(i > 0) printf("A"); if(i <= 0) printf("B"); }
jjnoakes 10y ago
> When you pass it to execlp, it just gets pushed through as a bit-pattern No, it doesn't. It goes through a proper conversion to a pointer. > [passing nullptr and getting 0 out of va_arg is] not required behaviour by the standard Yes, it is. See C++11 and C++14 standards, section 5.2.2 paragraph 7. You've been all over this thread shouting at people about how wrong they were, and even in your correction you are still mistaken. Please try to refrain from that in the future; lots of people reading these threads are going to be very confused about what is technically correct here, and I'm not willing to go reply to all of them. Perhaps some edits and/or deletes are appropriate?
- CJefferson 10y ago
  You are right, I learnt this stuff in a C++0x draft, and it has been notably improved. I'm not discussing C++ minutiae in future, I've learnt my lesson. Ycombinator allows neither edits or deletions after a short amount of time it seems.
  - jjnoakes 10y ago
    > I learnt this stuff in a C++0x draft, and it has been notably improved. I guess the lesson is: don't yell at people if you aren't up-to-date on what you are yelling about :)
    - CJefferson 10y ago
      Yes, yes, I agree. In my defence, I thought I was up to date. I did know all about how C++ and varargs interact, I was just unaware there was a specific addition to varargs just for nullptr, and I'll be honest it didn't even occur to me to check! While I agree it's a sensible feature, it's also (for me) been the final straw on giving up on understanding C++ (not using, but understanding...)