Again with the deliberately awkward interpretations. A pointer identifies a location in memory. The pointer's type gives the size of each item; the actual number of items (which can be zero) is not recorded anywhere. In the case of a void pointer either there is one item of size zero, or zero items of any size; take your pick. Either way it means "no data at this location". The existence of a pointer doesn't imply that there is anything at that location. Consider:

int array[10];
int *p = &array[10];

The variable p is a pointer to a location in memory, but it's past the end of the array. The item size is sizeof(int), but the number of items is zero. The code is perfectly legal—you're allowed to have a pointer to the location just past the end of an array—but there is nothing there. There may not even be a virtual memory mapping for that location.

The only difference between p and a void pointer, aside from pointer arithmetic, is that the compiler won't stop you from dereferencing p; you'll just get a runtime error, if you're very, very lucky.

Perhaps because we already have this perfectly usable pointer syntax, which identifies both an address and a type, and rather than make up a completely separate "address" type and special-case everything for no reason we can just use a pointer to the existing "void" type, which already means "no data", because if we don't know the type of the data it might as well not exist as far as the compiler is concerned.

Anyone who really wants an "address" keyword for personal reasons can just write "typedef void *address".

No, it doesn't point to anything. It's just an address. If it pointed to something then that something would have a well-defined (non-zero) size and type.

It should be, but some ancient versions of C allowed pointer arithmetic on void pointers as though they were pointers to bytes or characters, and support for this was retained, at least in the compiler if not the standard, for backward compatibility. The sizeof operator is defined such that (char*)(p + 1) == ((char*)p + sizeof *p), which implies that sizeof(void*) must equal sizeof(char*) for the pointer arithmetic to work out the same. No modern, well-behaved program should be doing pointer arithmetic with void pointers or using sizeof(void).

We know, but that knowledge is not represented by the void pointer type. The type says "nothing is there", and we have to override that with a typecast to say that there is something there after all.

It really seems like you want the use of "void" to be inconsistent, and are deliberately choosing an awkward interpretation (undefined type vs. the more obvious empty type) in order to make it so. The use of "void" meaning "nothing there" is perfectly consistent between void pointers, void functions, and void expressions.

Not this again. We have millions of registered guns in Australia. We like our huntin' too. But handguns and automatic weapons have never been a part of the culture.

That has nothing do do with our silly laws. It would be the same in NZ or US - if you were negligent and did not follow required standards, your insurance would be lost. And in neither case would there likely be criminal charges, let alone jail. It would have to be arson for that.

Yeah, so quick it happened decades ago.

Maybe I missed a joke, but it is illegal to change you own light socket or switch in Australia, instead of calling a licensed electrician.
But there is nothing to stop you buying the parts from the local hardware store, and I never heard of anyone being prosecuted.

citation please.

Because, as far as the type is concerned, it is a pointer to nothing. Given just a void pointer, the only safe assumption is that there is nothing there. It's like a pointer to a zero-length array or an empty structure. You have to perform a typecast, and thus tell the compiler that there is actually something there, before you can do anything with it.

Here's the equivalent C/C++/Java code:

so(that(can(understand(non(dweebs), your(program)))), is(necessary(syntax)));

Was that any easier to read?

You don't actually need to encrypt the shared key; a simple XOR of the pads from each piece of glass will do:

combinedKey = xor(glassAlice, glassBob)
publishToInternet("http://repository/combinedKeyId", combinedKey)

For Alice to send a message:

combinedKey = getFromInternet("http://repository/combinedKeyId")
glassBob = xor(combinedKey, glassAlice)
cipherText = xor(plaintext, glassBob)

For Bob to decode:

plaintext = xor(ciphertext, glassBob)

The result of the XOR only tells you whether a given bit is the same or different between the two pads, which, by itself, doesn't tell you anything about either pad, so the XOR can be made public. Combined with one of the pads, however, it allows you to infer the value of the other so that you can send your message. Normally each party would just have a copy of the same pad, but this approach gets around the difficulty of creating two pieces of glass with precisely equal (random) optical properties.

wonder what the username and passwords for electrical grid employees are going for...

well as long as you license the patent for quantum software robot from me, its all good
oh and might as well tell you about the DRM requirement ;)

easily explained by a bad search result on medication interaction...!!

I for one vote for cyborg data center staff...

maybe they can use a quantum software robot, surely that's the answer