For a distribution that "doesn't have an installer", they certainly use the word "install" a lot in the Installing Gentoo document.
Most of my open soruce work is with lower level tools like xml parsers and version control systems
How much of the time "spent... working on and tweaking my linux system to get it up to the usability stanadards of os x" could have been spent working on those tools, instead? That, as far as I'm concerned, is one of the biggest reasons why even hardcore hackers should support having the OS and desktop environment Just Work, whenever possible.
How many of the tweaks were either application source tweaks (which should be fed back to the developers - or, if they represent personal tweaks, perhaps fed back after being made settable preferences) or configuration file tweaks (in which case, should that setting of the configuration file be the default - or be settable from your favorite desktop environment's configuration app?)?
I'm definately a hardcore hacker and I spent the last two weeks working on and tweaking my linux system to get it up to the usability stanadards of os x.
Hopefully in ways that can be incorporated by whatever distribution you're using, so that, in the future, said distribution can work that way as installed.
Control+F2 to give the menu bar the input focus, tab to the appropriate menu, Space to open the menu, cursor arrows to move up or down or a letter to select the first menu item(?) beginning with that letter, Esc to dismiss the menu, Return or Enter to activate the item.
Not quite as quick as the Windows-and-many-UNIX+X-toolkits Alt+{accelerator for a menu} to directly pop up the menu in question, but at least it's something.
They present a new piece of Free Software, that is supossed to help the hacker community, and they use proprietary software (Flash) to show the software to the public?
Can any code using GPLFlash play that demonstration? Or does it use features not supported by GPLFlash?
I've been thinking recently about the direction of computing, it seems everything is 'going serial'. SCSI, ATA, FireWire, HyperTransport, USB, these are all serial protocols. It's time an OS focused on having fantastic and robust serial capabilities, and defined the various busses as limits against the entire set of capabilities. Maybe this is getting more towards the microkernel state of mind, but shouldn't all the serial protocols share a command set as far as the kernel is concerned?
(I'm not sure what that has to do with microkernels....)
The fact that the low-level transport for some interconnect mechanism happens to be bit-serial doesn't mean that it has any deeper relationship to any other interconnect mechanism that also happens to be bit-serial. The SCSI command set can be transported over the serial SCSI transport, FireWire, and even a certain other long-lived serial transport (iSCSI with IP running over Ethernet, as well as some SCSI-over-Ethernet transport), but that doesn't mean that the lower layers of the protocol share anything.
But surely the complete translation of the GUI into British English
The only en_* translation listed there is en_UK; does this mean that en_US, en_CA (what colour are your tires?:-)), en_AU, and en_NZ aren't available (well, maybe the latter two, and perhaps en_CA, could use en_UK as a "good enough" version)? (I may be a Yank, but I certainly hope it doesn't mean en_US is the "default", so that an en_US version wouldn't be considered a translation!)
I was under the impression it was OS X's response to a kernel panic.
It is. Presumably the person to whom you're responding is asserting that those panics are usually caused by hardware problems; that might be the case (whether it is the case is another matter), but they can, obviously, be caused by software problems as well.
Most flavors of UNIX, along with BeOS solve this problem by making the contextual menu just a vertical menubar menu.
Presumably by "most flavors of UNIX" you mean "most X11 toolkits"; what toolkits make the context menu just a vertical menubar menu? GTK+ doesn't, as far as I know.
I suspect that for most users, the X-Windows cut 'n paste model would be harder to work with than the existing model.
Fortunately, the models aren't mutually exclusive; most if not all X toolkits, these days, support both of them...
...which is why it's probably not a good idea to call the "paste current selection" operation in most X toolkits "X cut 'n paste", because in many X11 toolkits cut and paste is done with control-C to copy, control-X to cut, and control-V to paste, just as it's done in Windows (and in Mac OS with control replaced by command). The middle-mouse-button operation pastes the current selection, rather than copying something (it leaves the CLIPBOARD selection, as pasted by ^V, alone) and pasting the copied text, which is why I call it "paste current selection"....
Often the abi of the c library changes without the api changing. There are lots of macros and stuff thaat make that happen even if your code didn't change.
If the ABI of the library changes in a fashion that can break programs built with older versions of the library, no matter why it changed or whether it was a consequence of an API change or not, then the major version number of the library should change, and if whoever's supplying the system with that C library cares about binary compatibility, they need to keep supplying the older version of the library. (If they don't care about binary compatibility, they should make that clear, so that anybody who does care knows that they're not going to get release-to-release binary compatibility from that system.)
Delivering VB with an IDE and a bunch of libraries is what turned the... thing?... into a huge success.
Delivering the Linux kernel with a C library, and other libraries and user-mode code, was certainly necessary to turn it into a success in many applications (such as the "general-purpose OS" application).
That still doesn't mean it's the Linux kernel developers' job to ship all that additional code; it's the Linux distributors' job. Somebody could bundle GCC and a pile of libraries into a distribution (heck, some people do bundle it in that fashion, although they also thrown in a Linux kernel and some other stuff along with it:-)), and perhaps a "division of labor" in which the people who bundle aren't the same as the people who develop the component is the right answer. (I suspect having them cooperate, and having the developers of various components of the bundle cooperate, would be a Good Thing, but that's a different matter.)
Re:and how many times...
on
GCC 4.0 Preview
·
· Score: 2, Interesting
If you chose to go against the developers and statically link to Glibc, be prepared to handle the consequences!
And if you statically link against libc on, I suspect, at least some other UN*Xes (Solaris being one of them), you'd better be prepared to handle the consequences as well. The same, I suspect, applies if you statically link against the kernel32/gdi32/user32 libraries on Windows, if you even can do so.
Thus, it's not even clear that this (problems with installing completely-statically-linked binaries on OS versions other than the one on which it's built) is any worse than it is on Solaris or Windows, except for the "this week's version of glibc" problem. That would be the real problem, although if the binary requires this week's version of glibc because it was written for this week's version of glibc and uses functionality of this week's version of glibc, then, well, if you choose to do that, be prepared to handle the consequences....
(Yes, this means that making system developers' lives better by making the lives of some application developers harder, well, makes the lives of some application developers, such as the ones who want to use the latest shiniest APIs but still deliver their applications on systems lacking those APIs, harder. So it goes....)
A kernel that has a bug brings down a machine unlike a userspace app.
...unless, of course, the userspace "app" isn't just an application but a server process upon which operation of the system depends; those can exist even in systems with "monolithic" kernels, but with "true" microkernels in which large chunks of core system operation are moved to server processes, more of those processes exist.
Qnx is a microkernel and so is AIX.
QNX I can see - but how much of AIX's core kernelish functions are performed in, for example user-mode server processes?
Canadian taxes are high because so many services are supplied by the government, healthcare being the most notable.... Your best chance is to be rich and move to America or Europe, because Canada has smoothed you out.
So what is the difference, then, between the way universal health care works in Canada and the way it works in various European countries (e.g., France and Germany)?
In a single statement? No. In the logical combination of different parts? Probably - but I haven't paid $18.00 plus shipping and handling to get my copy of the actual standard. I only have FAQs and summaries to go on.
Well, I have ANSI C89 - at some point I may pay CHF 340 or so for ISO C99. I did find a C99 draft from January 18, 1999, but they might have changed the stuff about null pointers since then. However, given that they probably didn't intend to break valid C89 code if they didn't have to, I suspect they didn't change too much.
- NULL is defined via a cast operation. Since it MUST be a macro of "(void*)0",
That's presumably a C99ism - C89 makes no such requirement.
that means the compiler cannot treat "NULL" and "(void*)0" differently. They must be the same in all cases. Therefore, if there is any mangling of the zero, turning it into something nonzero, it MUST be the cast operator that is doing so, such that if foo=zero, then (void*)foo results in the same mangling of the value as NULL does.
Where in the C99 standard does it say that casting an integral constant 0 to void * must yield the same result as casting an integer variable with the value 0 to void *. It might be "obvious" that they must yield the same result, but "obvious" and "true" aren't always the same thing. Section 3.3.2.3 in C89 speaks of an integral constant expression 0, or such a constant cast to void *, as being a "null pointer constant", and speaks of a "null pointer constant", converted to a pointer when assigned to or compared with another pointer, as being a "null pointer". The Rationale says
Since pointers and integers are now considered incommensurate, the only integer that can safely be converted to a pointer is the constant 0. The result of converting any other integer to a pointer is machine dependent.
They don't explicitly say that the result of converting non-constant value that happens to be zero to a pointer is not necessarily the same as the result of converting a constant 0 to a pointer, but the fact that they explicitly say "the constant 0" rather than "0" suggests that they were at least thinking in those terms.
2 - So long as all the possible values of type Foo are expressable with a mapping into Bar (i.e. Bar is at least as big as Foo), then that means nothing gets lost from a casting of Foo into Bar, or in other words a circular casting chain of: (Foo)(Bar)(Foo)i results in the same 'i' as just (Foo)i does. (***This is what I need to see in the standard to look up - I need to see the section on castings***).
Please do look it up - and make sure it applies to mappings beetween integers and pointers. Please also note that casts are not the only places where conversions take place; there are places where a conversion is performed without a cast, e.g. an assignment where the LHS and RHS have different types, including, at least in C89, an assignment of a null pointer constant to a pointer, such as char *p = 0.
4 - boolean expressions automatically get casted back to int.
If true, that must be a C99ism, given that there's no such thing as a Boolean type in C89.
5 - therefore the expression:
if( expr )
{
}
Will result in expr getting silently cast into an int
I doubt that; I rather suspect that either C99 doesn't consider expr to be Boolean in that context if it lacks a comparison operator, or Boolean expressions don't get converted to int, because if expr is an expression of pointer or floating-point type, converting it to an int can lose information (consider a system with 64-bit pointers and 32-bit ints).
What C89 says about an expression in an if is implicitly comp
But null pointers are a concept at a higher level than the archetecture.
Are you certain of that? Are you certain that no architecture on which C has been implemented has ever mandated a particular null pointer representation? ("Certain" doesn't mean "certain that you have an argument that demonstrates this" - an argument could be making an explicit or implicit assumption that's wrong - "certain" means "certain that there's no architecture in the real world has done that, by looking at those architectures".)
Null pointers are a concept at the language level, not the hardware level - some pointer that, despite looking like a valid pointer to the hardware, still is by convention not going to be used for anything 'real'.
There might be hardware on which some bit patterns are defined not to be valid, perhaps even for use as null pointers or other "trap pointers". (Consider, for example, the GE 645 and successors, where one "tag" field in a pointer had a value explicitly intended to cause a trap; Multics used that for run-time dynamic linking, with pointers to functions or data objects in other segments starting out as trap pointers and, in the trap handler, invoking the run-time linker, resolving the reference, and replacing the pointer with a pointer to the object in question. Loading such a pointer caused a trap, so you couldn't copy such a pointer without snapping the link.)
Consider, also, that C programs don't necessarily exist in a vacuum; C might be implemented on a system with an existing operating system and other languages, in an environment where some not-all-zero value was used for null pointers. It might well be that, for convenience in calling existing non-C APIs, the C null pointer would use the existing null pointer representation. (A shim routine could translate arguments and return values, but might not be able to conveniently translate null pointers in, for example, data structures pointed to by arguments.)
Perhaps ease of porting existing C code that, for example, assumed that memset(object, 0, sizeof object ) will set all pointer values in object to null pointer values, would be a reason not to do that, but the implementors of C on that platform might still decide, perhaps properly, that ease of interfacing with existing code is more important than ease of porting technically-incorrect C code.
In practice, you probably will find few platforms on which the representation of null pointers in C does not have all bits zero, but
I wouldn't assume that there aren't any with not all bits zero (and I have the impression that there might have been some where they weren't all zero - I wonder what the null pointer representation is in C in OS/400 on AS/400?);
one cannot find in the ANSI C standard any requirement that null pointers be represented with all their bits zero.
The only case where a cast can cause bits of value 1 to be added to a value is when the value starts out negative and it's being lengthened to a larger number of bytes (for example, casting (short)-1 into a (long) will pad with 1 bits rather than 0 bits).
You're thinking of a cast of an integral value to a wider integral type.
That's not what this is - this is converting an integral constant 0 to a null pointer. Such a conversion is not guaranteed to just copy the bits. Nothing in the ANSI C standard says that, for example, on a platform where pointers have a 16-bit segment number and a 32-bit segment offset, and where a null pointer has a segment number of hex FEFE and a segment offset of FFFFFFFF, the expression (void *)0 must result in a pointer with an all-zero segment number and an all-zero segment offset, rather than one with a segment number of FEFE and a segment offset of FFFFFFFF.
Yes, the note in footnote 45 of page 46 of the ANSI C standard, that "The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment." would probably recommend that converting arbitrary integral values (which would have to be 48-bit or longer integral values on this platform) just copy the bits - but that's just a note (the standard just says the mapping is "implementation-defined", and if null pointers have to be FEFE:FFFFFFFF on that platform, then (void *)0 has to map to FEFE:FFFFFFFF even if
int i = 0; char *p = i;
would result in p being 0000:00000000. Yes, this is a bit counter-intuitive, but, given that C didn't have the notion of "nil" or some other null pointer constant from Day One, that's life.
Actually, in ALL C implementations that follow the standard. The standard mandates that NULL be "(void*)0".
Yes, but it doesn't mandate that all the bits of the value (void *)0 are zero. In most C implementations they are, but there might be some, or might have been some, where they weren't.
Nah, you're just thinking of it wrong -- strcmp returns "difference". So, "if not-different x,y" -- exactly what it says, not backwards at all.
Nah, you're thinking of it wrong -- strcmp returns "result of comparison of strings", in a form that appears to have been designed so that the result is compared against 0 using a comparison operator appropriate for the string comparison being done, i.e. == if you're comparing strings for equality, != if you're comparing them for inequality, > if you're checking whether the first string is greater than the second string, etc..
The !ptr form is actually more likely to be a performance problem in higher level/interperted languages, strangely enough, where it forces a type coercion to boolean rather than an integer compare.
Presumably by "higher level languages" you mean "languages that have a Boolean type and where ! takes a Boolean argument"; C is not one of those languages.
("Interpreted" isn't needed or wanted in that statement, so I removed it; one could have an interpreted implementation of C - and, in fact, Googling for "c interpreter" finds some, although I didn't check whether any that didn't explicitly say they weren't complete ANSI C implementations were - and one could have a language with a Boolean type and a ! operator that requires a Boolean argument and that has a non-interpreted implementation.)
I'm not sure what you mean by "be (int)0", but note that, regardless of how a null pointer is represented in a particular C implementation, comparing a pointer against 0 is interpreted as comparing it against a "null pointer constant"; see the comp.lang.c FAQ item about this.
However, any compiler worth anything should find that and optimize it very easily in the case where you're comparing to a constant that evaluates to zero
...such as a null pointer constant, in most C implementations. (There's no guarantee that a null pointer constant is implemented as a value all of whose bytes are zero, but on most implementations - probably including the 6502 C implementation in question - it is.)
Slashdot Mirror
For a distribution that "doesn't have an installer", they certainly use the word "install" a lot in the Installing Gentoo document.
How much of the time "spent ... working on and tweaking my linux system to get it up to the usability stanadards of os x" could have been spent working on those tools, instead? That, as far as I'm concerned, is one of the biggest reasons why even hardcore hackers should support having the OS and desktop environment Just Work, whenever possible.
How many of the tweaks were either application source tweaks (which should be fed back to the developers - or, if they represent personal tweaks, perhaps fed back after being made settable preferences) or configuration file tweaks (in which case, should that setting of the configuration file be the default - or be settable from your favorite desktop environment's configuration app?)?
Hopefully in ways that can be incorporated by whatever distribution you're using, so that, in the future, said distribution can work that way as installed.
Control+F2 to give the menu bar the input focus, tab to the appropriate menu, Space to open the menu, cursor arrows to move up or down or a letter to select the first menu item(?) beginning with that letter, Esc to dismiss the menu, Return or Enter to activate the item.
See Keyboard Shortcuts Quick Reference in Apple Human Interface Guidelines. (Ignore the "For Carbon Users" in the bit about Control+F2, it works fine in Cocoa applications such as Safari as well.)
Not quite as quick as the Windows-and-many-UNIX+X-toolkits Alt+{accelerator for a menu} to directly pop up the menu in question, but at least it's something.
Can any code using GPLFlash play that demonstration? Or does it use features not supported by GPLFlash?
This is your God.
(I'm not sure what that has to do with microkernels....)
The fact that the low-level transport for some interconnect mechanism happens to be bit-serial doesn't mean that it has any deeper relationship to any other interconnect mechanism that also happens to be bit-serial. The SCSI command set can be transported over the serial SCSI transport, FireWire, and even a certain other long-lived serial transport (iSCSI with IP running over Ethernet, as well as some SCSI-over-Ethernet transport), but that doesn't mean that the lower layers of the protocol share anything.
The only en_* translation listed there is en_UK; does this mean that en_US, en_CA (what colour are your tires? :-)), en_AU, and en_NZ aren't available (well, maybe the latter two, and perhaps en_CA, could use en_UK as a "good enough" version)? (I may be a Yank, but I certainly hope it doesn't mean en_US is the "default", so that an en_US version wouldn't be considered a translation!)
It is. Presumably the person to whom you're responding is asserting that those panics are usually caused by hardware problems; that might be the case (whether it is the case is another matter), but they can, obviously, be caused by software problems as well.
Presumably by "most flavors of UNIX" you mean "most X11 toolkits"; what toolkits make the context menu just a vertical menubar menu? GTK+ doesn't, as far as I know.
Fortunately, the models aren't mutually exclusive; most if not all X toolkits, these days, support both of them...
...which is why it's probably not a good idea to call the "paste current selection" operation in most X toolkits "X cut 'n paste", because in many X11 toolkits cut and paste is done with control-C to copy, control-X to cut, and control-V to paste, just as it's done in Windows (and in Mac OS with control replaced by command). The middle-mouse-button operation pastes the current selection, rather than copying something (it leaves the CLIPBOARD selection, as pasted by ^V, alone) and pasting the copied text, which is why I call it "paste current selection"....
If the ABI of the library changes in a fashion that can break programs built with older versions of the library, no matter why it changed or whether it was a consequence of an API change or not, then the major version number of the library should change, and if whoever's supplying the system with that C library cares about binary compatibility, they need to keep supplying the older version of the library. (If they don't care about binary compatibility, they should make that clear, so that anybody who does care knows that they're not going to get release-to-release binary compatibility from that system.)
Delivering the Linux kernel with a C library, and other libraries and user-mode code, was certainly necessary to turn it into a success in many applications (such as the "general-purpose OS" application).
That still doesn't mean it's the Linux kernel developers' job to ship all that additional code; it's the Linux distributors' job. Somebody could bundle GCC and a pile of libraries into a distribution (heck, some people do bundle it in that fashion, although they also thrown in a Linux kernel and some other stuff along with it :-)), and perhaps a "division of labor" in which the people who bundle aren't the same as the people who develop the component is the right answer. (I suspect having them cooperate, and having the developers of various components of the bundle cooperate, would be a Good Thing, but that's a different matter.)
And if you statically link against libc on, I suspect, at least some other UN*Xes (Solaris being one of them), you'd better be prepared to handle the consequences as well. The same, I suspect, applies if you statically link against the kernel32/gdi32/user32 libraries on Windows, if you even can do so.
Thus, it's not even clear that this (problems with installing completely-statically-linked binaries on OS versions other than the one on which it's built) is any worse than it is on Solaris or Windows, except for the "this week's version of glibc" problem. That would be the real problem, although if the binary requires this week's version of glibc because it was written for this week's version of glibc and uses functionality of this week's version of glibc, then, well, if you choose to do that, be prepared to handle the consequences....
(Yes, this means that making system developers' lives better by making the lives of some application developers harder, well, makes the lives of some application developers, such as the ones who want to use the latest shiniest APIs but still deliver their applications on systems lacking those APIs, harder. So it goes....)
Shark is part of the CHUD suite, and it's intended for use by application developers. CHUD isn't solely intended for hardware development (the expansion of the acronym is clumsy enough that one might suspect "hardware" was put in the name for reasons other than it being intended only for hardware development and testing).
...unless, of course, the userspace "app" isn't just an application but a server process upon which operation of the system depends; those can exist even in systems with "monolithic" kernels, but with "true" microkernels in which large chunks of core system operation are moved to server processes, more of those processes exist.
QNX I can see - but how much of AIX's core kernelish functions are performed in, for example user-mode server processes?
So what is the difference, then, between the way universal health care works in Canada and the way it works in various European countries (e.g., France and Germany)?
Well, I have ANSI C89 - at some point I may pay CHF 340 or so for ISO C99. I did find a C99 draft from January 18, 1999, but they might have changed the stuff about null pointers since then. However, given that they probably didn't intend to break valid C89 code if they didn't have to, I suspect they didn't change too much.
That's presumably a C99ism - C89 makes no such requirement.
Where in the C99 standard does it say that casting an integral constant 0 to void * must yield the same result as casting an integer variable with the value 0 to void *. It might be "obvious" that they must yield the same result, but "obvious" and "true" aren't always the same thing. Section 3.3.2.3 in C89 speaks of an integral constant expression 0, or such a constant cast to void *, as being a "null pointer constant", and speaks of a "null pointer constant", converted to a pointer when assigned to or compared with another pointer, as being a "null pointer". The Rationale says
They don't explicitly say that the result of converting non-constant value that happens to be zero to a pointer is not necessarily the same as the result of converting a constant 0 to a pointer, but the fact that they explicitly say "the constant 0" rather than "0" suggests that they were at least thinking in those terms.
Please do look it up - and make sure it applies to mappings beetween integers and pointers. Please also note that casts are not the only places where conversions take place; there are places where a conversion is performed without a cast, e.g. an assignment where the LHS and RHS have different types, including, at least in C89, an assignment of a null pointer constant to a pointer, such as char *p = 0.
If true, that must be a C99ism, given that there's no such thing as a Boolean type in C89.
I doubt that; I rather suspect that either C99 doesn't consider expr to be Boolean in that context if it lacks a comparison operator, or Boolean expressions don't get converted to int, because if expr is an expression of pointer or floating-point type, converting it to an int can lose information (consider a system with 64-bit pointers and 32-bit ints).
What C89 says about an expression in an if is implicitly comp
Are you certain of that? Are you certain that no architecture on which C has been implemented has ever mandated a particular null pointer representation? ("Certain" doesn't mean "certain that you have an argument that demonstrates this" - an argument could be making an explicit or implicit assumption that's wrong - "certain" means "certain that there's no architecture in the real world has done that, by looking at those architectures".)
There might be hardware on which some bit patterns are defined not to be valid, perhaps even for use as null pointers or other "trap pointers". (Consider, for example, the GE 645 and successors, where one "tag" field in a pointer had a value explicitly intended to cause a trap; Multics used that for run-time dynamic linking, with pointers to functions or data objects in other segments starting out as trap pointers and, in the trap handler, invoking the run-time linker, resolving the reference, and replacing the pointer with a pointer to the object in question. Loading such a pointer caused a trap, so you couldn't copy such a pointer without snapping the link.)
Consider, also, that C programs don't necessarily exist in a vacuum; C might be implemented on a system with an existing operating system and other languages, in an environment where some not-all-zero value was used for null pointers. It might well be that, for convenience in calling existing non-C APIs, the C null pointer would use the existing null pointer representation. (A shim routine could translate arguments and return values, but might not be able to conveniently translate null pointers in, for example, data structures pointed to by arguments.)
Perhaps ease of porting existing C code that, for example, assumed that memset( object , 0, sizeof object ) will set all pointer values in object to null pointer values, would be a reason not to do that, but the implementors of C on that platform might still decide, perhaps properly, that ease of interfacing with existing code is more important than ease of porting technically-incorrect C code.
In practice, you probably will find few platforms on which the representation of null pointers in C does not have all bits zero, but
You're thinking of a cast of an integral value to a wider integral type.
That's not what this is - this is converting an integral constant 0 to a null pointer. Such a conversion is not guaranteed to just copy the bits. Nothing in the ANSI C standard says that, for example, on a platform where pointers have a 16-bit segment number and a 32-bit segment offset, and where a null pointer has a segment number of hex FEFE and a segment offset of FFFFFFFF, the expression (void *)0 must result in a pointer with an all-zero segment number and an all-zero segment offset, rather than one with a segment number of FEFE and a segment offset of FFFFFFFF.
Yes, the note in footnote 45 of page 46 of the ANSI C standard, that "The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to be consistent with the addressing structure of the execution environment." would probably recommend that converting arbitrary integral values (which would have to be 48-bit or longer integral values on this platform) just copy the bits - but that's just a note (the standard just says the mapping is "implementation-defined", and if null pointers have to be FEFE:FFFFFFFF on that platform, then (void *)0 has to map to FEFE:FFFFFFFF even if
would result in p being 0000:00000000. Yes, this is a bit counter-intuitive, but, given that C didn't have the notion of "nil" or some other null pointer constant from Day One, that's life.
See question 5.5 in the comp.lang.c FAQ (and the rest of section 5 of that FAQ, devoted to the null pointer) for more details.
Yes, but it doesn't mandate that all the bits of the value (void *)0 are zero. In most C implementations they are, but there might be some, or might have been some, where they weren't.
Nah, you're thinking of it wrong -- strcmp returns "result of comparison of strings", in a form that appears to have been designed so that the result is compared against 0 using a comparison operator appropriate for the string comparison being done, i.e. == if you're comparing strings for equality, != if you're comparing them for inequality, > if you're checking whether the first string is greater than the second string, etc..
Presumably by "higher level languages" you mean "languages that have a Boolean type and where ! takes a Boolean argument"; C is not one of those languages.
("Interpreted" isn't needed or wanted in that statement, so I removed it; one could have an interpreted implementation of C - and, in fact, Googling for "c interpreter" finds some, although I didn't check whether any that didn't explicitly say they weren't complete ANSI C implementations were - and one could have a language with a Boolean type and a ! operator that requires a Boolean argument and that has a non-interpreted implementation.)
Here's all the items about null pointers in the comp.lang.c FAQ.
...such as a null pointer constant, in most C implementations. (There's no guarantee that a null pointer constant is implemented as a value all of whose bytes are zero, but on most implementations - probably including the 6502 C implementation in question - it is.)
You mean, this might be a real scientific result if it were, say, an article called Learned Predictions of Error Likelihood in the Anterior Cingulate Cortex in Science Magazine, a peer-reviewed journal? (No, that link won't take you directly to the article - you have to buy access or join the American Association for the Advancement of Science to get access.)