AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
April 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems



Valid HTML 4.01!



Thread

2009.04.26 17:22 "Packbits worst case encoded length", by Simon Berger
2009.04.29 14:28 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.29 18:07 "Re: Packbits worst case encoded length", by Simon Berger
2009.04.29 19:17 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.29 19:43 "Re: Packbits worst case encoded length", by Simon Berger
2009.04.30 07:41 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.04.30 13:58 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.30 19:12 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.04.30 19:25 "Re: Packbits worst case encoded length", by Toby Thain
2009.04.30 19:31 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.04.30 22:30 "Re: Packbits worst case encoded length", by Toby Thain
2009.05.01 06:34 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.05.01 14:21 "Re: Packbits worst case encoded length", by Toby Thain
2009.05.05 16:39 "Re: Packbits worst case encoded length", by Bob Friesenhahn
2009.05.05 18:09 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.05.05 18:32 "Re: Packbits worst case encoded length", by Bob Friesenhahn
2009.05.05 19:13 "Re: Packbits worst case encoded length", by Albert Cahalan
2009.05.05 22:57 "Re: Packbits worst case encoded length", by Graeme Gill
2009.05.05 18:42 "Guard pages - was Re: Packbits worst case encoded length", by Toby Thain
2009.04.30 19:25 "Re: Packbits worst case encoded length", by Simon Berger

2009.04.30 19:31 "Re: Packbits worst case encoded length", by Albert Cahalan

On Thu, Apr 30, 2009 at 3:25 PM, Toby Thain <toby@telegraphics.com.au> wrote:
> 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:

>> 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.

The alternative is that every app is structured
like Google Chrome. It's a really sad result.

>> 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.

Ah, but you do. Regular malloc doesn't put guard pages
around memory allocations. The memory protection is
there in your OS, but it's not getting full use.