Alas, scanf() e fscanf() sono funzioni deprecate per numerosi motivi, dalle performance alla sicurezza. Si deve invece utilizzare sscanf() su un buffer, il che implica l'uso di fgets() o read().

Se fflush(stdin) non funziona sul tuo compilatore preferito, è il momento di cambiare abitudini || compilatore || SO: oppure di utilizzare una standard library all'altezza della situazione.

La fflush() sullo stdin è uno di quei problemi che i vari standard hanno continuato a rimpallarsi fin dai tempi in cui lo stdin stesso proveniva da un lettore di schede perforate, ed era di gran lunga più facile trovare un mainfraime che un PC.

Lo standard, fin dal C'89, è estremamente chiaro: si tratta di una operazione opzionale. I compilatori non hanno l'obbligo di implementare la fflush() sugli stream di input.
Alcuni compilatori (tipicamente quelli nati in area PC DOS) ne forniscono una implementazione, altri preferiscono ignorare del tutto tale opzione.

In realtà, azzerare la coda circolare di tastiera gestita dal BIOS su qualsiasi PC IBM compatibile è un'operazione di una semplicità imbarazzante a basso livello: concettualmente si tratta di rendere uguali i contenuti dei due puntatori first/last char nella BIOS data area, tipicamente copiando arbitrariamente nell'uno il contenuto dell'altro. Tali puntatori al buffer di tastiera sono reperibili all'indirizzo segmentato 0000:041Ah e 0000:041Ch rispettivamente.
Tenendo conto di tutte le possibilità, occorrono nel peggiore dei casi otto o dieci linee di Assembly.

La questione è però molto semplice, anche se sgradevole nella sua brutalità. Dal momento che sia DOS che i brand Unix hanno sempre avuto librerie "non standard" ma standard de facto per la gestione della consolle (vedasi il benemerito conio.h di Borland, copiato a destra ed a manca), a nessuno giustamente fregava e frega alcunché di sistemare la questione modificando in tale senso un qualsiasi standard.

D'altro canto, nel terzo millennio e con l'attuale desolantissimo panorama di omologazione ed appiattimento non si può scrivere uno standard continuando a far finta di non sapere cos'è e com'è fatta una tastiera, assumendo che vi siano ancora due o tre dozzine di architetture diverse e tra loro incompatibili come negli anni '80: oggi la scelta è libera tra wintel, wintel, wintel, wintel, wintel e x86 su MAC.
Quei quattro fregnoni che usano Alpha, PPC e MIPS, incluso il sottoscritto, sono comunque abituati ad arrangiarsi, facendo di necessità virtù. E i clienti AS/400 dell'IBM hanno ben altro a cui pensare.

Ne consegue in sintesi che i vessilliferi free/opensource col vizio congenito di appellarsi sempre ai salvifici standard invece di usare - quando occorre - il cervello{*} finiscono per produrre implementazioni della consolle fallate e incomplete, con tutto quel che ne consegue a livello di fflush() sugli stream di input.


Bottom line: al giorno d'oggi è meglio non usare questa feature se non si hanno granitiche certezze in merito a piattaforma e compilatore: anche se sarebbe necessario averla (e molto banale standardizzarla).

---

{*} Ciò è doppiamente balordo poiché avviene solo quando fa politicamente comodo: egcs e gcc hanno anche loro delle belle liste di comportamenti apertamente contrari agli standard; eppure - come ho già accennato in passato - alcuni estensori del C'99 erano/sono anche sviluppatori di gcc...