Which is totally useless if you happen to be authoring a library which other developers depend on.
Not true - you can put the annotations in your header files and then other developers can use splint just the same. If they prefer not to use it, and would rather take on the burden (of checking that a parameter is non-null) for themselves, then fair enough. Either way you've documented that the pointer must not be null.
If you want to be 'nice' and fail cleanly when given a null pointer then yes you do need extra code - but the standard C library is not written to do that and I don't feel that third party libraries need be either. If passing a null pointer gives a nice, clean segfault that lets you bring up the offending line in the debugger, that's good enough.
(If your function doesn't have an explicit precondition saying the pointer must not be null, then that's different, of course.)
It's very hard to guarantee that a non-null pointer will never be passed as a parameter at compile time!
Indeed, which is why checkers like splint use annotations. You annotate your code to say which variables or parameters can be null and which can't be; then the checker only has to look at each function individually and at the boundaries between functions. Just the same as the compiler checks that the parameter type is correct when you call a function expecting an int.
It's no big deal; arguably you should be documenting whether your function allows null for its parameters anyway, and having this documentation in the code itself so it can be automatically checked is better. Have a look at Nice for a similar idea applied to Java.
But you do have to adopt this bondage-and-discipline across the whole program; if some of your code is annotated and some isn't, the checker won't be able to analyse the whole program.
that just means you're checking the value at multiple other points, as opposed to a central location, ie. the function that uses it.
The compiler or static checker is doing the work, so no extra runtime checking is necessary. You are writing the function specification in one central location - 'this function expects its parameter to be not null'.
Your functions should always check their parameters are valid, and non-null check takes all of 1 clock cycle, plus a fetch (if it's not in a register),
I agree that one extra clock cycle, or even several, is not a big deal for most applications (even if it happens on every function entry and exit). But it is a bunch of extra code to write, and only works to dodge a problem (calling with a null pointer) once it happens at run time. Whereas with static checking you can be certain there is *no possibility* of calling with a null pointer, and if you accidentally write a call that might be null, you get pointed to the exact source line when building.
It's worth noting that many important C libraries do not follow your rule of always checking arguments - the C standard library in particular does not.
Unless I'm missing something major here, I'm now not at all surprised at the terrible quality of some of the code out there.
I don't really understand this comment - having a code base where you can be _certain_ there will be no null pointer errors, because the checker has proved it statically, is surely better than code where you hope there are no such errors, and added runtime checks to catch them if they happen, but you don't really know.
(Not that a checker like splint would usually let the programmer eliminate all such errors - but it can certainly cut out a huge chunk of them, and alert you to the things it couldn't check statically, so you can test them at run time.)
No, because the check happens at compile time. Firstly this means you find the error sooner. Secondly there is no run-time overhead. Most importantly if it can statically check that the pointer is not null (or any other property), then you know that this is _always_ true, for _all_ inputs to your program. Whereas assert() will find a bug only if your test suite is comprehensive enough. Finally, if the checker does find a case where a null pointer might be passed, it can tell you which line of source that is ('foo(x) is called on line 100, but x might be null and foo() expects a non-null pointer').
I'm not arguing against assert() or run-time checking in any way, just pointing out that a compile-time check is better in cases where it is possible. But there's a limit to how much compilers or static checkers can figure out, so you have to use run-time checks for more complex things. Normally you'd use a mixture of both.
The null pointer in C is written as 0, and tests as false when used as a Boolean. It might be stored internally as the bit value 1010101, but still in C source code it is 0, and false. So
None of that bug report is at all useful if there is no logical way for all of those preconditions they listed to actually be met.
True, of course. However it gets insanely complicated to start worrying about 'is it ever possible that p == 0 and q != 0 and a < b + 3 and x != y...'. The only way is to fix the function so that it has a nice simple set of preconditions, which you can easily check are being followed. And if the preconditions aren't met, technically you are in the right if you segfault or do anything else, but in practice it may be better to log a message and keep the server running.
But not 'real' ASCII support
on
X11 in ASCII
·
· Score: 1
As far as I can tell from the screenshots they are treating the text console as a big bitmap (using aalib) and then rendering onto that using the standard X fonts.
A more usable alternative would be to provide the console font to X applications - perhaps as the only font available - and then render it using real letters. Pixel positioning might be hard, you might have to round to the nearest eight pixels or something.
The next stage is to make (or adapt) a window manager that knows about the chunky pixels and can draw windows with one-character borders that look reasonable.
If you make a 500x400 text console it's not that different to an ordinary bitmapped display. This is a neat hack, but getting X to run and be usable on an 80x25 screen would be much harder.
Remember that 'text mode Qt' announced on Slashdot a while back? I think it turned out to be a hoax.
So in fact, it's using a different media type, and you just have to hope that your blank CDs are high-quality enough to support this. Who cares, if you want high capacity, incompatible-with-ordinary-CD-players burning you'd just use one of the many DVD-writable formats.
I'd like to see a burner that can write both sides of a CD at once, and a source of cheap double-sided CD blanks, that would be kewl. Because you can fit twice as much on a disc but keep compatibility with older drives (at the expense of some manual flipping).
Remember when Slashdot did a phone interview with Metallica and the editors just transcribed everything including ums and ahs. People said it was deliberate to make Lars sound foolish, but the editors thought it was just honesty. I think it's good editorial practice to edit and chop repetitive spoken mumblings, or at least give the interviewee a chance to rephrase them more concisely.
The main issue with on-board sound is not the sound quality (nowadays, even cheap hardware sounds good enough for games and Oggs) but the possible lack of drivers. Does Linux have free drivers for most onboard sound chipsets?
I know that English is not Linus's mother tongue but he always seemed to use it pretty well... until now:
A: I think it works well because I don't have the final say. I have this final say in my tree. It is special in that a lot of people trust my tree. So some people will not use it if it is not my tree. That is a minority. But most people end up using various appendages. My tree is really not. Yes I have the final say on my tree. There is always this forking but there is always this joining. There is more forking than there is joining. But that just means that there are all these dead branches that not end up not being interesting. My branch is to some degree, you could think of it as the trunk of the tree. People try to join back into my tree.
Why should I care about encrypting the download of mail? It goes in clear text across the network anyway; everyone knows you should not write anything in electronic mail that you wouldn't send on a postcard. That's what PGP is for.
(It is a bit more worrying if someone could pretend to be me and delete all my messages from the server.)
That's great for e-mail, but what about general browsing? Or telnet?
If you are using in-the-clear protocols, then your connection is vulnerable to eavesdropping _anyway_, wireless or no wireless. Use https instead of http, and especially use ssh instead of telnet. Of course this requires the other side to support it (many web sites don't do https) but that is just as you'd expect - a connection that is secure against attackers in the middle must necessarily require cooperation from both the endpoints.
I don't think 'Apple gets the core of their OS developed for them by Open Source community'. That's surely unfair to Apple - they developed their own kernel, which took some BSD code as part of its Unix personality, and released it as free (or semi-free, depending on who you ask) software.
I don't believe IBM makes buckling spring keyboards any more - they spun off the technology as part of Lexmark, who later sold it to Unicomp, who still sell the keyboards but at a fairly high price.
But surprisingly I did find some made-in-China Windows keyboards that have buckling spring and removable keys. (The Model M has both removable keycaps and removable keys revealing the spring underneath - the clone keyboard didn't have the separate keycaps.) Not as good as a real Model M but not bad.
It's not a question of whether the producer and consumer value envionmental safety; they can both value it yet still pollute - because the pollution affects somebody else, and not them directly. Or because the cost of the pollution is spread over everyone, and so the cost to producer and consumer is only a small part of the total cost.
I suppose you could imagine an altruistic producer and an altruistic consumer, who will always take into account other people's interests and not just their own. If actors in the market were like that, we'd have no need for governments at all.
For example I would lose out personally if global warming caused a rise in sea levels. Yet I do not adjust my spending patterns for this, because the amount of CO2 emissions caused by me personally is such a tiny proportion of the whole that my actions would make no difference. Even though I would be willing to pay more for goods to save the environment if everyone else did it, just for me the tiny extra damage to the environment from my own pollution is less important than the money I save.
One point you should never forget is that the licence is not valid if not prompted. Not the GPL nor the EULA.
A contract is not valid if you don't agree to it, that is for certain. And the GPL itself says:
5. You are not required to accept this License, since you have not signed it.
So, don't agree with the GPL? No problem! You are not forced to accept it in order to use a GNU/Linux system or any other GPLed software.
But bear in mind that most countries have copyright laws, and you will be infringing copyright if you distribute copies of the program. You can't do that without the permission of the copyright holder, which means getting a licence. The GNU GPL might be one licence under which the copyright holder is willing to grant permission.
If the G5-based Mac really is 'the world's fastest desktop' then you might want to buy one to use as a Linux box. But I don't really believe Apple's hype on this, not after all the nonsense over the years about Macs being faster based solely on some obscure Photoshop benchmark. (Which may matter to some users, but not to me.)
Slashdot Mirror
Not true - you can put the annotations in your header files and then other developers can use splint just the same. If they prefer not to use it, and would rather take on the burden (of checking that a parameter is non-null) for themselves, then fair enough. Either way you've documented that the pointer must not be null.
If you want to be 'nice' and fail cleanly when given a null pointer then yes you do need extra code - but the standard C library is not written to do that and I don't feel that third party libraries need be either. If passing a null pointer gives a nice, clean segfault that lets you bring up the offending line in the debugger, that's good enough.
(If your function doesn't have an explicit precondition saying the pointer must not be null, then that's different, of course.)
Indeed, which is why checkers like splint use annotations. You annotate your code to say which variables or parameters can be null and which can't be; then the checker only has to look at each function individually and at the boundaries between functions. Just the same as the compiler checks that the parameter type is correct when you call a function expecting an int.
It's no big deal; arguably you should be documenting whether your function allows null for its parameters anyway, and having this documentation in the code itself so it can be automatically checked is better. Have a look at Nice for a similar idea applied to Java.
But you do have to adopt this bondage-and-discipline across the whole program; if some of your code is annotated and some isn't, the checker won't be able to analyse the whole program.
The compiler or static checker is doing the work, so no extra runtime checking is necessary. You are writing the function specification in one central location - 'this function expects its parameter to be not null'.
I agree that one extra clock cycle, or even several, is not a big deal for most applications (even if it happens on every function entry and exit). But it is a bunch of extra code to write, and only works to dodge a problem (calling with a null pointer) once it happens at run time. Whereas with static checking you can be certain there is *no possibility* of calling with a null pointer, and if you accidentally write a call that might be null, you get pointed to the exact source line when building.
It's worth noting that many important C libraries do not follow your rule of always checking arguments - the C standard library in particular does not.
I don't really understand this comment - having a code base where you can be _certain_ there will be no null pointer errors, because the checker has proved it statically, is surely better than code where you hope there are no such errors, and added runtime checks to catch them if they happen, but you don't really know.
(Not that a checker like splint would usually let the programmer eliminate all such errors - but it can certainly cut out a huge chunk of them, and alert you to the things it couldn't check statically, so you can test them at run time.)
No, because the check happens at compile time. Firstly this means you find the error sooner. Secondly there is no run-time overhead. Most importantly if it can statically check that the pointer is not null (or any other property), then you know that this is _always_ true, for _all_ inputs to your program. Whereas assert() will find a bug only if your test suite is comprehensive enough. Finally, if the checker does find a case where a null pointer might be passed, it can tell you which line of source that is ('foo(x) is called on line 100, but x might be null and foo() expects a non-null pointer').
I'm not arguing against assert() or run-time checking in any way, just pointing out that a compile-time check is better in cases where it is possible. But there's a limit to how much compilers or static checkers can figure out, so you have to use run-time checks for more complex things. Normally you'd use a mixture of both.
The null pointer in C is written as 0, and tests as false when used as a Boolean. It might be stored internally as the bit value 1010101, but still in C source code it is 0, and false. So
...
if (pointer)
is perfectly legal, and portable, C.
What splint would really like you to do is to annotate the parameter somebuf to say whether it can be null. IIRC something like:
/*@notnull@*/ somebuf)
int some_func(char *
{
somebuf[0] = 'a';
return OK;
}
Then it will statically check that you never pass a non-null pointer to this function, so the runtime check is no longer needed.
True, of course. However it gets insanely complicated to start worrying about 'is it ever possible that p == 0 and q != 0 and a < b + 3 and x != y...'. The only way is to fix the function so that it has a nice simple set of preconditions, which you can easily check are being followed. And if the preconditions aren't met, technically you are in the right if you segfault or do anything else, but in practice it may be better to log a message and keep the server running.
As far as I can tell from the screenshots they are treating the text console as a big bitmap (using aalib) and then rendering onto that using the standard X fonts.
A more usable alternative would be to provide the console font to X applications - perhaps as the only font available - and then render it using real letters. Pixel positioning might be hard, you might have to round to the nearest eight pixels or something.
The next stage is to make (or adapt) a window manager that knows about the chunky pixels and can draw windows with one-character borders that look reasonable.
If you make a 500x400 text console it's not that different to an ordinary bitmapped display. This is a neat hack, but getting X to run and be usable on an 80x25 screen would be much harder.
Remember that 'text mode Qt' announced on Slashdot a while back? I think it turned out to be a hoax.
So in fact, it's using a different media type, and you just have to hope that your blank CDs are high-quality enough to support this. Who cares, if you want high capacity, incompatible-with-ordinary-CD-players burning you'd just use one of the many DVD-writable formats.
I'd like to see a burner that can write both sides of a CD at once, and a source of cheap double-sided CD blanks, that would be kewl. Because you can fit twice as much on a disc but keep compatibility with older drives (at the expense of some manual flipping).
Remember when Slashdot did a phone interview with Metallica and the editors just transcribed everything including ums and ahs. People said it was deliberate to make Lars sound foolish, but the editors thought it was just honesty. I think it's good editorial practice to edit and chop repetitive spoken mumblings, or at least give the interviewee a chance to rephrase them more concisely.
The main issue with on-board sound is not the sound quality (nowadays, even cheap hardware sounds good enough for games and Oggs) but the possible lack of drivers. Does Linux have free drivers for most onboard sound chipsets?
Why should I care about encrypting the download of mail? It goes in clear text across the network anyway; everyone knows you should not write anything in electronic mail that you wouldn't send on a postcard. That's what PGP is for.
(It is a bit more worrying if someone could pretend to be me and delete all my messages from the server.)
Does this mean that the Declaration of Independence is the first spam?
I don't think 'Apple gets the core of their OS developed for them by Open Source community'. That's surely unfair to Apple - they developed their own kernel, which took some BSD code as part of its Unix personality, and released it as free (or semi-free, depending on who you ask) software.
I don't believe IBM makes buckling spring keyboards any more - they spun off the technology as part of Lexmark, who later sold it to Unicomp, who still sell the keyboards but at a fairly high price.
But surprisingly I did find some made-in-China Windows keyboards that have buckling spring and removable keys. (The Model M has both removable keycaps and removable keys revealing the spring underneath - the clone keyboard didn't have the separate keycaps.) Not as good as a real Model M but not bad.
It's not a question of whether the producer and consumer value envionmental safety; they can both value it yet still pollute - because the pollution affects somebody else, and not them directly. Or because the cost of the pollution is spread over everyone, and so the cost to producer and consumer is only a small part of the total cost.
I suppose you could imagine an altruistic producer and an altruistic consumer, who will always take into account other people's interests and not just their own. If actors in the market were like that, we'd have no need for governments at all.
For example I would lose out personally if global warming caused a rise in sea levels. Yet I do not adjust my spending patterns for this, because the amount of CO2 emissions caused by me personally is such a tiny proportion of the whole that my actions would make no difference. Even though I would be willing to pay more for goods to save the environment if everyone else did it, just for me the tiny extra damage to the environment from my own pollution is less important than the money I save.
So, don't agree with the GPL? No problem! You are not forced to accept it in order to use a GNU/Linux system or any other GPLed software.
But bear in mind that most countries have copyright laws, and you will be infringing copyright if you distribute copies of the program. You can't do that without the permission of the copyright holder, which means getting a licence. The GNU GPL might be one licence under which the copyright holder is willing to grant permission.
Much of eastern Europe chose SECAM, supposedly so it would be difficult to receive Western TV broadcasts.
Analogue TV in France uses SECAM.
If the G5-based Mac really is 'the world's fastest desktop' then you might want to buy one to use as a Linux box. But I don't really believe Apple's hype on this, not after all the nonsense over the years about Macs being faster based solely on some obscure Photoshop benchmark. (Which may matter to some users, but not to me.)
Is there a fix for Microsoft Moron Writing Changelist Has No Idea of Meaningful Usage of Capital Letters?
Oh, wait, Windows is case-insensitive...
But does it run Linux?