[Geany] do not open oversize files

[Dimitar Zhekov]

On Wed, 5 Jan 2011 11:08:18 +1100
Lex Trotman <elextr at gmail.com> wrote:

> And on modern kernels virtual memory can be overcommitted
> significantly so it may not work

I haven't said that a successful alloc guarantees everything will be
fine. :) But with the kernel defaults, you'll at least catch the most
obvious cases.

> is expensive since the page tables have to be constructed even if
> the memory is not used.

CPU cost: that's only once per file, memory cost: < 1%

> Also this could cause fragmentation of the virtual address space that
> may limit how many times it will work.

Yes, or some other problems. It's a hack, and should only be used if
we can't agree on anything better. Personally I'm for a preference.

---

On Tue, 4 Jan 2011 22:05:52 +0100
Krzysztof Żelechowski <giecrilj at stegny.2a.pl> wrote:

> > > I do not know where you got it from, but the last OS I know that
> > > behaved like that was MacOS 7. [cut]
> > 
> > Like what?..
> 
> Like necessarily allocating a contiguous block of physical memory.

What a strange idea... Unless your CPU lacks MMU, of course.

> GNU malloc uses mmap so it is all virtual.

mmap for large blocks and heap for small blocks IIRC, and naturally, the
heap itself is mmap-ed.

> > If by "01 << 040" you mean 4GB, how much real and virtual memory do
> > you have?
> > 
> > 
> 
> I have 1 GB of physical memory.  (01 << 040) is the first integer that does not fit into unsigned int.

So then, using more than 4GB _will_ be a problem on your system, QED.
I pointed out it's a rough check.

But if your malloc() fails on 4GB, and not below that, you either have
an unusually large swap file, or your kernel is set to always
overcommit. With the defaults, the check works much better.

-- 
E-gards: Jimmy