Please create an account to participate in the Slashdot moderation system


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×

Comment Re:I get this... (Score 1, Informative) 376

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.

Comment It is a problem I've talked about for a long time (Score 0) 130

And one that often gets me downvoted since Mac users don't like to hear it: Apple is a fashion company. That's why they've been able to do what they do. In fashion, a higher price can be a GOOD thing not a bad thing, whereas consumer electronics are one of the most notoriously price sensitive markets out there.

However the downside is as you say: What is fashionable changes and it is really hard to stay on top of it forever.

Comment Re:Search engine? (Score 1) 285

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.

Comment Re:Search engine? (Score 1) 285

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.

Comment Re:Search engine? (Score 1) 285

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.

Comment Re:Search engine? (Score 1) 285

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.

Comment Re:Search engine? (Score 2) 285

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.

Comment Re:No, it wasn't (Score 1) 104

Well two things there BTChead:

1) Some currencies DO move large amounts and that is NOT considered successful. When the pound was experiencing instability, that was a big cause for concern. It was not considered a "success" as people seem to think for BTC.

2) It was 8%, not 30%. Bit of a difference there.

Like I said before: You can't have it both ways. If you want it to be a good currency, then stability is what you want. If you are happy with rapid fluctuations, then it is a speculative betting opportunity.

Comment Re:Search engine? (Score 2) 285

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.

Comment No, it wasn't (Score 3, Interesting) 104

Not just because it doesn't work as a currency, but because for currencies big swings in valuation, up or down, are no "good performance". Ideally a currency would be completely stable. What $1 buys now would be what $1 buys tomorrow, and what it buys in a thousand years. Of course in reality none of them are totally stable, but the good ones are pretty stable. They move a very small amount, and do so very gradually. They function as a good store of wealth for that reason, and more importantly make for a useful medium of exchange. Since their value is pretty constant, people have a good feeling for how much they are "worth" and can mentally price things.

Bitcoin did well as a speculative bet. If you want to play financial speculation, Bitcoin is a good target as it moves like a very thinly traded stock. That means it can swing bit and make you a lot of money. Also means it can swing big the other way and lose you a lot. So like any sort of speculation, you need to know what you are getting in to and understand the risks.

You BTC promoters can't have it both ways: If Bitcoin is a good currency then it needs to be stable. If Bitcoin is a good investment, then it isn't a currency.

Comment Re:Truth of the story. (Score 1) 432

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.

Comment Re:Truth of the story. (Score 1) 432

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.

Comment Re:Was the Go prog lang at fault? Would Rust help? (Score 1) 119

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:

func Uptime() (int64, err) {
    var si syscall.Sysinfo_t
    err = syscall.Sysinfo(&si)
    return si.Uptime, err

I'm too lazy to look up whether Windows has a similar feature.

Slashdot Top Deals

The Tao is like a glob pattern: used but never used up. It is like the extern void: filled with infinite possibilities.