rk9005@cca.ucsf.edu (Roland McGrath) (01/10/88)
Is there some reason that the ANSI standard doesn't include functions vfscanf, vscanf and vsscanf? I don't know actually how useful they would be, but they'd be at least as useful as v*printf. I can't see any reason for not including them. The GNU C library has them because I didn't see why it shouldn't and I needed to write vfscanf to implement fscanf, scanf and sscanf anyway. Don't talk to me about hard to implement; they can't be harder than v*printf. And don't talk to me about prior art; there's a whole hell of a lot of other new functions much harder to deal with than these. Can our local XJ311 representative give any insights? Doug, have your fingers fallen off yet? :-) You sure have a lot of work to do fielding all the responses (and abuse) to the committee's decisions. -- Roland McGrath UUCP: ...!ucbvax!lbl-rtsg.arpa!roland ARPA: roland@lbl-rtsg.arpa
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/11/88)
In article <1112@ucsfcca.ucsf.edu> roland@lbl-rtsg.arpa (Roland McGrath) writes: >Is there some reason that the ANSI standard doesn't include >functions vfscanf, vscanf and vsscanf? Basically, many of us feel that the *scanf() functions are a lossage, and we don't want to introduce any more of them. The main problem is that their operation varies too much, depending on external (input) conditions beyond programmer control, and the interface is not as easy to use for input field validation as it should be. Also, the white-space skipping is problematic; usually, I end up fgets()ing an input line, then sscanf()ing the result. We had to provide specs for the three common *scanf() functions simply because they're widely used and therefore needed standard specifications, not because we think they're great functions. >I don't know actually how useful they would be, but >they'd be at least as useful as v*printf. Not so -- I regularly use v*printf(), for example in error logging functions, but still haven't felt the need for v*scanf().