Holes discovered in SSL certificate validation

Posted Nov 2, 2012 7:21 UTC (Fri) by cmccabe (guest, #60281)
In reply to: Holes discovered in SSL certificate validation by zlynx
Parent article: Holes discovered in SSL certificate validation

I'm glad that C++ finally introduced a version of enums that doesn't decay to ints. I probably will use that in the future if I'm writing C++0x code.

Still, I feel that it is unfair for you to criticize C for containing the bug referenced by the poster. C doesn't have a bool type, so there is no way that anyone could pass 'true' in a place where an enum was expected.

In my experience, C++'s addition of bool was not a good idea. The fact that any type of pointer implicitly converts to bool is the source of much hilarity when novices try to write C++ code. That problem does not exist in C because the numeric types there never implicitly convert to pointers.

to post comments

Holes discovered in SSL certificate validation

Posted Nov 2, 2012 18:07 UTC (Fri) by zlynx (guest, #2285) [Link] (3 responses)

No, C does not have a boolean type. That doesn't change much though because pointers do get treated as boolean values.

It is very common to write if(pointer) { use(pointer); } in C code. That is a pointer being used as a boolean.

I think that you must have gotten confused about the pointer conversions somewhere. There aren't any cases in any version of C or C++ where a numeric type converts into a pointer silently.

Holes discovered in SSL certificate validation

Posted Nov 2, 2012 22:00 UTC (Fri) by nix (subscriber, #2304) [Link] (1 responses)

There aren't any cases in any version of C or C++ where a numeric type converts into a pointer silently.

Um, 0 in pointer context is the null pointer constant. (Sure, it doesn't apply to any other values of integral type, but still.)

Holes discovered in SSL certificate validation

Posted Nov 3, 2012 1:14 UTC (Sat) by nybble41 (subscriber, #55106) [Link]

>> There aren't any cases in any version of C or C++ where a numeric type converts into a pointer silently.
> Um, 0 in pointer context is the null pointer constant.

It's not just the value; in C99, at least, only an _integer constant expression_ with the value zero, or the same cast to (void*), can be implicitly converted to a null pointer. Any other expression with numeric type will not be implicitly treated as a null pointer, even if the value happens to be zero. GCC treats this as an integer-to-pointer conversion without a cast and generates a warning by default.

Granted, "false" from <stdbool.h> is a macro defined as the integer constant 0, so it can be converted to a null pointer. However, the null pointer is treated as false in a boolean context, so that isn't so very surprising.

Holes discovered in SSL certificate validation

Posted Nov 11, 2012 18:41 UTC (Sun) by cmccabe (guest, #60281) [Link]

Here is an example.

> #include <stdio.h>
> void dostuff(bool foo) {
> printf("foo = %d\n", foo);
> }
> int main(int argc, char **argv) {
> dostuff(argv);
> }

Compiles with no errors on -Wall, produces "foo = 1"

Change the bool to int and you get:

example.c: In function ‘main’:
example.c:6:3: warning: passing argument 1 of ‘dostuff’ makes integer from pointer without a cast [enabled by default]
example.c:2:6: note: expected ‘int’ but argument is of type ‘char **’

Conclusion: the C method is safer than the C++ method.

Start combining this with things like function overloading and default parameters, and what little type safety you had tends to evaporate. Take it from a C++ programmer for many years.