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

[Måns Rullgård]

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.

-- 
M?ns Rullg?rd
mans at mansr.com