"I see
where you're coming from - but I also know that writing a TIFF
decoder is pretty straightforward; I wouldn't fancy doing the same
for >
either JPEG or PDF (not sure about PNG, but I get the impression
that > it's pretty simple in nature)."
Noooooo!!!!!
Don't do it. The problem with writing your own decoder is that you may
not have your own set of reference images, so testing it would be
'interesting'. This is the major cause of security issues in software
at the moment. All it takes is one case where you mis-handle input, and
you have introduced a vulnerability into your application.
Unfortunately, you can't work on the basis that image data is not
hostile any more.
That's what application libraries are for. Yes, they are larger that
rolling your own, but they are also more robust.
Yes, that's all well and good when such libraries are available - but my point
was that it's not too difficult to write a TIFF decoder for a system that had
no TIFF support if it were needed. JPEG support I expect is considerably
harder to implement.
As an aside: I've never quite understood these OS image vunerabilities.
Doesn't any modern OS provide sufficient protection such that a process can't
just stomp all over memory at random? Unless the problem is just a Windows
thing...
cheers
J.
--
A. Because it destroys the natural flow of conversation.
Q. What's wrong with top posting ?