In my books a good interview rarely if ever follows the "trivial once you've heard the answer, nearly impossible if you haven't" pattern.
What I consider fair game:
1 - Foundation of cs / math / core concepts of candidates preferred language.
Do you know your cs concepts(algo,
data structures, etc), math and common
syntax?
2 - Using the principles from part 1 can you solve straightforward problems?
Choose appropriate algorithms and data
structures for a real-world problem.
Create an efficient algorithm to solve
a tangible problem. Solve a somewhat
challenging math proof with assistance
only on specific formulas. Code
something on the order of FizzBuzz.
3 - You're allowed one "widowmaker". Usually math or algorithm design. A question you don't expect people to be able to answer. See how they deal with it, bonus points if they solve it. If they're on the right track, great. If they give an honest effort, but are way off that's ok. If they get defensive or freeze up, bad.
4 - All questions must be dry-run in interview conditions on several current staff members before use in a real interview.
Questions seem a lot easier when you
know the answer. Test them on staffers
who haven't heard the problems before,
see how well they do.
Avoid trivia... and this is a particularly bad trivia question for an interview. It's obscure, and a definitive no answer would be impossible to prove. I've worked with C for years, and I'd have to answer "not in any of the code I've worked with or written, and not in any situation I can think of".