tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RFC - add snscanf(3) to stdio
> However, passing in a non-NULL terminated string is a bug.
C strings are not terminated with NULL; they are terminated with NUL.
Well, a zero byte, which is NUL if you're using something
ASCII-compatible, as NetBSD does. (This is one of the reasons I
believe NULL should never be used.)
Passing a non-NUL-terminated string to sscanf is a bug. It would not
be a bug for snscanf, which is much of the point of snscanf. (As for
itohy's point, I think the parallel with sscanf is compelling enough to
justify the name even though it is not, strictly, accurate.)
Another benefit of snscanf, which I haven't seen mentioned yet, is that
it lets you scanf out of a "string" that contains nonterminal NULs,
much as you can fscanf out of a file containing NULs.
Yes, snscanf's lack can be worked around with fropen (or funopen), but
it's a bit ugly. Perhaps people would be happer with an "fopen a block
of memory" call instead?
FILE *fopenmem(void * /*buf*/, int /*len*/, const char * /*mode*/);
or, for the sake of proper const poisoning, perhaps separate calls for
read and write?
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index