You're saying it will definitely happen "somewhere between a week and 7 or so billion years" and allowing for no possibility it won't happen at all. How is that different from inevitable?
OK, sorry, should have said "somewhere between a week and the Big Crunch" if the universe is closed and "...and the heat death of the universe" if it's open - by the time of the Big Crunch your Mac will be quark soup and by the time of the heat death of the universe there won't be enough energy to run a compiler so nobody will be developing software anyway.:-)
It's amusing that you think the "Haters" will just not let people use what they find suits them best, when that is precisely Apple's strategy (not letting people just use what they find suits them best)
No, it's "suing vendors who they assert are violating their patents"; Apple's not stopping people from buying devices they don't deem to be infringing on their patents.
I hate Apple because they have ruined software for me.
On my desktops or servers download Windows freeware or open source software and get good quality software that does not necessarily track or spy on me.
On my desktop (well, laptop, really) I can download Mac OS X freeware or open-source software and get good quality software that does not necessarily track or spy on me.
I can install whatever I want.
Same here.
I can develop on it for free, I don't have to pay anyone to start programming. On an Apple product I have to pay Apple for this right to write code for my own device.
OK, so what you really mean is "...because they have ruined smartphone and tablet software for me". I can and do develop, on my Mac, for free, software that runs on Mac OS X.
I suppose that's why it's awesome that iOS is open-source
Actually it is (check out Darwin sometime).
Most of iOS is not open source. The versions of Darwin atop which particular Mac OS X releases are built are; the versions of Darwin atop which particular iOS releases aren't - maybe a particular Darwin release is "close enough" to the Darwin in a particular iOS release, but, even then, it doesn't include the low-level ARM support isn't there in xnu, and a lot of the higher-level stuff isn't open source even in Mac OS X (good luck finding the source to Foundation - not Core Foundation, but Foundation - or AppKit or UIKit).
"ISO C" is the name of the internationally-recognized standard C programming language.
And there are three of them.
I.e., from all you said, and from the fact that there have been 3 C standards from ISO (one originally from ANSI later adopted by ISO, one from ISO and adopted by ANSI, and one from ISO which will probably again be adopted by ANSI), if somebody wants to complain about stuff in the new C standard, saying "ANSI good, ISO bad" is not a valid way to do it.
But intptr_t? Really? It takes more than a weird CPU to support pointers as specified in the C standard and yet be unable to store them into an integer type.
How about a machine that uses tag bits to distinguish between pointers and non-pointer data and doesn't allow you to construct a pointer from raw bits?
For the C++ compilers that generate the high-level instruction set, pointers are, as far as I know, 128-bit.
According to The Fine Manual for the IBM i C++ compiler, you get two data models - P128 with 128-bit pointers, and LLP64 with 64-bit pointers (and, I'm guessing from what LLP64 usually means, 32-bit long int and 64-bit long long int).
No, they didn't. short int is a type the range of which is a possibly-improper subset of the range of int and int is a type the range of which is a possibly-improper subset of the range of long int. I.e., the ANSI C specification does not prevent an implementation of ANSI C from having short, int, and long int from all being 16, or all being 32, or all being 64. It also doesn't prevent a pointer from not fitting into any integral data type (C on the IBM i operating system has, I think, 128-bit pointers).
The standard requires a ranking char<=short<=int<=long<=long long, so, yes, they could be all the same (but, short can not be larger than int, for example). But, any comp/arch that doesn't provide a base 8/16/32/64 is impractical.
Inconvenient, but not completely impractical; presumably somebody uses C on the descendants of the Univac 1100 series in order for Unisys to continue to offer it. In practice, on architectures other than that and oddball stuff such as DSPs, you're going to get 8-bit, 16-bit, 32-bit, and 64-bit integral data types.
Also, char is mandated to be 8 bits.
No, it's mandated to be "large enough to store any member of the basic execution character set". (Yes, that's a direct quote from ISO/IEC 9899:1999 section 6.2.5 "Types".)
So, to provide the size coverage and honor the ranking requirement, this pretty much locks in char==8,short==16,int==32.
Except where it doesn't. Most programmers will probably not encounter cases where it doesn't, but they do exist.
But, if you're going to cover a 64 bit number, which most programmers expect to be "long long",
...except for programmers using MSVC, where it's _I64 or something such as that.
As to IBM's 128 bit address (which model specifically? some extension of S/390 or of their power* series?),
The AS/400 and iSeries and System i and, now, Power Series. Those machines have a very high-level "virtual" instruction set that is never directly executed, and have two different "real" instruction sets, the older ones having a System/3x0-like CISC instruction set and the newer ones having a Power-architecture instruction set that has some extensions (for example, tag bits and, I think some fixed-point-decimal-arithmetic assists). The lowest level of the OS is compiled into the "real" instruction set, and it includes code that translates the high-level "MI" instruction set into whatever the "real" instruction set is so that programs compiled into the "MI" instruction set can be executed. That lowest level was written in, I think, a PL/I-like language for the older CISC machines, and rewritten in C++ for the newer Power-architecture machines; I suspect that in the C++ compiler used for that purpose pointers and long int are 64 bit. For the C++ compilers that generate the high-level instruction set, pointers are, as far as I know, 128-bit.
they would need to have an integer type of the same size. If they've gone to the trouble of doing this, they have quite probably implemented an ALU that is just as wide.
I don't think so. Note that
not all of the bits in those pointers necessarily participate in address arithmetic;
"MI" instructions that use those pointers probably translate into multiple "real" instructions.
That is, you need to have something that can index through a byte array. If you can't, then the arch is some segmented variant
Which I think it might be. I think MI pointers also contain other gunk, so it's not as if you can have objects of size 2^128 bytes.
Meaning that ICC will generate code that is correct for Intels microcode architecture, but not for AMD's for example.
In another reply you say "Compiled and output into a microcode dat file, according to the Intel engineer I talked to." This seems to indicate that ICC is generating, rather than x86 instructions, microcode instructions, perhaps meaning uops. As far as I know, no x86 processor can run uops from main memory, so this presumably means that ICC generates microcode to be loaded into the processor's microcode memory.
Keep in mind, x86 is now _effectively_ an abstraction layer, with the underlying, ACTUAL ISA being the microcode level, where the implementation differs between the vendors.
And, probably, even between processors from the same vendor, so presumably it would generate microcode only if told which processor was the target processor.
(Or is this a separate compiler from the ones Intel sells, used internally by the processor development groups when developing microcode for particular processors?)
So for example Intels and AMD's FMADD can look the same on x86-level, and called the same, with the same arguments, but on the microcode level they are completely different.
But that doesn't mean the compiler has to generate actual microcode into a.dat file just to use that instruction. It can:
generate code that uses FMADD, as specified by the architecture manual, in a fashion that works on multiple processors, without using it in a fashion optimized for specific processors, so it'll work correctly on all processors, regardless of how it's implemented;
generate code that uses FMADD, as specified by the architecture manual, in a fashion that works on multiple processors, in a fashion optimized for a specific processor, so it'll work correctly on all processors, regardless of how it's implemented, but might be slower than the previous option's code is on processors other than the one for which it's tuned;
generate code that uses FMADD, in ways that the architecture manual doesn't specify as valid, but that happens to work on a particular processor and happens to run faster than code that uses it in a way that the architecture manual specifies as valid;
generate replacement microcode for FMADD's implementation (if it's implemented by microcode fetched from internal processor memory rather than implemented by non-reprogrammable hardware generating uops);
If a short isn't 16 bits (which it has been on any compiler I've ever seen), what would the compiler intrinsic type be? Not some crufty int*_t typedef, but what the crufty typedef would typedef to (e.g. typedef short int16_t equivalent?)
Whatever the compiler writer decides to make it. No guarantee it's a type defined by C89 - or C99 (the spec just says the intN_t types are "signed integer types", not "standard signed integer types", so they could be "extended signed integer types").
As a practical matter, forget the spec. On this point, it's just as inane as IETF specs that still insist on using "octet" instead of byte. The reason they did that was because of Sperry(?) et. al. which didn't have an 8 bit byte size.
Sperry and Digital Equipment Corporation (PDP-10) and General Electric^W^WHoneywell (GE 645/Honeywell 6180).
If somebody wants to name the compiler and architecture that doesn't have int as 32 (that are still in use--as the 36 bit model had vacuum tubes and core memory, circa 1960 era, with some stragglers), I'd like to know about it
Presumably "vacuum tubes" is hyperbole, given that even the PDP-6 was transistorized. The only 36-bit architecture for which there are significant surviving implementations that I know of is the Univac 1100-and-descendants architecture, and Unisys does appear to claim to support C.
There's a bigger problem. sizeof(int) vs sizeof(long) between GCC/ICC/clang/just_about_anybody and VC.
When K&R first came out, int's could be either 16 bit or 32 bit and long's were 32 always. ANSI C changed this to short is 16, int is 32, and long is "large enough to contain a pointer".
No, they didn't. short int is a type the range of which is a possibly-improper subset of the range of int and int is a type the range of which is a possibly-improper subset of the range of long int. I.e., the ANSI C specification does not prevent an implementation of ANSI C from having short, int, and long int from all being 16, or all being 32, or all being 64. It also doesn't prevent a pointer from not fitting into any integral data type (C on the IBM i operating system has, I think, 128-bit pointers).
What "changed this to short is 16, int is 32, and long is "large enough to contain a pointer"" was the widespread availability of 32-bit processors, where those sizes made the most sense.
MS used the K&R model [with int being 16] because it was stuck on the pre-386 8086's. They wanted int's to be 16 for that. They assumed long's were 32 bit. This is one of the reasons that they have so many abstract types for simple types (e.g. LONG, ULONG, STATUS, etc.). They kept this model going, even during the transition from win16 to win32 (which would have been a good time to change the paradigm).
Well, for Win32, they went with int and long int both being 32-bit, just as is the case on UN*X on 32-bit processors (the ILP32 model).
The problem occurs when going to a 64 bit architecture.
Yes, for better or worse, they went with the allowed-by-ANSI-C-but-still-annoyingly-different-from-UN*X's-LP64 LLP64 model.
some of the optimizations regarding intrinsics involve microcode level, which can cause crashes in worst case, or even giving incorrect data only noticed later
Meaning that ICC, or ICC-generated code, will load new microcode for some instructions?
Or that ICC will generate code, for certain processors, that is not valid for the x86 architecture, and might crash or give incorrect data on some processors, but, on other processors, is known (because the developers at Intel know how the microcode works on those processors) to work as desired (presumably even in the face of microcode updates) and known to be faster than the architecturally-correct code?
There is nothing in C90 that forbids 64-bit integers. You are thinking about implementations.
There is also nothing in C90 that requires them, so if you're writing code that needs to run in ILP32 environments but needs to have 64-bit integers, you have to, as peppepz said, "write more platform specific code" - or rely on somebody else (e.g., GLib) to have done so for you (gint64 and guint64 being defined differently for most UN*X C compilers and for MSVC).
some of the optimizations regarding intrinsics involve microcode level, which can cause crashes in worst case, or even giving incorrect data only noticed later
Meaning that ICC, or ICC-generated code, will load new microcode for some instructions?
This is dishonest, because it's completely the wrong way to do it: you're supposed to check for feature bits, not specific CPUs, as both Intel and AMD say to do in their own optimization manuals.
I infer, perhaps incorrectly, from what Shinobi said that in some places they were checking for implementations, not for features, because, in some cases, for a given intrinsic that could expand to more than one sequence of code, even though both sequences of code could work on processors A and B, one sequence would be better on processor A and another sequence would be better on processor B.
Hint: It's loaded at boot time, from flash RAM, and those patches are made, for example, in ICC.
"Made in ICC" in what sense?
ICC has some optimization tools that can analyze the flow of the microcode in some intrinsics.
Presumably meaning the tools know about the internal implementations, on various processors, of instructions generated from the intrinsics, whether they're microcoded or not. If so, stating it that way might have not have provoked that response.
The Soviets were deathly afraid of an invasion, and their nukes were aimed at a country that HAD INVADED THEM IN THE PAST. Look up Murmansk and Archangel.
If Safari can do it, so can others who craft this type of object. Therefore it is a Windows 64 bit bug.
Yes, but if the fix to the Windows graphics subsystem means that whatever Safari's doing causes, instead, Safari to be terminated with an error (because it's doing something the Windows graphics subsystem doesn't want you to do), or to mis-display the HTML page in question, or something such as that, there's also a Safari bug there that should also be fixed.
Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.
As a game developer, I need graphics code to be low level, fast, and insecure. There are times I just need it to be a rocketship without handrails.
If there is a way to secure it without sacrificing speed, that's great! But doing a great deal of error checking on that level? Leave me some insecure route to blitting billions of bits to the screen without guardrails please.
Sure, as long as 1) only the applications that absolutely positively need this do their graphics through that API and other apps can't even get at that API under any circumstances (so if the app has a bug nobody can inject code to enable it) and 2) applications that do can be marked as "DANGER DANGER WILL ROBINSON IF THIS APP HAS A BUG YOU MIGHT BE SERIOUSLY PWNED". There might be a tradeoff between your requirements and the requirements of security, and the best resolution for that tradeoff might not be in your favor....
The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser.
So, they blame win32k.sys - but apparently the actual bug is that you can cause something resembling a buffer overflow by feeding Safari a ridiculously large bit of data as an iFrame.
Could go either way.
Should go both ways.
Apple should fix the Safari bug so it doesn't mishandle IFRAMEs with "overly large" "height" attributes.
Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.
I am also ALL ABOUT the endlessly derived works being Free.
"Just giving your software away" only works if the person to whom you're giving your software doesn't refuse to cooperate; as Stallman's goal was to force that cooperation, so that failure to cooperate could be prevented by law - and, in fact, there have been cases where users of GPLed software have, whether intentionally or not, failed to cooperate, and had to be threatened legally to get them to cooperate.
So, if you strongly believe that the derived works should be free-as-in-speech, but are willing to accept the possibility that they not remain free-as-in-speech, in exchange for allowing people the freedom to make non-free-as-in-speech derived works, that's fine, but that's not the GPL's goal. The goals may be similar, but they're not the same (and no valid argument can possibly exist that they are, as the goal of people using the GPL without dual-licensing is explicitly not to allow people the freedom to make non-free-as-in-speech derived works).
However, that is a bit of an obstacle to Apple "giving back" code, especially kernel code, as it would involve Apple doing work to port that code to the BSD in question.
I think that is a mostly unreasonable expectation.
As do I; that was my point when saying " However, that is a bit of an obstacle to Apple "giving back" code...". It's also an obstacle to, say, OpenBSD "giving back" code to NetBSD, even though OpenBSD began as a fork from NetBSD, or DragonFly BSD "giving back" to FreeBSD; the individual *BSDs differ at the kernel level as well.
Darwin is (mostly) open source, and well documented. If a BSD team wanted to take some code from Darwin I think they have to do the porting effort.
Yes, they would - and, as somebody else noted, they did do so for HFS+, but, apparently, nobody cared enough to keep it going.
Anyway, my main point to GP was that the kernels aren't much alike.
As long as that statement applies to all four - or, if you include DragonFly BSD, five - kernels, yes. It's not as if there's "*BSD", with kernels that are essentially similar, and "Mac OS X", with a kernel that's nowhere similar. My guess would be that the place where they're most similar is at the networking layer, followed by the file system layer (Mac OS X's VFS layer is different from those of the other *BSDs, but that hasn't anything to do with Mach - it's due to
its VFS layer being reorganized to hide a lot of internal XNU details, such as the layout of an inode structure, from file systems, so that Apple can change code above the VFS layer without breaking binary compatibility with third-party file systems;
changes Apple have made to support various things they've added to Mac OS X such as its NT-flavored ACLs and its flavor of extended attributes;
architectural changes made for various reasons, e.g. VNOP_COMPOUND_OPEN in Lion, added to make the VFS layer more friendly towards remote file systems (SMB, NFS, etc.).
The process layer is a bit less similar, mostly due to processes being built atop Mach tasks, so the top layer is pretty similar to the other *BSDs but it's built atop a different bottom layer. The in-kernel mutual-exclusion primitives are different, but I'm not sure they're even that much the same between the *BSDs; the same applies with the mechanisms atop which userland threads are built. The XNU virtual memory system is Mach-based, but, then, so was the original 4.4-Lite VM system; however, the XNU one wasn't yanked out of Mach and reimplemented in a non-Mach context the way the 4.4-Lite one was. Then again, some of the other *BSDs have replaced their Mach-based VM system.
You seem to be arguing my 98% dissimilar is too high, and maybe it should be 90% dissimilar.
I definitely would not say "98% dissimilar" for the kernel as a whole, seriously; for moving code to XNU from one of the *BSDs, that's a major exaggeration. I wouldn't even say "90% dissimilar". I wouldn't even use a single percentage; the percentage is different for different parts of the kernel. The biggest problem I had porting to XNU to make select() handle the BIOCSRTIMEOUT timeout on BPF devices for Lion was the difference between the ways you say "I'm starting a timer, poke me when it expires". The bulk of the changes pretty much just went over.
Even if true, I think that addresses GP's objection that Apple isn't contributing kernel code back....
Yes - and, as indicated, the same applies to moving kernel-land changes between the *BSDs.
Slashdot Mirror
You're saying it will definitely happen "somewhere between a week and 7 or so billion years" and allowing for no possibility it won't happen at all. How is that different from inevitable?
OK, sorry, should have said "somewhere between a week and the Big Crunch" if the universe is closed and "...and the heat death of the universe" if it's open - by the time of the Big Crunch your Mac will be quark soup and by the time of the heat death of the universe there won't be enough energy to run a compiler so nobody will be developing software anyway. :-)
Enjoy this while you can. How long before Apple reproduces the iPhone market model on the Mac ?
Somewhere between a week and 7 or so billion years (unless they manage to reproduce it after the Sun turns into a red giant).
(I.e., no, I do not adhere to one group's conventional wisdom that it's inevitable that they'll do it.)
It's amusing that you think the "Haters" will just not let people use what they find suits them best, when that is precisely Apple's strategy (not letting people just use what they find suits them best)
No, it's "suing vendors who they assert are violating their patents"; Apple's not stopping people from buying devices they don't deem to be infringing on their patents.
I hate Apple because they have ruined software for me.
On my desktops or servers download Windows freeware or open source software and get good quality software that does not necessarily track or spy on me.
On my desktop (well, laptop, really) I can download Mac OS X freeware or open-source software and get good quality software that does not necessarily track or spy on me.
I can install whatever I want.
Same here.
I can develop on it for free, I don't have to pay anyone to start programming. On an Apple product I have to pay Apple for this right to write code for my own device.
OK, so what you really mean is "...because they have ruined smartphone and tablet software for me". I can and do develop, on my Mac, for free, software that runs on Mac OS X.
I suppose that's why it's awesome that iOS is open-source
Actually it is (check out Darwin sometime).
Most of iOS is not open source. The versions of Darwin atop which particular Mac OS X releases are built are; the versions of Darwin atop which particular iOS releases aren't - maybe a particular Darwin release is "close enough" to the Darwin in a particular iOS release, but, even then, it doesn't include the low-level ARM support isn't there in xnu, and a lot of the higher-level stuff isn't open source even in Mac OS X (good luck finding the source to Foundation - not Core Foundation, but Foundation - or AppKit or UIKit).
"ISO C" is the name of the internationally-recognized standard C programming language.
And there are three of them.
I.e., from all you said, and from the fact that there have been 3 C standards from ISO (one originally from ANSI later adopted by ISO, one from ISO and adopted by ANSI, and one from ISO which will probably again be adopted by ANSI), if somebody wants to complain about stuff in the new C standard, saying "ANSI good, ISO bad" is not a valid way to do it.
But intptr_t? Really? It takes more than a weird CPU to support pointers as specified in the C standard and yet be unable to store them into an integer type.
How about a machine that uses tag bits to distinguish between pointers and non-pointer data and doesn't allow you to construct a pointer from raw bits?
For the C++ compilers that generate the high-level instruction set, pointers are, as far as I know, 128-bit.
According to The Fine Manual for the IBM i C++ compiler, you get two data models - P128 with 128-bit pointers, and LLP64 with 64-bit pointers (and, I'm guessing from what LLP64 usually means, 32-bit long int and 64-bit long long int).
No, they didn't. short int is a type the range of which is a possibly-improper subset of the range of int and int is a type the range of which is a possibly-improper subset of the range of long int. I.e., the ANSI C specification does not prevent an implementation of ANSI C from having short, int, and long int from all being 16, or all being 32, or all being 64. It also doesn't prevent a pointer from not fitting into any integral data type (C on the IBM i operating system has, I think, 128-bit pointers).
The standard requires a ranking char<=short<=int<=long<=long long, so, yes, they could be all the same (but, short can not be larger than int, for example). But, any comp/arch that doesn't provide a base 8/16/32/64 is impractical.
Inconvenient, but not completely impractical; presumably somebody uses C on the descendants of the Univac 1100 series in order for Unisys to continue to offer it. In practice, on architectures other than that and oddball stuff such as DSPs, you're going to get 8-bit, 16-bit, 32-bit, and 64-bit integral data types.
Also, char is mandated to be 8 bits.
No, it's mandated to be "large enough to store any member of the basic execution character set". (Yes, that's a direct quote from ISO/IEC 9899:1999 section 6.2.5 "Types".)
So, to provide the size coverage and honor the ranking requirement, this pretty much locks in char==8,short==16,int==32.
Except where it doesn't. Most programmers will probably not encounter cases where it doesn't, but they do exist.
But, if you're going to cover a 64 bit number, which most programmers expect to be "long long",
...except for programmers using MSVC, where it's _I64 or something such as that.
As to IBM's 128 bit address (which model specifically? some extension of S/390 or of their power* series?),
The AS/400 and iSeries and System i and, now, Power Series. Those machines have a very high-level "virtual" instruction set that is never directly executed, and have two different "real" instruction sets, the older ones having a System/3x0-like CISC instruction set and the newer ones having a Power-architecture instruction set that has some extensions (for example, tag bits and, I think some fixed-point-decimal-arithmetic assists). The lowest level of the OS is compiled into the "real" instruction set, and it includes code that translates the high-level "MI" instruction set into whatever the "real" instruction set is so that programs compiled into the "MI" instruction set can be executed. That lowest level was written in, I think, a PL/I-like language for the older CISC machines, and rewritten in C++ for the newer Power-architecture machines; I suspect that in the C++ compiler used for that purpose pointers and long int are 64 bit. For the C++ compilers that generate the high-level instruction set, pointers are, as far as I know, 128-bit.
they would need to have an integer type of the same size. If they've gone to the trouble of doing this, they have quite probably implemented an ALU that is just as wide.
I don't think so. Note that
That is, you need to have something that can index through a byte array. If you can't, then the arch is some segmented variant
Which I think it might be. I think MI pointers also contain other gunk, so it's not as if you can have objects of size 2^128 bytes.
Meaning that ICC will generate code that is correct for Intels microcode architecture, but not for AMD's for example.
In another reply you say "Compiled and output into a microcode dat file, according to the Intel engineer I talked to." This seems to indicate that ICC is generating, rather than x86 instructions, microcode instructions, perhaps meaning uops. As far as I know, no x86 processor can run uops from main memory, so this presumably means that ICC generates microcode to be loaded into the processor's microcode memory.
Keep in mind, x86 is now _effectively_ an abstraction layer, with the underlying, ACTUAL ISA being the microcode level, where the implementation differs between the vendors.
And, probably, even between processors from the same vendor, so presumably it would generate microcode only if told which processor was the target processor.
(Or is this a separate compiler from the ones Intel sells, used internally by the processor development groups when developing microcode for particular processors?)
So for example Intels and AMD's FMADD can look the same on x86-level, and called the same, with the same arguments, but on the microcode level they are completely different.
But that doesn't mean the compiler has to generate actual microcode into a .dat file just to use that instruction. It can:
for example.
If a short isn't 16 bits (which it has been on any compiler I've ever seen), what would the compiler intrinsic type be? Not some crufty int*_t typedef, but what the crufty typedef would typedef to (e.g. typedef short int16_t equivalent?)
Whatever the compiler writer decides to make it. No guarantee it's a type defined by C89 - or C99 (the spec just says the int N _t types are "signed integer types", not "standard signed integer types", so they could be "extended signed integer types").
As a practical matter, forget the spec. On this point, it's just as inane as IETF specs that still insist on using "octet" instead of byte. The reason they did that was because of Sperry(?) et. al. which didn't have an 8 bit byte size.
Sperry and Digital Equipment Corporation (PDP-10) and General Electric^W^WHoneywell (GE 645/Honeywell 6180).
If somebody wants to name the compiler and architecture that doesn't have int as 32 (that are still in use--as the 36 bit model had vacuum tubes and core memory, circa 1960 era, with some stragglers), I'd like to know about it
Presumably "vacuum tubes" is hyperbole, given that even the PDP-6 was transistorized. The only 36-bit architecture for which there are significant surviving implementations that I know of is the Univac 1100-and-descendants architecture, and Unisys does appear to claim to support C.
There's a bigger problem. sizeof(int) vs sizeof(long) between GCC/ICC/clang/just_about_anybody and VC.
When K&R first came out, int's could be either 16 bit or 32 bit and long's were 32 always. ANSI C changed this to short is 16, int is 32, and long is "large enough to contain a pointer".
No, they didn't. short int is a type the range of which is a possibly-improper subset of the range of int and int is a type the range of which is a possibly-improper subset of the range of long int. I.e., the ANSI C specification does not prevent an implementation of ANSI C from having short, int, and long int from all being 16, or all being 32, or all being 64. It also doesn't prevent a pointer from not fitting into any integral data type (C on the IBM i operating system has, I think, 128-bit pointers).
What "changed this to short is 16, int is 32, and long is "large enough to contain a pointer"" was the widespread availability of 32-bit processors, where those sizes made the most sense.
MS used the K&R model [with int being 16] because it was stuck on the pre-386 8086's. They wanted int's to be 16 for that. They assumed long's were 32 bit. This is one of the reasons that they have so many abstract types for simple types (e.g. LONG, ULONG, STATUS, etc.). They kept this model going, even during the transition from win16 to win32 (which would have been a good time to change the paradigm).
Well, for Win32, they went with int and long int both being 32-bit, just as is the case on UN*X on 32-bit processors (the ILP32 model).
The problem occurs when going to a 64 bit architecture.
Yes, for better or worse, they went with the allowed-by-ANSI-C-but-still-annoyingly-different-from-UN*X's-LP64 LLP64 model.
some of the optimizations regarding intrinsics involve microcode level, which can cause crashes in worst case, or even giving incorrect data only noticed later
Meaning that ICC, or ICC-generated code, will load new microcode for some instructions?
Or that ICC will generate code, for certain processors, that is not valid for the x86 architecture, and might crash or give incorrect data on some processors, but, on other processors, is known (because the developers at Intel know how the microcode works on those processors) to work as desired (presumably even in the face of microcode updates) and known to be faster than the architecturally-correct code?
There is nothing in C90 that forbids 64-bit integers. You are thinking about implementations.
There is also nothing in C90 that requires them, so if you're writing code that needs to run in ILP32 environments but needs to have 64-bit integers, you have to, as peppepz said, "write more platform specific code" - or rely on somebody else (e.g., GLib) to have done so for you (gint64 and guint64 being defined differently for most UN*X C compilers and for MSVC).
some of the optimizations regarding intrinsics involve microcode level, which can cause crashes in worst case, or even giving incorrect data only noticed later
Meaning that ICC, or ICC-generated code, will load new microcode for some instructions?
This is dishonest, because it's completely the wrong way to do it: you're supposed to check for feature bits, not specific CPUs, as both Intel and AMD say to do in their own optimization manuals.
I infer, perhaps incorrectly, from what Shinobi said that in some places they were checking for implementations, not for features, because, in some cases, for a given intrinsic that could expand to more than one sequence of code, even though both sequences of code could work on processors A and B, one sequence would be better on processor A and another sequence would be better on processor B.
Hint: It's loaded at boot time, from flash RAM, and those patches are made, for example, in ICC.
"Made in ICC" in what sense?
ICC has some optimization tools that can analyze the flow of the microcode in some intrinsics.
Presumably meaning the tools know about the internal implementations, on various processors, of instructions generated from the intrinsics, whether they're microcoded or not. If so, stating it that way might have not have provoked that response.
The most recognized standards are those you need to pay for.
Except for the ones that aren't those you need to pay for and the ones that used to be those you need to pay for, but aren't any more.
I love revisionist history:
The Soviets were deathly afraid of an invasion, and their nukes were aimed at a country that HAD INVADED THEM IN THE PAST. Look up Murmansk and Archangel.
Yup.
In fact, there was not one single offensive push by the USSR in its history if you look at the whole picture.
To be fair, you might want to ask the Poles about that. Yeah, the Germans invaded a bit before that, but they'd already agreed with the Soviets to carve Poland up.
Our psychopathic drive to jump into every conflict on earth (ok, maybe we largely ignore Africa)
Sadly, we didn't ignore it enough; cf. Angola and the Congo.
If Safari can do it, so can others who craft this type of object. Therefore it is a Windows 64 bit bug.
Yes, but if the fix to the Windows graphics subsystem means that whatever Safari's doing causes, instead, Safari to be terminated with an error (because it's doing something the Windows graphics subsystem doesn't want you to do), or to mis-display the HTML page in question, or something such as that, there's also a Safari bug there that should also be fixed.
Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.
As a game developer, I need graphics code to be low level, fast, and insecure. There are times I just need it to be a rocketship without handrails.
If there is a way to secure it without sacrificing speed, that's great! But doing a great deal of error checking on that level? Leave me some insecure route to blitting billions of bits to the screen without guardrails please.
Sure, as long as 1) only the applications that absolutely positively need this do their graphics through that API and other apps can't even get at that API under any circumstances (so if the app has a bug nobody can inject code to enable it) and 2) applications that do can be marked as "DANGER DANGER WILL ROBINSON IF THIS APP HAS A BUG YOU MIGHT BE SERIOUSLY PWNED". There might be a tradeoff between your requirements and the requirements of security, and the best resolution for that tradeoff might not be in your favor....
The vulnerability is caused due to an error in win32k.sys and can be exploited to corrupt memory via e.g. a specially crafted web page containing an IFRAME with an overly large "height" attribute viewed using the Apple Safari browser.
So, they blame win32k.sys - but apparently the actual bug is that you can cause something resembling a buffer overflow by feeding Safari a ridiculously large bit of data as an iFrame.
Could go either way.
Should go both ways.
Apple should fix the Safari bug so it doesn't mishandle IFRAMEs with "overly large" "height" attributes.
Microsoft should fix the in-kernel graphics code so you can't use it to break into the system.
I am also ALL ABOUT the endlessly derived works being Free.
"Just giving your software away" only works if the person to whom you're giving your software doesn't refuse to cooperate; as Stallman's goal was to force that cooperation, so that failure to cooperate could be prevented by law - and, in fact, there have been cases where users of GPLed software have, whether intentionally or not, failed to cooperate, and had to be threatened legally to get them to cooperate.
So, if you strongly believe that the derived works should be free-as-in-speech, but are willing to accept the possibility that they not remain free-as-in-speech, in exchange for allowing people the freedom to make non-free-as-in-speech derived works, that's fine, but that's not the GPL's goal. The goals may be similar, but they're not the same (and no valid argument can possibly exist that they are, as the goal of people using the GPL without dual-licensing is explicitly not to allow people the freedom to make non-free-as-in-speech derived works).
I think that is a mostly unreasonable expectation.
As do I; that was my point when saying " However, that is a bit of an obstacle to Apple "giving back" code...". It's also an obstacle to, say, OpenBSD "giving back" code to NetBSD, even though OpenBSD began as a fork from NetBSD, or DragonFly BSD "giving back" to FreeBSD; the individual *BSDs differ at the kernel level as well.
Darwin is (mostly) open source, and well documented. If a BSD team wanted to take some code from Darwin I think they have to do the porting effort.
Yes, they would - and, as somebody else noted, they did do so for HFS+, but, apparently, nobody cared enough to keep it going.
Anyway, my main point to GP was that the kernels aren't much alike.
As long as that statement applies to all four - or, if you include DragonFly BSD, five - kernels, yes. It's not as if there's "*BSD", with kernels that are essentially similar, and "Mac OS X", with a kernel that's nowhere similar. My guess would be that the place where they're most similar is at the networking layer, followed by the file system layer (Mac OS X's VFS layer is different from those of the other *BSDs, but that hasn't anything to do with Mach - it's due to
The process layer is a bit less similar, mostly due to processes being built atop Mach tasks, so the top layer is pretty similar to the other *BSDs but it's built atop a different bottom layer. The in-kernel mutual-exclusion primitives are different, but I'm not sure they're even that much the same between the *BSDs; the same applies with the mechanisms atop which userland threads are built. The XNU virtual memory system is Mach-based, but, then, so was the original 4.4-Lite VM system; however, the XNU one wasn't yanked out of Mach and reimplemented in a non-Mach context the way the 4.4-Lite one was. Then again, some of the other *BSDs have replaced their Mach-based VM system.
You seem to be arguing my 98% dissimilar is too high, and maybe it should be 90% dissimilar.
I definitely would not say "98% dissimilar" for the kernel as a whole, seriously; for moving code to XNU from one of the *BSDs, that's a major exaggeration. I wouldn't even say "90% dissimilar". I wouldn't even use a single percentage; the percentage is different for different parts of the kernel. The biggest problem I had porting to XNU to make select() handle the BIOCSRTIMEOUT timeout on BPF devices for Lion was the difference between the ways you say "I'm starting a timer, poke me when it expires". The bulk of the changes pretty much just went over.
Even if true, I think that addresses GP's objection that Apple isn't contributing kernel code back....
Yes - and, as indicated, the same applies to moving kernel-land changes between the *BSDs.