"Allan Bruce" <al*****@TAKEAWAYf2s.com> wrote in message
news:c5**********@news.freedom2surf.net...
Thanks for the help guys - I wanted something shorter hand, and found out
some things about sscanf. Now I just need to use:
sscanf(xiBuffer, "FD:%[^:]%s:%[^:]%d:%d", lGUID, &lLastPktFlag,
&lDataLength);
It is shorter, but I feel obliged to point out that it is not safer. If you
set any of the types wrong, either in the format string or in the argument
list, sscanf will fail. If the type sscanf tries to read is smaller than the
variable you pass it, it'll likely fail rather benevolently, but if it's the
other way around you have the possibility of a stack overflow and all the
security problems associated with that. Same goes for overrunning your
string buffers, can be dangerous on the heap, even more so on the stack. The
question you need to ask yourself is whether you can trust yourself (and any
future maintainers of the code) to always ensure type safety and buffer
length safety where sscanf does not enforce it, and (even more importantly)
if you can always trust the input to be well-formed. If the string is coming
from a network/internet source especially, you need something a lot more
secure than sscanf since network input can't be trusted. Local file input is
slightly better, but might still be malformed either purpously or by
filesystem malfunction. This still applies even if some other part of your
program generates the string, because then you are assuming that that part
of the program is 100% correct and can never generate a wrong string, and
that the memory in which the string resides is not corrupted by some
external (or internal) force.
Of course I can't force you to use any kind of construct, but I just hope
you're aware of the dangers that lie with sscanf, and that those few more
lines of code of the examples I and Hendrik provided can easily help avoid
them.
--
Unforgiven