There is no no-compete or non-disclosure in my file. There is no "domain rule" blanketing what I do outside of my job scope. The skills were not attained at this current employer but instead were amassed on my own time out of sheer hobby. The fact they were not divulged at the time of interview and hire are irrelevant.
Okay, sounds like you're clear on ownership. Might be worthwhile to spend $100 (or whatever) for an hour consult with an IP attorney to be sure.
However, it seems unlikely you'll get much from your present situation because they don't have the money, the authority, and don't/won't perceive the need. Most colleges believe in the free market system. They believe they should be able to use their grad students as free labor (e.g. a former girlfriend of mine was getting a PhD in neural networks and the amount of programming she had to do, that was not related to her studies/thesis, for the professor who held her fate in his hands, was tantamount to extortion).
So, this brings up the question. Is what you've done [highly] specific to your current environment or is it good enough to be productized and sold to other places that do have the money/authority/need? In other words, could you set up [say] a website based company that could sell this, with support contracts, that other companies would be willing to pay for?
If not, it might be worthwhile as points on your resume [as others have noted]. It might allow you to elevate your pay grade on your next job.
However, if you do feel you could make a viable product out of what you've done, what are your potential markets/competition? What distinguishes what you've done from what currently exists in the proposed marketplaces? Do you have the drive/enthusiasm/endurance to take this route? You needn't give up your present position to do this, but, it might require a lot of nights/weekends for a while.
No offense, but 'sizeof' exists specifically to avoid problems. If you don't use it in your code and you assume things, you're causing your own problems.
I've even used sizeof(char) in malloc because you never know.
None taken, but I'm hardly a newbie [sigh]. And, I do most of my work in kernel space with device drivers with hardware that isn't quite working yet. So, I assume nothing, but expect everything. BTW, I didn't invent the "long contains pointer" thing, I read it in a spec/standard somewhere. But, I've been doing C for 30+ years (and programming for 40+), and I can't remember what/when, but I do remember reading it. I guess I'll have to go on a trip down memory lane to find it, or dig through the basement...
I use sizeof liberally (e.g. sizeof(struct mystruct) * numelems). But, sizeof doesn't help because the granularity is on the order of bytes not bits. In the mythical/horrific 36 bit int case, chars are 6 bits. So, you'd still get a rounding up to 1. If, the oddball arch defines char to be 16 bits, you'd be in trouble because there's no coverage for 8 bits.
Furthermore, since the spec defines a "char" as "single byte", and "byte" as being able to contain the "basic character set of the implementation". "Basic character set" appears to be defined as all the printable chars from ASCII (sans control chars). But, it also references UCS and 7-bit ASCII docs. The UCS is defined in terms of octets (and encompasses UTF-8 and variants). So, for purposes of size, I'll interpret "basic character set" as 8 bit ASCII as there is little-to-no advantage to using either odd bit sizes or sizes less than an octet (which is, by definition, 8 bits). So, I think that char being 8 bits is reasonably safe.
However, in a config file for freetype, there is a comment about the conflict between some systems having char as 16 bits (e.g. TI C54x). But, it also says "ANSI C says that sizeof(char) is always 1". Other.h files hook CHAR_BIT and error out if it's not 8
CHAR_BIT is also defined as "number of bits for smallest object that is not a bit-field (byte)". If that's not 8, your code will have to know a lot more about the environment (e.g. it will have to be intimately familiar with the fact that it's running in a DSP or FPGA, etc.) A simple sizeof(char) isn't going to help as many other things will need to be adjusted. You probably won't be using [or even have] malloc. My last embedded project was on an RISC inside an FPGA, controlling custom logic, and none of the vendor's libc stuff could be used because it would overflow the 128KB of internal static RAM that the program/data/stack had to fit into
But, I cover the sizeof(char) not being what is expected by having a static assertion. As I mentioned elsewhere on the main thread, you can do it with a special switch/case combo [in a macro], so I have, in effect: COMPILE_TIME_ASSERT(sizeof_in_bits(char) == 8); If that were to fail [unlikely], I would determine the cause. If it turns out that an 8 bit number were defined by "__builtin_int8_t", I would adjust by doing (amongst other things) #define char __builtin_int8_t. What would need be done would be potentially more involved than, but that's the essence of it
But, in rare circumstances, I'm not above hacking the compiler to get what I want (as I've done so, in the past). Or, generate the intermediate -S output and [automatically] modify that.
What most people seem to be forgetting is that you need the 8/16/32 coverage so you can talk to the hardware on most systems (e.g. if you trying to write a 32 bit quantity to a 16 bit port, you'll get a bus lockup, or bad result).
Beyond that, I prefer to use abstract typedefs (and I use a lot of them) that describe the function/semantics rather than the size. For example, suppose we had a system that involved peoples' ages. Instead of doing a "char age;" (or if you prefer "int8_t age;"), I would have
Which was only valid standards body for 5% of the human population. That is why all important languages have ISO standards these days.
I think you missed the point. I was well aware of what ISO was (I use ISO standards in other areas all the time). The "WTF is ISO C" was a subtle way of saying "the ISO C standard, just released, stinks". Too subtle for you, apparently.
The ISO atomic/thread model is so poor and anemic that it makes pthreads look positively stellar (which is hard to do, BTW). Since ANSI isn't your thing, how about POSIX from the IEEE? Much of what ISO did is an incompatible encroachment on what POSIX already defined (and belongs in the libc standard, rather than adding bloat to the language core spec).
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. Also, char is mandated to be 8 bits. So, to provide the size coverage and honor the ranking requirement, this pretty much locks in char==8,short==16,int==32. Beyond that, all bets are off. Which is why my own code uses [my own] abstract types for anything else (e.g. I have my own intptr_t equiv). But, if you're going to cover a 64 bit number, which most programmers expect to be "long long", this confines "long" to either 32 or 64 bits.
As to IBM's 128 bit address (which model specifically? some extension of S/390 or of their power* series?), 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. 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 or is badly broken.
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.
Yes, that's my point. What makes the most sense. But, if you don't have an integer type that contains a pointer, you'll have a very hard time with arrays.
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).
When win32 came out, there was a lot of hand waving from developers over making the switch from win16. I'm sure MS had a compiler option to select int as 16, for ease of transition (e.g. less squawking)
Yes, for better or worse, they went with the allowed-by-ANSI-C-but-still-annoyingly-different-from-UN*X's-LP64 LLP64 model.
This makes me believe that the cstdint* cruft was done just to work around MS's intransigence (or IBM's 128 bit arch). As somebody else pointed out on another branch of the thread, it's another OOXML style hijacking of the committee (with particular regard to threading model).
In fact, it would be truly sad if one had to include cstdint, just to get a base type of a given size. This would be so bad that I would prefer the disease to the cure.
When K&R first came out, int's could be either 16 bit or 32 bit and long's were 32 always.
except when longs were 36-bit. And already varied widely because people started running C on things other than a PDP-11.
ANSI C changed this to short is 16, int is 32, and long is "large enough to contain a pointer".
actually that's not true of C89 or C99 (I cannot comment on C1x as I don't want to spend the money on that spec).
int cannot be smaller than an int, but it does not have to be 32. and the only type large enough to contain a pointer is intptr_t.
The rest of your comment is moot as it is based on the premise above.
I'm familiar with octal based arch's such as Sperry/Univac/Honeywell/whatever. The ones that had the oddball sizes died a slow painful death. The ones that survived and prospered were the ones that had word sizes that were 8/16/32/64. Devise a 36 bit arch these days and it will go nowhere. As to what most people used after a PDP/11, it was [no surprise] a Vax.
My first C compiler was on a PDP/11 (Unix V7) and it got ported to 8086's and some m68k's (int's were 16 bit). But, some m68k's got their port from the Vax compiler, where int's were 32 bit. On the m68k's, the 32 bit compilers were a lot easier to deal with.
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?)
And speaking of crufty typedef's, before cstdint* there were caddr_t, ptrdiff_t, and uchar/byte, s16/u16, s32/u32, s64/u64. To my mind, no less clear and shorter (which is a benefit). For high usage types (e.g. int), everybody knows what you mean (e.g. you don't have to spell out "integer" as in Fortran/PL1)
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. If you wish to disagree with that, when was the last time you told somebody you were downloading a 50 megaoctet file?
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 as it would break 99.44% of existing C code. If a modern compiler/arch needs a 36 bit intrinsic type, it will not co-opt a current [well understood] type, it will create something like "__builtin_int36_t" and leave int alone. That's what intel does for its SIMD/Larabee extensions
As to the floating 32/64 bit size of "long", it appears to be supported on gcc/clang/icc(?). AFAIK, the only 32/64 bit switchable compiler that chooses not to honor this is VC. So, what's the rationale for long's floating nature in these compilers, if the "long contains pointer" isn't true?
Many of us gave up waiting on Microsoft for our development tools.
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".
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).
The problem occurs when going to a 64 bit architecture. The "long contains a pointer" model works seamlessly (more or less). But, MS, in order to prevent breakage of legacy apps, keeps their 64 bit compiler assuming a "long" is 32 bits. They've created [yet] another set of abstract types to resolve the [obvious] conflict (e.g. NEW_POINTER_DIFF [or whatever] is conditionally defined as a "long long" for 64 bit and "long" (or "int") for 32 bit). They might have a compiler option or pragma that changes this behavior, but since they tend to have their own little world, I'm guessing not.
Even so, most win32 apps need to use win*.h files. So, even if you're using a non-MS compiler, you still get tripped up by (or have to deal with) the issues surrounding this.
The Intel compiler puts MS's compiler in the dust when it comes to optimization. If I had to choose a compiler for standards compliance, I'd go with gcc. If I had to pick something to squeeze performance out of x86/amd64 binaries, I'd go with icc.
icc is a bit touchy about the amd thing. It tends to optimize for intel and the resulting code may be sub-optimal for amd because icc knows exactly the internal implementation of the x86 arch on an intel chipset.
There was a time (circa gcc 2.96) that icc produced vastly better code than gcc. However, gcc got a complete makeover starting with 4.0.x [punting on LALR grammar parsers and doing recursive descent, virtual register optimizing, etc.] and the code that it produces is pretty close to optimal as far as I can determine [I'm concerned with speed, so I disassemble a lot to be sure].
Also, icc is x86 specific. Whereas gcc does a plethora of arch's. There is a disincentive [for intel] to make icc multiarch.
Without standards, code written on one platform wouldn't work on another, which was kind of the point of inventing programming languages in the first place, going back to that first cross-platform COBOL demonstration in late 1960.
Shocked that I even have to explain this.
The original point was that, after K&R, ANSI was the standards body for C. Not that you don't need standards. Since I, too, starting by using K&R in 1981, and then ANSI, I, also, want to know "WTF is ISO C". Could be wrong, but I can't recall ANSI charging for the standard like ISO wants to [I've downloaded the draft, BTW].
Shocked that you misread the original post.
Re:Static asserts have been around for a long time
on
ISO Updates C Standard
·
· Score: 1
Static assertions, so you can do things like _Static_assert(sizeof(int) == 4, "This code path should not be used in ILP64 platforms!"); and get a compile-time error if it is.
There was already a macro for that, involving declaring an array whose size is 1 when true or -1 (and thus invalid in a way that produces a diagnostic) when false.
I implemented such a macro using a switch statement that produced a "duplicate case" diagnostic if the assertion was false
Actually, Gnome 3 is trying to clone Apple--and that's the problem.... This is so close to what an iPad/iOS does that I'm surprised that Apple isn't suing Gnome for patent infringement...
Actually, there is one Ubuntu based distro - PearOS - which uses Gnome 3.2, but has customized it exactly so that it looks & feels identical to OS-X. Actually, if Gnome 3.2 were to completely morph into that, it would be an improvement - at least people who want OS-X on non-Mac PCs could then install and run it on their systems. Yeah, there will be some differences, like Opera or Firefox instead of Safari (wonder whether the Camino browser runs on anything other than Macs) but otherwise, the UX will be the same.
When I said "that's the problem" what I meant was "lack of options" (which I explained in a bit more detail on another branch of the main thread). The iOS model is geared toward a touchscreen which has only one "mouse button" (your finger). If the Gnome 3 developers want to make Gnome 3 a 100% clone of the iOS user interface to attract more market share--fine.
But, those of us who want a our favorites on a toolbar on the work surface and not in an "Activities" window (which takes more clicks to get to and use) should be able to configure that. In fact, the entire look-and-feel should be as easy to configure as selecting a different background wallpaper.
Thus, a regular user, who has done no reconfiguration, gets the default look-and-feel, which is an artistic choice. If they're happy, nothing further needs be done. Choosing a default that appeals to the widest audience is a good thing, providing that it's easy for power users to reconfigure it as they chose.
What's truly incredible is that given all the XML config files used in Gnome 3 for trivial stuff, that enabling alternatives is so painful/impossible. Most users might not want to do this, but some might be willing to download an alternative configuration and install it, just as they do a.png for a background. There could be a site for this, with user rankings, just like the site for add-ons for Firefox. For example, many people like AdBlocker+, even though many could not write it themselves.
The fact that the Gnome 3 developers have gone the opposite way and prevented such an aftermarket ecosystem from developing is hubris, plain and simple. Or, lack of [sufficient] programming skill to architect it that way.
so they have patents for "white X with a black background with a white circle around it" nowadays? this has to come to an end sooner or later.
In reality, it's just about that bad [or worse]. There was an article recently (see apple.slashdot.org) about how Apple lawyers were actually arguing (via a court brief against Samsung) about "how not to infringe" [Apple patents]. Basically, no rounded corners on the tablet/phone, and no flat screen, and a host of other psychotic restrictions (e.g. device can't recharge its own rechargeable batteries).
There's nothing wrong with ignoring the needs of individual users to tailor a generally good experience, _so long as power-users are still given the ability to pick the option best for them as individuals_. That last part is the important part that Apple has forgotten of late.
Actually, Gnome 3 is trying to clone Apple--and that's the problem. If you look at the activities panel and scroll over an active window, you'll see a "dismiss" that is a white X with a black background with a white circle around it. This is so close to what an iPad/iOS does that I'm surprised that Apple isn't suing Gnome for patent infringement...
You know what's best for everyone? Configurability. but Gnome used to have GConf (does Gnome 3 have it? I don't know).
Gnome 3 does have GConf but it's probably not installed by default. I had to go look for it.
In Gnome 2, you could create an icon on your toolbar for your highly used shortcuts.
In Gnome 2, you could put a terminal icon on the toolbar and a single click brought up a new instance. To do this in Gnome 3, well, you can't... To get a new terminal window, you click on "Activities", find the terminal icon (assuming of course, you've already added it to "Favorites"), then right click on it, slide right to the menu, and right click on "New Window"
So, something that used to be a single click operation is now a three step process. This is an improvement???
It's perfectly fine to make the starting configuration a simple one for the average user. But, it should be configurable enough for those that want more sophistication to have it as well. Gnome 3 developers have decided to dumb things down and then lock down that decision by removing as much configurability as they could.
You can have the best of both. Have your initial development start closed to help keep your cards close to your chest, then when you're comfortable and you believe your code base is relevant enough, open source it. This is particularly helpful if what you're creating happens to be competitive to other products.
Open sourcing can provide [some] protection against software patent trolls as prior art. Also, consider the Aladdin/Ghostscript model.
By open sourcing, you create prior art that can defend against software patent lawsuits without having to go to the expense of actually getting a patent--a time/money consuming process for a small company.
I may be wrong about this, but, Aladdin used to publish a GPL version of Ghostscript with a one year delay. They made money from their proprietary version, which commercial companies wanted, because it had the latest/greatest features and bug fixes and commercial grade (paid) support. They would then release a given version as GPL, but, even with the availability of the open version, commercial companies still would be willing to use the paid versions.
This is similar to RedHat with RHEL. They make money off of it, even though Fedora and CentOS exist.
As C is a subset of C++, it can't possibly be better. Every C program can be written in C++.
That is simply not correct. For mission critical, realtime, you spend more time ensuring that the C++ doesn't generate code you don't want. To do that, you have to disassemble the code to be sure. For OS's, there are things that you _have_ to do were you need precision control that C++ can _not_ provide. That is why there is some effort afoot to come up with a standard for a C++ _subset_ for realtime (If I recall correctly, it will omit copy constructors, for example).
They aren't widely used though, in the projects I've seen (except the Linux kernel).
Part of my job is to replace ugly, unsafe multi-line macros with inline functions...
something which was only made possible earlier this year (2011), when we ditched our
last C compiler which didn't understand C99.
I use a #define to abstract the inline (e.g. #define myinline extern inline) and ifdef it away if the compiler doesn't support it. For my personal stuff, I had (and still have a few stragglers) of large (pre-inline) macros, and I replace them with inlines whenever I find them. BTW, what compiler didn't have the inlines?
Which brings us back to part of TFA: it's hard to change a language which is widely used,
and harder to make the programmers use the new stuff.
(Personally I still think it's the way to go.)
I think the real point here is the programmers. A good programmer will be able to use the features of any language and produce good code. A bad programmer will take the same features and screw things up. At my last job, everybody was waxing on about using C++. But, they all used it as straight C. No class definitions, only structs. And, when one programmer actually used inheritance on one class (no templates or abstract virtual anything), one of the other programmers starting complaining about not using "confusing features".
We used to do OO programming in assembler in the 70's. IBM mainframes had 16 GP registers and the assembler had a DSECT directive that was the equivalent of a struct. Another directive was USING. So, if you had a dsect named "myblock" that had a data element named "mydata", you could specify "using myblock,r10". Then, you could just refer to "mydata" without any base register (e.g. move 5,mydata). This is just like mydata being a class element in a member function.
Second line works in C++, but is a compiler error in C. You have to use #define instead.
Fair enough. But, I would use a #define or an enum (which you _can_ use in C) [particularly for an all uppercase]. And I would prefer those to the const for this example because it's easier to put them in a header file and put the array instance in a.c file.
If you could replace the "5" with a reference to an extern (e.g. (cast int) &dynamic_size) and define it with a linker option -Adynamic_size=5 [and have it all work], this would be beneficial.
These are language capabilities, but not necessarily benefits.
C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates.
Ahem. C has had inline functions for at least a decade. And what better const semantics would you be referring to?
And because it's so offensive, I didn't limit the boycott to not just buying the games on the PC. I skipped the games across all platforms. No Assassin's Creed for me? It's a bit of a pity, but I'll live. I mean, really, I'm not the kind of gamer it's a fantastic idea to be upsetting. I buy 30+ games per year (as you can see from the end-of-year roundups I do in my journal).
Ditto. I buy fewer games (even a few Myst* in the past), never pirated any, but I will _never_ buy (or play) a Ubisoft game ever again as long as I live. Because of articles about Ubisoft's rabid approach to DRM, and their smug, self-validating attitude that if their PC sales are down, it must be because of piracy.
No, Ubisoft, it's because of the boycott (of which I'm another proud member)...
Even if you could do the encryption approach or a data security erase approach (e.g. write over each block 100 times using some DOD approved algorithm), it might be better to just get new drives.
---
Sounds like you've had the prior contract for a few years. Add in the next few years for the new contract. Sounds like six years or so. This might exceed the expected longevity of the hard drives in question. They might become ripe for a head crash or equivalent. In between contracts would probably be a less painful time to do the replacement to insure better uptime during the new contract. Perhaps getting more information on the MTBF for the drives might help decide this.
Also, the capacities of drives go up and their costs go down over time. You may need fewer, larger capacity drives to meet your requirements, so the cost might be less.
This is just one more example of Apple being unaware/clueless of tech outside of Apple. I sincerely hope Apple isn't claiming this as another one of their innovations.
The fundamental approach is flawed. They chose to use a special "launchd" app to control this rather than adding the extra security to the OS kernel fork/exec. Hence, the security flaw that these researchers found.
In typical Apple fashion, after being notified, they're trying to sweep it under the rug by revising the developer documentation.
In the context Apple is using the term "sandboxing" here, this is a description of "fine grained" privileges. Linux has had fine grained privileges for years. Under Linux, they're called "capabilities". And it is the Linux kernel that does the enforcement, so that the type of "end around" that is the security flaw wouldn't work. Also, Linux already has selinux in the non-MLS mode that does much the same thing [and more].
Even if the Linux kernel developers had decided to use the "launchd" approach, they would have [in all probability] carried over the privilege list from the original sender of the message with the message itself and made it available to launchd so that launchd would not allow escalation of privilege level.
So, Apple... Bad architecture and bad implementation of the architecture.
And, the literature on this has been around for decades.
Slashdot Mirror
There is no no-compete or non-disclosure in my file. There is no "domain rule" blanketing what I do outside of my job scope. The skills were not attained at this current employer but instead were amassed on my own time out of sheer hobby. The fact they were not divulged at the time of interview and hire are irrelevant.
Okay, sounds like you're clear on ownership. Might be worthwhile to spend $100 (or whatever) for an hour consult with an IP attorney to be sure.
However, it seems unlikely you'll get much from your present situation because they don't have the money, the authority, and don't/won't perceive the need. Most colleges believe in the free market system. They believe they should be able to use their grad students as free labor (e.g. a former girlfriend of mine was getting a PhD in neural networks and the amount of programming she had to do, that was not related to her studies/thesis, for the professor who held her fate in his hands, was tantamount to extortion).
So, this brings up the question. Is what you've done [highly] specific to your current environment or is it good enough to be productized and sold to other places that do have the money/authority/need? In other words, could you set up [say] a website based company that could sell this, with support contracts, that other companies would be willing to pay for?
If not, it might be worthwhile as points on your resume [as others have noted]. It might allow you to elevate your pay grade on your next job.
However, if you do feel you could make a viable product out of what you've done, what are your potential markets/competition? What distinguishes what you've done from what currently exists in the proposed marketplaces? Do you have the drive/enthusiasm/endurance to take this route? You needn't give up your present position to do this, but, it might require a lot of nights/weekends for a while.
No offense, but 'sizeof' exists specifically to avoid problems. If you don't use it in your code and you assume things, you're causing your own problems.
I've even used sizeof(char) in malloc because you never know.
None taken, but I'm hardly a newbie [sigh]. And, I do most of my work in kernel space with device drivers with hardware that isn't quite working yet. So, I assume nothing, but expect everything. BTW, I didn't invent the "long contains pointer" thing, I read it in a spec/standard somewhere. But, I've been doing C for 30+ years (and programming for 40+), and I can't remember what/when, but I do remember reading it. I guess I'll have to go on a trip down memory lane to find it, or dig through the basement ...
I use sizeof liberally (e.g. sizeof(struct mystruct) * numelems). But, sizeof doesn't help because the granularity is on the order of bytes not bits. In the mythical/horrific 36 bit int case, chars are 6 bits. So, you'd still get a rounding up to 1. If, the oddball arch defines char to be 16 bits, you'd be in trouble because there's no coverage for 8 bits.
Furthermore, since the spec defines a "char" as "single byte", and "byte" as being able to contain the "basic character set of the implementation". "Basic character set" appears to be defined as all the printable chars from ASCII (sans control chars). But, it also references UCS and 7-bit ASCII docs. The UCS is defined in terms of octets (and encompasses UTF-8 and variants). So, for purposes of size, I'll interpret "basic character set" as 8 bit ASCII as there is little-to-no advantage to using either odd bit sizes or sizes less than an octet (which is, by definition, 8 bits). So, I think that char being 8 bits is reasonably safe.
However, in a config file for freetype, there is a comment about the conflict between some systems having char as 16 bits (e.g. TI C54x). But, it also says "ANSI C says that sizeof(char) is always 1". Other .h files hook CHAR_BIT and error out if it's not 8
CHAR_BIT is also defined as "number of bits for smallest object that is not a bit-field (byte)". If that's not 8, your code will have to know a lot more about the environment (e.g. it will have to be intimately familiar with the fact that it's running in a DSP or FPGA, etc.) A simple sizeof(char) isn't going to help as many other things will need to be adjusted. You probably won't be using [or even have] malloc. My last embedded project was on an RISC inside an FPGA, controlling custom logic, and none of the vendor's libc stuff could be used because it would overflow the 128KB of internal static RAM that the program/data/stack had to fit into
But, I cover the sizeof(char) not being what is expected by having a static assertion. As I mentioned elsewhere on the main thread, you can do it with a special switch/case combo [in a macro], so I have, in effect: COMPILE_TIME_ASSERT(sizeof_in_bits(char) == 8); If that were to fail [unlikely], I would determine the cause. If it turns out that an 8 bit number were defined by "__builtin_int8_t", I would adjust by doing (amongst other things) #define char __builtin_int8_t. What would need be done would be potentially more involved than, but that's the essence of it
But, in rare circumstances, I'm not above hacking the compiler to get what I want (as I've done so, in the past). Or, generate the intermediate -S output and [automatically] modify that.
What most people seem to be forgetting is that you need the 8/16/32 coverage so you can talk to the hardware on most systems (e.g. if you trying to write a 32 bit quantity to a 16 bit port, you'll get a bus lockup, or bad result).
Beyond that, I prefer to use abstract typedefs (and I use a lot of them) that describe the function/semantics rather than the size. For example, suppose we had a system that involved peoples' ages. Instead of doing a "char age;" (or if you prefer "int8_t age;"), I would have
ANSI was the standards body for C.
Which was only valid standards body for 5% of the human population. That is why all important languages have ISO standards these days.
I think you missed the point. I was well aware of what ISO was (I use ISO standards in other areas all the time). The "WTF is ISO C" was a subtle way of saying "the ISO C standard, just released, stinks". Too subtle for you, apparently.
The ISO atomic/thread model is so poor and anemic that it makes pthreads look positively stellar (which is hard to do, BTW). Since ANSI isn't your thing, how about POSIX from the IEEE? Much of what ISO did is an incompatible encroachment on what POSIX already defined (and belongs in the libc standard, rather than adding bloat to the language core spec).
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. Also, char is mandated to be 8 bits. So, to provide the size coverage and honor the ranking requirement, this pretty much locks in char==8,short==16,int==32. Beyond that, all bets are off. Which is why my own code uses [my own] abstract types for anything else (e.g. I have my own intptr_t equiv). But, if you're going to cover a 64 bit number, which most programmers expect to be "long long", this confines "long" to either 32 or 64 bits.
As to IBM's 128 bit address (which model specifically? some extension of S/390 or of their power* series?), 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. 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 or is badly broken.
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.
Yes, that's my point. What makes the most sense. But, if you don't have an integer type that contains a pointer, you'll have a very hard time with arrays.
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).
When win32 came out, there was a lot of hand waving from developers over making the switch from win16. I'm sure MS had a compiler option to select int as 16, for ease of transition (e.g. less squawking)
Yes, for better or worse, they went with the allowed-by-ANSI-C-but-still-annoyingly-different-from-UN*X's-LP64 LLP64 model.
This makes me believe that the cstdint* cruft was done just to work around MS's intransigence (or IBM's 128 bit arch). As somebody else pointed out on another branch of the thread, it's another OOXML style hijacking of the committee (with particular regard to threading model).
In fact, it would be truly sad if one had to include cstdint, just to get a base type of a given size. This would be so bad that I would prefer the disease to the cure.
When K&R first came out, int's could be either 16 bit or 32 bit and long's were 32 always.
except when longs were 36-bit. And already varied widely because people started running C on things other than a PDP-11.
ANSI C changed this to short is 16, int is 32, and long is "large enough to contain a pointer".
actually that's not true of C89 or C99 (I cannot comment on C1x as I don't want to spend the money on that spec). int cannot be smaller than an int, but it does not have to be 32. and the only type large enough to contain a pointer is intptr_t.
The rest of your comment is moot as it is based on the premise above.
I'm familiar with octal based arch's such as Sperry/Univac/Honeywell/whatever. The ones that had the oddball sizes died a slow painful death. The ones that survived and prospered were the ones that had word sizes that were 8/16/32/64. Devise a 36 bit arch these days and it will go nowhere. As to what most people used after a PDP/11, it was [no surprise] a Vax.
My first C compiler was on a PDP/11 (Unix V7) and it got ported to 8086's and some m68k's (int's were 16 bit). But, some m68k's got their port from the Vax compiler, where int's were 32 bit. On the m68k's, the 32 bit compilers were a lot easier to deal with.
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?)
And speaking of crufty typedef's, before cstdint* there were caddr_t, ptrdiff_t, and uchar/byte, s16/u16, s32/u32, s64/u64. To my mind, no less clear and shorter (which is a benefit). For high usage types (e.g. int), everybody knows what you mean (e.g. you don't have to spell out "integer" as in Fortran/PL1)
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. If you wish to disagree with that, when was the last time you told somebody you were downloading a 50 megaoctet file?
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 as it would break 99.44% of existing C code. If a modern compiler/arch needs a 36 bit intrinsic type, it will not co-opt a current [well understood] type, it will create something like "__builtin_int36_t" and leave int alone. That's what intel does for its SIMD/Larabee extensions
As to the floating 32/64 bit size of "long", it appears to be supported on gcc/clang/icc(?). AFAIK, the only 32/64 bit switchable compiler that chooses not to honor this is VC. So, what's the rationale for long's floating nature in these compilers, if the "long contains pointer" isn't true?
Many of us gave up waiting on Microsoft for our development tools.
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".
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).
The problem occurs when going to a 64 bit architecture. The "long contains a pointer" model works seamlessly (more or less). But, MS, in order to prevent breakage of legacy apps, keeps their 64 bit compiler assuming a "long" is 32 bits. They've created [yet] another set of abstract types to resolve the [obvious] conflict (e.g. NEW_POINTER_DIFF [or whatever] is conditionally defined as a "long long" for 64 bit and "long" (or "int") for 32 bit). They might have a compiler option or pragma that changes this behavior, but since they tend to have their own little world, I'm guessing not.
Even so, most win32 apps need to use win*.h files. So, even if you're using a non-MS compiler, you still get tripped up by (or have to deal with) the issues surrounding this.
The Intel compiler puts MS's compiler in the dust when it comes to optimization. If I had to choose a compiler for standards compliance, I'd go with gcc. If I had to pick something to squeeze performance out of x86/amd64 binaries, I'd go with icc.
icc is a bit touchy about the amd thing. It tends to optimize for intel and the resulting code may be sub-optimal for amd because icc knows exactly the internal implementation of the x86 arch on an intel chipset.
There was a time (circa gcc 2.96) that icc produced vastly better code than gcc. However, gcc got a complete makeover starting with 4.0.x [punting on LALR grammar parsers and doing recursive descent, virtual register optimizing, etc.] and the code that it produces is pretty close to optimal as far as I can determine [I'm concerned with speed, so I disassemble a lot to be sure].
Also, icc is x86 specific. Whereas gcc does a plethora of arch's. There is a disincentive [for intel] to make icc multiarch.
Without standards, code written on one platform wouldn't work on another, which was kind of the point of inventing programming languages in the first place, going back to that first cross-platform COBOL demonstration in late 1960.
Shocked that I even have to explain this.
The original point was that, after K&R, ANSI was the standards body for C. Not that you don't need standards. Since I, too, starting by using K&R in 1981, and then ANSI, I, also, want to know "WTF is ISO C". Could be wrong, but I can't recall ANSI charging for the standard like ISO wants to [I've downloaded the draft, BTW].
Shocked that you misread the original post.
Static assertions, so you can do things like _Static_assert(sizeof(int) == 4, "This code path should not be used in ILP64 platforms!"); and get a compile-time error if it is.
There was already a macro for that, involving declaring an array whose size is 1 when true or -1 (and thus invalid in a way that produces a diagnostic) when false.
I implemented such a macro using a switch statement that produced a "duplicate case" diagnostic if the assertion was false
Actually, Gnome 3 is trying to clone Apple--and that's the problem.... This is so close to what an iPad/iOS does that I'm surprised that Apple isn't suing Gnome for patent infringement ...
Actually, there is one Ubuntu based distro - PearOS - which uses Gnome 3.2, but has customized it exactly so that it looks & feels identical to OS-X. Actually, if Gnome 3.2 were to completely morph into that, it would be an improvement - at least people who want OS-X on non-Mac PCs could then install and run it on their systems. Yeah, there will be some differences, like Opera or Firefox instead of Safari (wonder whether the Camino browser runs on anything other than Macs) but otherwise, the UX will be the same.
When I said "that's the problem" what I meant was "lack of options" (which I explained in a bit more detail on another branch of the main thread). The iOS model is geared toward a touchscreen which has only one "mouse button" (your finger). If the Gnome 3 developers want to make Gnome 3 a 100% clone of the iOS user interface to attract more market share--fine.
But, those of us who want a our favorites on a toolbar on the work surface and not in an "Activities" window (which takes more clicks to get to and use) should be able to configure that. In fact, the entire look-and-feel should be as easy to configure as selecting a different background wallpaper.
Thus, a regular user, who has done no reconfiguration, gets the default look-and-feel, which is an artistic choice. If they're happy, nothing further needs be done. Choosing a default that appeals to the widest audience is a good thing, providing that it's easy for power users to reconfigure it as they chose.
What's truly incredible is that given all the XML config files used in Gnome 3 for trivial stuff, that enabling alternatives is so painful/impossible. Most users might not want to do this, but some might be willing to download an alternative configuration and install it, just as they do a .png for a background. There could be a site for this, with user rankings, just like the site for add-ons for Firefox. For example, many people like AdBlocker+, even though many could not write it themselves.
The fact that the Gnome 3 developers have gone the opposite way and prevented such an aftermarket ecosystem from developing is hubris, plain and simple. Or, lack of [sufficient] programming skill to architect it that way.
so they have patents for "white X with a black background with a white circle around it" nowadays? this has to come to an end sooner or later.
In reality, it's just about that bad [or worse]. There was an article recently (see apple.slashdot.org) about how Apple lawyers were actually arguing (via a court brief against Samsung) about "how not to infringe" [Apple patents]. Basically, no rounded corners on the tablet/phone, and no flat screen, and a host of other psychotic restrictions (e.g. device can't recharge its own rechargeable batteries).
There's nothing wrong with ignoring the needs of individual users to tailor a generally good experience, _so long as power-users are still given the ability to pick the option best for them as individuals_. That last part is the important part that Apple has forgotten of late.
Actually, Gnome 3 is trying to clone Apple--and that's the problem. If you look at the activities panel and scroll over an active window, you'll see a "dismiss" that is a white X with a black background with a white circle around it. This is so close to what an iPad/iOS does that I'm surprised that Apple isn't suing Gnome for patent infringement ...
You know what's best for everyone? Configurability. but Gnome used to have GConf (does Gnome 3 have it? I don't know).
Gnome 3 does have GConf but it's probably not installed by default. I had to go look for it.
In Gnome 2, you could create an icon on your toolbar for your highly used shortcuts.
In Gnome 2, you could put a terminal icon on the toolbar and a single click brought up a new instance. To do this in Gnome 3, well, you can't ... To get a new terminal window, you click on "Activities", find the terminal icon (assuming of course, you've already added it to "Favorites"), then right click on it, slide right to the menu, and right click on "New Window"
So, something that used to be a single click operation is now a three step process. This is an improvement???
It's perfectly fine to make the starting configuration a simple one for the average user. But, it should be configurable enough for those that want more sophistication to have it as well. Gnome 3 developers have decided to dumb things down and then lock down that decision by removing as much configurability as they could.
You can have the best of both. Have your initial development start closed to help keep your cards close to your chest, then when you're comfortable and you believe your code base is relevant enough, open source it. This is particularly helpful if what you're creating happens to be competitive to other products.
Open sourcing can provide [some] protection against software patent trolls as prior art. Also, consider the Aladdin/Ghostscript model.
By open sourcing, you create prior art that can defend against software patent lawsuits without having to go to the expense of actually getting a patent--a time/money consuming process for a small company.
I may be wrong about this, but, Aladdin used to publish a GPL version of Ghostscript with a one year delay. They made money from their proprietary version, which commercial companies wanted, because it had the latest/greatest features and bug fixes and commercial grade (paid) support. They would then release a given version as GPL, but, even with the availability of the open version, commercial companies still would be willing to use the paid versions.
This is similar to RedHat with RHEL. They make money off of it, even though Fedora and CentOS exist.
Assembly? Only language we ever needed was machine code - 0s & 1s - b'cos ultimately, that's all that the machine recognizes
I've written scores of assembly. Machine code? You're a better man than I am, Gunga Din ...
Only language we ever needed was vacuum tubes. You putzes just aren't using it right.
Only language we ever needed was Jacquard looms. You putzes just aren't using it right.
Only language we ever needed was punchcards. You putzes just aren't using it right.
I've actually used punchcards ...
Only language we ever needed was plugboards. You putzes just aren't using it right.
For system-level native tasks, C is better.
As C is a subset of C++, it can't possibly be better. Every C program can be written in C++.
That is simply not correct. For mission critical, realtime, you spend more time ensuring that the C++ doesn't generate code you don't want. To do that, you have to disassemble the code to be sure. For OS's, there are things that you _have_ to do were you need precision control that C++ can _not_ provide. That is why there is some effort afoot to come up with a standard for a C++ _subset_ for realtime (If I recall correctly, it will omit copy constructors, for example).
They aren't widely used though, in the projects I've seen (except the Linux kernel). Part of my job is to replace ugly, unsafe multi-line macros with inline functions ...
something which was only made possible earlier this year (2011), when we ditched our
last C compiler which didn't understand C99.
I use a #define to abstract the inline (e.g. #define myinline extern inline) and ifdef it away if the compiler doesn't support it. For my personal stuff, I had (and still have a few stragglers) of large (pre-inline) macros, and I replace them with inlines whenever I find them. BTW, what compiler didn't have the inlines?
Which brings us back to part of TFA: it's hard to change a language which is widely used, and harder to make the programmers use the new stuff. (Personally I still think it's the way to go.)
I think the real point here is the programmers. A good programmer will be able to use the features of any language and produce good code. A bad programmer will take the same features and screw things up. At my last job, everybody was waxing on about using C++. But, they all used it as straight C. No class definitions, only structs. And, when one programmer actually used inheritance on one class (no templates or abstract virtual anything), one of the other programmers starting complaining about not using "confusing features".
We used to do OO programming in assembler in the 70's. IBM mainframes had 16 GP registers and the assembler had a DSECT directive that was the equivalent of a struct. Another directive was USING. So, if you had a dsect named "myblock" that had a data element named "mydata", you could specify "using myblock,r10". Then, you could just refer to "mydata" without any base register (e.g. move 5,mydata). This is just like mydata being a class element in a member function.
const int SIZE=5; int arr[SIZE];
Second line works in C++, but is a compiler error in C. You have to use #define instead.
Fair enough. But, I would use a #define or an enum (which you _can_ use in C) [particularly for an all uppercase]. And I would prefer those to the const for this example because it's easier to put them in a header file and put the array instance in a .c file.
If you could replace the "5" with a reference to an extern (e.g. (cast int) &dynamic_size) and define it with a linker option -Adynamic_size=5 [and have it all work], this would be beneficial.
These are language capabilities, but not necessarily benefits.
C++ provides several very fundamental features which make it hugely superior to C: inline functions, better const semantics, reference types, and templates.
Ahem. C has had inline functions for at least a decade. And what better const semantics would you be referring to?
And because it's so offensive, I didn't limit the boycott to not just buying the games on the PC. I skipped the games across all platforms. No Assassin's Creed for me? It's a bit of a pity, but I'll live. I mean, really, I'm not the kind of gamer it's a fantastic idea to be upsetting. I buy 30+ games per year (as you can see from the end-of-year roundups I do in my journal).
Ditto. I buy fewer games (even a few Myst* in the past), never pirated any, but I will _never_ buy (or play) a Ubisoft game ever again as long as I live. Because of articles about Ubisoft's rabid approach to DRM, and their smug, self-validating attitude that if their PC sales are down, it must be because of piracy.
No, Ubisoft, it's because of the boycott (of which I'm another proud member) ...
---
Sounds like you've had the prior contract for a few years. Add in the next few years for the new contract. Sounds like six years or so. This might exceed the expected longevity of the hard drives in question. They might become ripe for a head crash or equivalent. In between contracts would probably be a less painful time to do the replacement to insure better uptime during the new contract. Perhaps getting more information on the MTBF for the drives might help decide this.
Also, the capacities of drives go up and their costs go down over time. You may need fewer, larger capacity drives to meet your requirements, so the cost might be less.
The fundamental approach is flawed. They chose to use a special "launchd" app to control this rather than adding the extra security to the OS kernel fork/exec. Hence, the security flaw that these researchers found.
In typical Apple fashion, after being notified, they're trying to sweep it under the rug by revising the developer documentation.
In the context Apple is using the term "sandboxing" here, this is a description of "fine grained" privileges. Linux has had fine grained privileges for years. Under Linux, they're called "capabilities". And it is the Linux kernel that does the enforcement, so that the type of "end around" that is the security flaw wouldn't work. Also, Linux already has selinux in the non-MLS mode that does much the same thing [and more].
Even if the Linux kernel developers had decided to use the "launchd" approach, they would have [in all probability] carried over the privilege list from the original sender of the message with the message itself and made it available to launchd so that launchd would not allow escalation of privilege level.
So, Apple ... Bad architecture and bad implementation of the architecture.
And, the literature on this has been around for decades.