2009.04.30 19:25 "Re: [Tiff] Packbits worst case encoded length", by Toby Thain

On 30-Apr-09, at 3:12 PM, Albert Cahalan wrote:

On Thu, Apr 30, 2009 at 9:58 AM, Toby Thain <toby@telegraphics.com.au> wrote:

There must be a lot of code out there that assumes good input. And if you're writing a quick hack, not a general purpose library, you might choose to do

Sure. This being the tiff mailing list, it's reasonable to assume that this code is going into something, possibly libtiff itself, that needs to deal with files from random sources.

(Relying on memory protection to save you is not a portable strategy, so again unsuitable for a general purpose library.)

You may imagine that you are so much more capable than the people at Microsoft, Adobe, Apple... and so you NEVER make a mistake that could result in a buffer overflow...

Of course not.

At the very least, you can have an #ifdef to enable memory protection on platforms that can support it. Windows and all the typical UNIX-like systems offer this.

They offer it for processes for 'free', as far as an application developer is concerned.

Whether libtiff should use such a facility directly? Well, the debate is open, I guess.

BTW, since infinite portability is far too costly for the value it provides, you do draw a line somewhere. Crummy platforms are likely to be writing files only, not reading them. (embedded OSes in cameras, scanners, etc.) At most they need to read their own files, which will of course be well-formed.

Going without the memory protection is really really bad.

I don't, and haven't since Mac OS 9. And my Linux and Solaris systems don't do without it either.

I can't possibly emphasize this enough. There is no reason to believe you are some super programmer who never makes a bug.

I do not believe any such thing. When did you stop beating your wife?

--T