And jogging and bicycling increases your chances to get fatally hit by an automobile, train or plane.
I wondered about that a while back, so I did some investigation into the odds. It turned out that the risk of riding a bike is in the same ballpark as riding in a car when measured on a per-hour basis.
While the risks aren't insignificant, they turned out to be clearly better than the risk of being out of shape and keeling over prematurely from a heart attack or similar problem.
I do avoid some of the things that probably skew the cycling risk numbers higher, such as riding at night, or riding on hilly country roads that lack shoulders.
The food in the buffet is inedible - I wouldn't feed it to hogs.
That's funny... that's exactly what they do.
I saw a segment on some TV show a few years ago that featured a guy who collects the abundant leftover buffet food from Las Vegas hotels, mixes it all together, and then delivers it to hog farms. The animals did seem to be enjoying it quite a bit.
So you've avoided the need for another function by requiring the user to add *two* separate manual fixups to each call of the most common use case. Do you realize how stupid that is?
Of course, the best practice is to forbid the use of strncpy at all in coding standards, which then involves what you said you wanted to avoid: writing your own function.
I'm not the only one to point this out. Here's the discussion of strncpy from Wikipedia:
Despite the well-established need to replace strcat[10] and strcpy[6] with functions that do not allow buffer overflows, no accepted standard has arisen. This is partly due to the mistaken belief by many C programmers that strncat and strncpy have the desired behavior; however, neither function was designed for this (they were intended to manipulate null-padded fixed-size string buffers, a data format less commonly used in modern software), and the behavior and arguments are non-intuitive and often written incorrectly even by expert programmers.
As I said, "sound practice" involves not using that damned function at all. Why do you defend the design of an API that requires you to add an extra line of mitigation code every time you use it?. And why would you accept the performance hit of the extraneous zero padding? It's most likely worse than any of the bounds checking you're so worried about. But an actual "real programmer" would know that.
It the function were named "copyTeminatedStringTo_UNTERMINATED_memoryBuffer()", then you'd have a point.
As it is, this non-string function is named just like all of the actual terminated string functions. So you can save your insults; *I* know about this C library fail (along with scores of other fails), but this problem usually crops up multiple times in any significant project with more than a couple of team members. So much so that it's best to prohibit the use of this function altogether in coding standards, and replace it with a home-grown function that does what people actually expect.
Attempts to "fix" the problem by fudging the buffer and setting characters are just asking for fencepost errors. Not to mention the performance penalty for needlessly zeroing out any empty space after the string.
Yes, you would naturally assume that best practice is to artificially adjust the buffer length, and to execute a separate statement to add a null char *every* time you call one particular library routine, especially if most every other library routine that starts with "str" does set the null terminator unconditionally and doesn't require you to fudge the buffer length.
Or at least you might assume that if you were an imbecile.
That's nice that you have the optional local documentation installed for the C libraries, so you can find out that strncpy() doesn't do what any reasonable person would assume it does without searching the web. (Do you have the POSIX versions installed as well? Sometimes it conflicts with the Linux version, and both can be extremely vague. For those entries, you might have to start searching the web.)
Not to mention that many if not most of the gotchas are in the core language, and man pages won't help you much there.
If C developers aren't searching for C info, they ought to be. People may think that C is simple, but it's full of hidden gotchas.
For example, strncpy() doesn't actually do what any reasonable person would assume it does. Using it in the wrong "obvious" way can result in bugs that won't easily be found during testing. There are hundreds more land mines like that sprinkled throughout the C ecosystem, and they all need to be reviewed repeatedly before one can be considered an experienced developer.
About the only NASCAR related things I saw there, other than the outdated pushrod V8s I already mentioned, were some oil filters. The remaining technologies were either from less reactionary racing organizations that allow car designs that aren't still pinned to production cars from 40 years ago, or they were broad technology categories that happened many decades ago. (Plastic-bodied cars have been on the market for at least six decades now.)
So, getting back to the original post, Ford cars must suck because their oil filters aren't good enough to win NASCAR races.
I'm sure that very little of the R&D that goes into contemporary NACAR racing has any relevance to production vehicles. For example, until very recently, the power train engineering was all about getting performance out of a carburetted pushrod V8 sucking air through artificially small holes. What has that got to do with today's real world? Likewise, safety is based on tightly strapping the driver into the very center of a birdcage frame. Once again, completely irrelevant to highway situations.
The question that interests me is what certainty threshold do we require before we hurt oil and related businesses? Can we make these companies lose billions of dollars based on a probability of 99%? If it turns out we're in the 1% where man-made climate change was wrong, will they get compensated?
On the flip side, if the worst case climate predictions with only 1% probability come to pass (such as most of Florida under water, along with every coastal city on the planet), it will cost humankind quadrillions of dollars in damages and/or remediation attempts. Which end of this spectrum do you think is more worrisome?
No offence intended but there are always tricky edge cases. Reality is more complicated than we realize.
The worst edge cases by far are drunk, senile, texting and/or plain old incompetent drivers. Yet we're developing autonomous vehicles that can mix in with those and perform acceptably.
By comparison, it would be a piece of cake to develop a dedicated transport system, allowing only automated traffic, with a safety level that's an order of magnitude better than current public highways.
What? Greenhouse gasses are fungible. It doesn't matter if the carbon was captured recently or (as with coal) in the distant past.
The only way this logic makes sense is if those trees were planted by humans for the primary purpose of burning.
No, the only thing that matters is what ultimately happens to those trees.
Unless you're harvesting them then carefully warehousing all of the wood indefinitely so that it never rots, the CO2 is going to get released. Whether it's by burning or fungal digestion is irrelevant.
That makes the burning carbon neutral relative to what would have happened anyway.
I think Rockety is awesome when it's done by NASA and not con-artists that cut corners with safety to make a buck.
So you prefer rocketry in the form of a Rube Goldberg contraption that's so unwieldy that safety corners have to be cut in order to make any attempt at a launch.
Slashdot Mirror
How about select the block, then :s/^ /##
I wonder how you're supposed to smelt it in space.
You don't smelt it; it's not in an oxidized state.
It's rarely mentioned how these later waves likely destroyed previous cultures in the Americas, such as the Clovis people
So you're saying that today's Native Americans are carrying a "red guilt"?
And jogging and bicycling increases your chances to get fatally hit by an automobile, train or plane.
I wondered about that a while back, so I did some investigation into the odds. It turned out that the risk of riding a bike is in the same ballpark as riding in a car when measured on a per-hour basis.
While the risks aren't insignificant, they turned out to be clearly better than the risk of being out of shape and keeling over prematurely from a heart attack or similar problem.
I do avoid some of the things that probably skew the cycling risk numbers higher, such as riding at night, or riding on hilly country roads that lack shoulders.
The food in the buffet is inedible - I wouldn't feed it to hogs.
That's funny... that's exactly what they do.
I saw a segment on some TV show a few years ago that featured a guy who collects the abundant leftover buffet food from Las Vegas hotels, mixes it all together, and then delivers it to hog farms. The animals did seem to be enjoying it quite a bit.
How would Trump get his money transferred then?
Operatives exchange briefcases full of cash for envelopes of IOUs at Checkpoint Charlie.
So you've avoided the need for another function by requiring the user to add *two* separate manual fixups to each call of the most common use case. Do you realize how stupid that is?
Of course, the best practice is to forbid the use of strncpy at all in coding standards, which then involves what you said you wanted to avoid: writing your own function.
I'm not the only one to point this out. Here's the discussion of strncpy from Wikipedia:
Despite the well-established need to replace strcat[10] and strcpy[6] with functions that do not allow buffer overflows, no accepted standard has arisen. This is partly due to the mistaken belief by many C programmers that strncat and strncpy have the desired behavior; however, neither function was designed for this (they were intended to manipulate null-padded fixed-size string buffers, a data format less commonly used in modern software), and the behavior and arguments are non-intuitive and often written incorrectly even by expert programmers.
As I said, "sound practice" involves not using that damned function at all. Why do you defend the design of an API that requires you to add an extra line of mitigation code every time you use it?. And why would you accept the performance hit of the extraneous zero padding? It's most likely worse than any of the bounds checking you're so worried about. But an actual "real programmer" would know that.
It the function were named "copyTeminatedStringTo_UNTERMINATED_memoryBuffer()", then you'd have a point.
As it is, this non-string function is named just like all of the actual terminated string functions. So you can save your insults; *I* know about this C library fail (along with scores of other fails), but this problem usually crops up multiple times in any significant project with more than a couple of team members. So much so that it's best to prohibit the use of this function altogether in coding standards, and replace it with a home-grown function that does what people actually expect.
Attempts to "fix" the problem by fudging the buffer and setting characters are just asking for fencepost errors. Not to mention the performance penalty for needlessly zeroing out any empty space after the string.
Yes, you would naturally assume that best practice is to artificially adjust the buffer length, and to execute a separate statement to add a null char *every* time you call one particular library routine, especially if most every other library routine that starts with "str" does set the null terminator unconditionally and doesn't require you to fudge the buffer length.
Or at least you might assume that if you were an imbecile.
That's nice that you have the optional local documentation installed for the C libraries, so you can find out that strncpy() doesn't do what any reasonable person would assume it does without searching the web. (Do you have the POSIX versions installed as well? Sometimes it conflicts with the Linux version, and both can be extremely vague. For those entries, you might have to start searching the web.)
Not to mention that many if not most of the gotchas are in the core language, and man pages won't help you much there.
If C developers aren't searching for C info, they ought to be. People may think that C is simple, but it's full of hidden gotchas.
For example, strncpy() doesn't actually do what any reasonable person would assume it does. Using it in the wrong "obvious" way can result in bugs that won't easily be found during testing. There are hundreds more land mines like that sprinkled throughout the C ecosystem, and they all need to be reviewed repeatedly before one can be considered an experienced developer.
When Trump is in this will get canned,
Not after they tell Trump that Google is discriminating by hiring furrinors in preference to natural born umericans.
About the only NASCAR related things I saw there, other than the outdated pushrod V8s I already mentioned, were some oil filters. The remaining technologies were either from less reactionary racing organizations that allow car designs that aren't still pinned to production cars from 40 years ago, or they were broad technology categories that happened many decades ago. (Plastic-bodied cars have been on the market for at least six decades now.)
So, getting back to the original post, Ford cars must suck because their oil filters aren't good enough to win NASCAR races.
I'm sure that very little of the R&D that goes into contemporary NACAR racing has any relevance to production vehicles. For example, until very recently, the power train engineering was all about getting performance out of a carburetted pushrod V8 sucking air through artificially small holes. What has that got to do with today's real world? Likewise, safety is based on tightly strapping the driver into the very center of a birdcage frame. Once again, completely irrelevant to highway situations.
So to me it sounds like this incident was at least partially due to limitations with the Go programming language and its libraries.
For now, you could use a platform-specific workaround. (Just like you would have to do if you were coding in C). For Linux:
I'm too lazy to look up whether Windows has a similar feature.
Everybody knows Ford sucks. Hard. They haven't won a NASCAR championship in years.
Is there even a single part on a modern NASCAR car that has any relation at all to an actual production vehicle?
I think that argument is kind of like "Law degrees from Yale suck: Their football record was only 3-7 this year."
He's hired primarily free market people as opposed to corporatist
Free marketers don't generally campaign on a platform of protectionist trade policies and direct government intervention in job markets.
NOTHING has changed about the ability of humans to adapt to new circumstances.
Except that in the near future, the robots may more adaptable than the humans.
The question that interests me is what certainty threshold do we require before we hurt oil and related businesses? Can we make these companies lose billions of dollars based on a probability of 99%? If it turns out we're in the 1% where man-made climate change was wrong, will they get compensated?
On the flip side, if the worst case climate predictions with only 1% probability come to pass (such as most of Florida under water, along with every coastal city on the planet), it will cost humankind quadrillions of dollars in damages and/or remediation attempts. Which end of this spectrum do you think is more worrisome?
No offence intended but there are always tricky edge cases. Reality is more complicated than we realize.
The worst edge cases by far are drunk, senile, texting and/or plain old incompetent drivers. Yet we're developing autonomous vehicles that can mix in with those and perform acceptably.
By comparison, it would be a piece of cake to develop a dedicated transport system, allowing only automated traffic, with a safety level that's an order of magnitude better than current public highways.
Derp!
Der took er berces!!
Derp!!!
What? Greenhouse gasses are fungible. It doesn't matter if the carbon was captured recently or (as with coal) in the distant past.
The only way this logic makes sense is if those trees were planted by humans for the primary purpose of burning.
No, the only thing that matters is what ultimately happens to those trees.
Unless you're harvesting them then carefully warehousing all of the wood indefinitely so that it never rots, the CO2 is going to get released. Whether it's by burning or fungal digestion is irrelevant.
That makes the burning carbon neutral relative to what would have happened anyway.
Really ? Kindly explain why it gets cooler on a cloudless night. Heat RADIATES, after all. . .
In general, overnight low temperatures are rising faster than the overall global average temperature.
Why? Because adding CO2 blocks more of that RADIATING heat from escaping to space.
(Of course, the science isn't "settled" on that yet. The laws of thermodynamics are just a theory, after all.)
I think Rockety is awesome when it's done by NASA and not con-artists that cut corners with safety to make a buck.
So you prefer rocketry in the form of a Rube Goldberg contraption that's so unwieldy that safety corners have to be cut in order to make any attempt at a launch.