[FFmpeg-cvslog] r29509 - trunk/libswscale/swscale.c

[Reimar Döffinger]

On Fri, Aug 14, 2009 at 09:40:30AM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> 
> > On Fri, Aug 14, 2009 at 02:01:12AM +0100, M?ns Rullg?rd wrote:
> >> Ramiro Polla <ramiro.polla at gmail.com> writes:
> >> 
> >> > On Thu, Aug 13, 2009 at 4:24 PM, Reimar
> >> > D?ffinger<Reimar.Doeffinger at gmx.de> wrote:
> >> >> On Thu, Aug 13, 2009 at 08:29:54PM +0200, ramiro wrote:
> >> >>> +#ifdef MAP_ANONYMOUS
> >> >>> + ? ? ? ? ? ?mprotect(c->lumMmx2FilterCode, MAX_MMX2_FILTER_CODE_SIZE, PROT_EXEC | PROT_READ);
> >> >>> + ? ? ? ? ? ?mprotect(c->chrMmx2FilterCode, MAX_MMX2_FILTER_CODE_SIZE, PROT_EXEC | PROT_READ);
> >> >>
> >> >> Both for mmap and mprotect: Why PROT_READ though? I don't think
> >> >> EXEC without read is possible on most architectures, but still we
> >> >> do not need read access in any case I think...
> >> >
> >> > Mans, or anyone else that knows an extensive amount of platforms, can
> >> > you comment on this?
> >> 
> >> On ARM read permission is required to execute.  I see no harm in
> >> always requesting both.
> >
> > mmap/mprotect can and will automatically "upgrade" the permissions.
> 
> On some systems perhaps, but these are arguably not strictly
> conforming to spec.  This is from the spec page for mmap():
> 
>   If an implementation cannot support the combination of access types
>   specified by prot, the call to mmap() shall fail.
> 
> It says the same thing about mprotect().  It is of course unreasonable
> to expect the caller to know the precise combinations possible on
> every bit of hardware, so adjusting to something it can do is a good
> idea.  It's probably not compliant to the letter though.

Uh, you forgot to quote the following sentence, which clarifies what
the thing you quoted meant:
> An implementation may permit accesses other than those specified by
> prot;

The case where it "shall fail" is e.g. a system where there is no memory
that would allow both executing and reading the data in principle,
then PROT_READ | PROT_EXEC mmap shall fail (instead of not giving one of
the requested permissions).
Which also give you the reason why in theory using PROT_EXEC is better than
PROT_EXEC | PROT_READ, because on some theoretical systems the later
would have to fail to be POSIX compliant, whereas the former can be made
to work wherever the later would work without breaking POSIX compliance.