Hacker News Reader

Comment by mhogomchungu | Hacker News Reader

The bug here is probably with encfs and most frontend tools to enc are doing exactly what cryptkeeper is doing.

For those who want alternative to cryptkeeper,there is SiriKali[1], next version will be released on Feb 1st and it will have support for OSX.

    execlp ("encfs", "encfs", "-S", crypt_dir, mount_dir, NULL);

That line of code also has a bug as its wrong to pass NULL in C++ to a variadic function. IMHO,usage of NULL in C++ should be strongly discouraged in all cases.

[1] https://github.com/mhogomchungu/sirikali

View on HN

Incorrect. execlp requires a NULL to terminate the argument list. How else would the called function know when to stop processing arguments?

To quote the linux man page, "The list of arguments must be terminated by a NULL pointer...".

The original paster didn't say that a null pointer was incorrect, merely that using NULL in C++ was. Which, in recent versions of C++ it certainly is. The correct way to specify a null pointer in C++ is 'nullptr', NULL has been deprecated because it's definition '(void*)0' leads to typing issues for templates.

In C++, `NULL` is defined as a simple 0 without the `void*` cast.

No, that's exactly wrong (in this case).

For variadic C functions, you MUST use 0 (or NULL, which is the same as 0). Passing nullptr will case abort() to be called (as is the case whenever you pass a C++ class into a variadic function).

Reply (to myself, based on a correction)

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.

There isn't a guarantee that NULL has a bit pattern that's the same as a true (void)0 C-style null pointer either.

I didn't look it up directly but apparently NULL is allowed to be nullptr instead of 0, and nullptr converts to void in varargs arguments.

I think C/C++ also allow actual null pointers to have different bit patterns than the integer zero, so in C++03 passing NULL to terminate a varargs argument list would technically be incorrect, or maybe implementation-defined.

Damn, there is a special exception in the definition of vararg functions, just for nullptr! throws things in the air I give up having discussions about C++.

I give up too, because the HN formatting is actively fighting me.

nullptr, I believe, is compatible with C interfaces (as is simply passing 0) while not suffering from the issues described here.

What are the semantic/grammatical/"magical" differences between 0 and NULL?

I understand their similarity in terms of NULL's equivalence to memory address 0 and boolean false, but I'm increasingly aware that there's some hidden behavior.

Does NULL strictly resolve to '(void * )0', or can it be influenced by anything else?

Also, does it behave differently in C vs. C++? I suspect it might.

EDIT: Someone else just replied close to this thread chain just said it's defined in C++ as 0 without '(void * )'. If anyone can expand on this that would be awesome.

sizeof(NULL) in 4 in C++ in a 64 bit system.

sizeof(NULL) is 8 in C in a 64 bit system.

The difference is because NULL in C is a variable of a void pointer type with a value zero. In C++,NULL is a variable with a value zero that gets deduced to an int type.

That's not true. sizeof(NULL) is the same in C++ and C:

https://goo.gl/WL1akj

I looked up at my g++ compiler and i found this: http://pastebin.com/VpSsEkBY

That g++ compiler is using a gnu extension through the __GNUG__ code path. The "true" C++ code path is at line 11.

Edit:

Answering the person below,the file that defines NULL is "stddef.h"

An example of the file online that defines NULL is here: https://github.com/Alexpux/mingw-w64/blob/d0d7f784833bbb0b2d...

What file are we supposed to be looking at?

I looked into this.

#include <iostream>

int main() { std::cout << "sizeof(NULL) = " << sizeof(NULL) << '\n'; }

Compiling with both g++ 6.2.1 and clang++ 3.9.1 with -std=c++11 in both cases gives: sizeof(NULL) = 8

AFAICT, NULL should not even be defined at all in C++ 11; certainly if you include neither <stddef.h> nor <stdlib.h> nor <cstddef> nor <cstdlib>.

I could never get it to compile on x86_64 linux without saying 8.

Bottom line: NULL works in the execlp call, whether from C or from C++. nullptr would be cleaner.

fwiw, in C++11 onwards, apparently NULL is allowed to be nullptr and not an integral constant.

No, that's wrong!

You can't pass nullptr to a variadic function. It causes a run-time call to abort. You can pass 0, or NULL (which is just a macro defined to 0).

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~"

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.

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.

>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 ?

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");
    }

> 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?

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.

> 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 :)

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...)

Wow, so many wrong answers in this subthread.

From the execlp manpage: "The list of arguments must be terminated by a null pointer, and, since these are variadic functions, this pointer must be cast (char *) NULL."

Using bare "NULL" or "nullptr" in this context is wrong (although you might get away with the former on many platforms).

Reply on news.ycombinator.com