[QUOTE="Robbie Brown"]\n[QUOTE]\n[QUOTE="Helmut Tessarek"]\nOn 21.01.14 7:33 , Robbie Brown wrote:\ncheck out my mail signature. it will also answer your question.\n\n[...]\n/*\nThou shalt not follow the NULL pointer for chaos and madness\nawait thee at its end.\n*/[/QUOTE]\n\nGood advice, but not actually relevant in this case.\n\nThe OP *expected* a segmentation fault on dereferencing a null pointer.\nThe problem was that the pointer object in question was uninitialized,\nand therefore might or might not contain a null pointer value.[/QUOTE]\n\nYes, I'm starting to get the impression that, unlike other languages I\nhave used, C (or rather the C compiler perhaps) doesn't stop you from\ndoing all manner of exceptionally stupid things.[/QUOTE]\n\nYes. Another interesting, um, feature of C is that the syntax is what I\nthink of as "dense". What that means is that a single-character typo in\nan otherwise correct C program can easily produce something that's\nperfectly correct as far as the compiler is concerned, but has\ncompletely different behavior.\n[QUOTE]\nFor example, for no other reason that experimentation I tried to get my\nhead around pointers to pointers and came up with the following.\nTrying hard not to make assumptions, just observations.\n\n[Linux 3.2.0-23-generic x86_64 GNU/Linux]\n\nint **arpi = (int**) malloc(sizeof(int*) * 5);[/QUOTE]\n\nA good idiom for malloc that mostly avoids type mismatches is:\n\nint **arpi = malloc(5 * sizeof *arpi);\n\nCasting the result of malloc is unnecessary and can mask errors in some\ncases. Applying sizeof to *arpi (more generally, to what the LHS points\nto) ensures that you have the correct size and type without having to\nrepeat the type name.\n[QUOTE]\n*(arpi + 4) = malloc(sizeof(int));[/QUOTE]\n\nProbably better written as:\n\narpi = malloc(sizeof *(arpi));\n[QUOTE]\n*(*(arpi + 4)) = 14;[/QUOTE]\n\n*(arpi) = 14;[QUOTE]\nIf I run this through gdb I can see what I expected to see (there's that\nword again, what other word can I use?).\n\narpi is a pointer to the first of 5 64 bit addresses.\nthe first 4 addresses contain 0x0000000000000000 I hope I understand\nthat these are uninitialized addresses ... or maybe they have been\ninitialized to 0 by some voodoo priest :-) anyway[/QUOTE]\n\nmalloc returns a pointer to uninitialized memory. The contents might\nhappen to be all bits zero, but that's not guaranteed, and you shouldn't\nrely on it. And the null pointer is very commonly represented as\nall-bits-zero, but that's not guaranteed either.\n[QUOTE]\nthe fifth address contains the 64 bit address 0x0000000000602010\nthis seems reasonable as I malloc'd enough space for a pointer to int.\nif I inspect the contents of 0x602010 I see 0x0e which is (I hope) what\nI was expecting \nYes.\n\nThen it got all strange again\n\nI changed the first line to\nint **arpi = (int**) malloc(sizeof(int) * 5);\n\nnow I malloc int instead of int*\nCompile, run, inspect, same old results\nI think this works because an int is probably 64 bits same as an address\n(gross assumption)[/QUOTE]\n\nYes, that's the kind of type mismatch that can be avoided by the idiom I\nsuggested above.\n[QUOTE]\nThen it gets weirder\nint **arpi = (int**) malloc(0);\nNow realistically what should I 'expect' to happen\n\nI sort of expected it not to compile ... wrong, it compiled[/QUOTE]\n\nI'm not sure why you'd expect it not to compile. malloc is a library\nfunction, not a built-in language feature. It takes an integer argument\n(specifically an argument of the unsigned integer type size_t), and\nyou've called it with an integer value. Even if 0 were not a valid\nargument value, it's of the right type (or rather, is implicitly\nconvertible to the right type), so there's nothing for the compiler to\ncomplain about. The run time behavior may be another matter; as James\nKuyper already explained, the behavior of malloc(0) is\nimplementation-defined.\n[QUOTE]\nI sort of expected it to blow up ... wrong, ran and exited normally\nI even found 0x0e lurking about almost where I hoped it would be.\n\ngdb exposed the memory and it was obviously not right but it still ran.[/QUOTE]\n\nIt's likely that malloc(0) allocated some small amount of memory from\nthe heap (it could have returned a null pointer, but then your program\nprobably would have crashed). The actual amount of memory allocated for\nmalloc(N) is likely to be a bit bigger than N, but you can only safely\naccess the first N bytes (and only if malloc(N) actually succeeded).\nBut if you try to access memory beyond those first N bytes, you're\n*probably* still accessing memory within your program's memory space.\nThe behavior is undefined, but that doesn't mean it's going to crash;\nif you're *unlucky*, it will appear to "work".