From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags |
Date: | 2010-12-11 16:55:19 |
Message-ID: | 3785.1292086519@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Sat, Dec 11, 2010 at 17:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> No, it isn't. There's an apparently-useless definition of _S_IRWXU
>> there, but no S_IRWXU.
> Hmm. You're right, of course.
> A search on my windows box finds the text string S_IRWXU in the
> following "*.h" files across the whole filesystem:
> c:\perl\lib\CORE\perl.h
> c:\perl64\lib\CORE\perl.h
> c:\pgsql\src\include\pg_config_os.h
> c:\pgsql\src\include\port\win32.h
> that's it.
OK, now I'm really confused. We have at least two questions:
1. How did all those pre-existing references to S_IRXWU compile?
2. Why didn't the previously hard-wired constants passed to chmod
and umask fail on Windows? The M$ documentation I can find at the
moment suggests that *only* _S_IREAD and _S_IWRITE bits are allowed
in the inputs to those functions, which apparently is untrue or none
of this code would have executed successfully.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-12-11 16:59:18 | Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags |
Previous Message | Magnus Hagander | 2010-12-11 16:44:53 | Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2010-12-11 16:59:18 | Re: [COMMITTERS] pgsql: Use symbolic names not octal constants for file permission flags |
Previous Message | Pavel Stehule | 2010-12-11 16:55:04 | Re: proposal: auxiliary functions for record type |