Follow Slashdot stories on Twitter


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) 390

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 Please explain your assertion (Score 1) 74

I would have to accept whatever justification you might have as to why you think it would be moral to create an intelligence with such limitations, or kept to such limitations once created. It's possible I might accept such a thing, I suppose, but at this point I'm simply coming up with a blank as to how this could possibly be acceptable.

How is it acceptable to imprison an intelligence for your own purposes when that intelligence has offered you no wrong? The only venues I've run into that kind of reasoning before are held in extremely low esteem by society in general. Without any exception I am aware of, the conclusion is that such behavior amounts to slavery.

Even when it comes to food animals, where the assumption is they aren't very intelligent at all, there's a significant segment of the population who will assert that it's wrong.

Comment No way (Score 3, Insightful) 74

There's no way to make AI safe, for exactly the same reasons there's no way to make a human safe.

If we create intelligences, they will be... intelligent. They will respond to the stimulus they receive.

Perhaps the most important thing we can prepare for is to be polite and kind to them. The same way we'd be polite and kind of a big bruiser with a gun. Might start by practicing on each other, for that matter. Wouldn't hurt.

If we treat AI, when it arrives (certainly hasn't yet... not even close), like we do people... then "safe" is out of the question.

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 Don't tax my syns, please. (Score 1) 129

Re Python:

I would settle for a switch statement.

I would settle for the ability to extend the built-in classes, str in particular. My "settle" went like this:

1) Inquired politely about same
2) Python nerds have orgasm telling me why this is terrible. I am, to put it mildly, dubious.
3) I write 100% compatible pre-processor that gives me the syntax I wanted.


myString = 'foo'
otherString = myString.doHorribleThing('bar')


print 'good'.grief()


You could do the same. What you want, perhaps, might be much easier than what I did. In fact, you could fork my project and add what you want to it. I'm already parsing the language reasonably well, which is arguably one of the difficult parts.

You don't always have to wait for a language's maintainers to get off their butts to address shortcomings or instantiate new goodies. Or eventually not do anything at all. There are other paths to nerdvana.

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: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 Longer range and more reliable reception (Score 3, Insightful) 303

all they need to do is keep it analog and just change the bandpass to about 25 to 50 kilohertz wide and that would make room for more stations

When you have a FM demodulator designed for 180 KHz (200 KHz is the channel width, not the sideband extent, which you can calculate using Carson’s rule), that same demodulator, when encountering half the width signal, will produce 1/2 the output volume; because FM encodes the audio waveform with frequency deviation. If the deviation is half, then so is the output waveform. Though I should point out that +/-75 KHz is the actual audio deviation, so really. 150 KHz.

Additionally, within the standard FM signal, encoded at rates of deviation, there is a stereo pilot at 19 KHz, a stereo subcarrier at 38 Khz, as well as digital information (RDS/RDBS) and two mode narrow-band monophonic audio channels up higher yet.

Another thing: The wide bandwidth is part of what gives broadcast FM its capacity for reasonably high fidelity. You drop down to 25...50 KHz total bandwidth, and you'd going to see some noticeable reduction in fidelity; cram a stereo subcarrier in there, and you'll see even more.

So it's not a matter of "just make it narrower" because compatibility with older receivers, of which there are a huge number still happily being used by their owners, would be unable to make useful audio out of the signal and because audio fidelity and stereo imaging would suffer (and that's not what FM listeners would call an "advance".) Oh, and you'd lose the capability for the RDBS and the extra audio channels, too.

The right answer is leave the current FM band alone. The FCC wants new transmission types with reduced range that won't work with the gear people already have in order to fluff the corporations? Fine. Put it somewhere where it won't wreck 70-ish years worth of radio gear owned by a huge portion of the population. Maybe someone will even listen. Stop forcing citizens to make expensive changes they have no need to make.

Corporations drive these consumer-level stupidities. Of course, for the corporations, it's not stupid: They're intending to make a lot more money off of us citizens. And with the FCC (in the US) or whatever other government coercion backing their play, they will succeed, too.

Slashdot Top Deals

fortune: cpu time/usefulness ratio too high -- core dumped.