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