Re: [PATCH 2/2] msvcrt: Check pmode in _wsopen_dispatch.

[Piotr Caban]

Hi Lauri,

On 02/04/17 15:38, Lauri Kenttä wrote:
> if (oflags & MSVCRT__O_CREAT)
>    {
> - if(pmode & ~(MSVCRT__S_IREAD | MSVCRT__S_IWRITE))
> -
>  FIXME(": pmode 0x%04x ignored\n", pmode);
> - if (secure && !MSVCRT_CHECK_PMT(!(pmode & ~(MSVCRT__S_IREAD | MSVCRT__S_IWRITE))))
> -
>  return MSVCRT_EINVAL;

According to my testing pmode validation doesn't depend on secure flag 
value (I've tested _wsopen function in msvcr90, I didn't test the 
_wsopen_dispatch function).

Thanks,
Piotr

[PATCH 2/2] msvcrt: Check pmode in _wsopen_dispatch.

[Lauri Kenttä]

On 2017-02-06 15:04, Piotr Caban wrote:
> Hi Lauri,
>
> On 02/04/17 15:38, Lauri Kenttä wrote:
> > if (oflags & MSVCRT__O_CREAT)
> >    {
> > - if(pmode & ~(MSVCRT__S_IREAD | MSVCRT__S_IWRITE))
> > -
> >  FIXME(": pmode 0x%04x ignored\n", pmode);
> > - if (secure && !MSVCRT_CHECK_PMT(!(pmode & ~(MSVCRT__S_IREAD |
> >
> > MSVCRT__S_IWRITE))))
> > -
> >  return MSVCRT_EINVAL;
>
> According to my testing pmode validation doesn't depend on secure flag
> value (I've tested _wsopen function in msvcr90, I didn't test the
> _wsopen_dispatch function).

What do you mean? How do you even test the secure flag with _wsopen?

test__sopen_dispatch calls _wsopen_dispatch with secure=0 and secure=1. 
The former succeeds and the latter fails with EINVAL. Or am I missing 
something obvious?

test__sopen_s shows the same difference between _open (implies secure=0) 
and _sopen_s (implies secure=1), and if you add _sopen there, you can 
see [1] it works like _open.

[1] https://testbot.winehq.org/JobDetails.pl?Key=28357

[PATCH 2/2] msvcrt: Check pmode in _wsopen_dispatch.

[Piotr Caban]

On 02/06/17 16:56, Lauri Kenttä wrote:
> On 2017-02-06 15:04, Piotr Caban wrote:
> > According to my testing pmode validation doesn't depend on secure flag
> > value (I've tested _wsopen function in msvcr90, I didn't test the
> > _wsopen_dispatch function).
>
> What do you mean? How do you even test the secure flag with _wsopen?
>
> test__sopen_dispatch calls _wsopen_dispatch with secure=0 and secure=1.
> The former succeeds and the latter fails with EINVAL. Or am I missing
> something obvious?
>
> test__sopen_s shows the same difference between _open (implies secure=0)
> and _sopen_s (implies secure=1), and if you add _sopen there, you can
> see [1] it works like _open.

Sorry, I've made a mistake while testing it. The patch looks good for me.

Thanks,
Piotr