Re: allow read into untouched noreserve mappings

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jul 19 10:12, Brian Ford wrote:
> On Tue, 18 Jul 2006, Corinna Vinschen wrote:
> > The answer is in list::try_map.  It tries to find a suitable, unused
> > record which can be reused for another mapping.  The idea here is to
> > accomodate old, non-standard implementations which assume that two
> > consecutive mappings are using consecutive pages in memory.  An example
> > are old autoconf tests.  This was more of a problem when getpagesize()
> > was 4K.  Today it will only be used on 9x due to the alignment bug I'm
> > referring to in mmap64.
> 
> Thanks for the constructive information; it is greatly appreciated.  I
> don't totally understand it yet, but I'll study it.

Some of the code has history.  It's not always nice history and, trust
me, I keep forgetting sometimes why I did something, too.  The older I
get, the more I add comments to the code to keep up with my degenerating
memory.  The last iteration of mmap has lots of comments, though.  It
shouldn't be as intransparent as earlier code.

However, if you have further questions about the code, ask on
cygwin-developers, ok?

> I wasn't sure that minor nits and code rearrangements would be accepted as
> patches, or would just be considered insulting.  If the former, I would be
> happy to submit patches that IMHO make the code more readable as I try to
> understand it myself.  (Things like assignments inside conditionals and
> repeated function calls, even if they are inlined, make it harder for me
> to see what's going on.)

Uh, it depends.

Doing stuff like (not) using assignments within conditionals, or (not)
using inline function calls heavily, or names of variables, are simply a
matter of taste.  For instance, I like assignments in conditionals and
they make the code clearer for me.  I won't take a patch which changes
no functionality, but only changes the source code to satisfy a
different coding taste.

If you can do stuff like getting rid of useless code (prove is
necessary) or if you can simplify code by moving something into a
function or method, or if you can optimize functionality by shuffling
code around, then that's almost always fine.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat