X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com X-Authenticated: #27081556 X-Provags-ID: V01U2FsdGVkX19n8KR9beBnTDhmCfRHMDdnsMwxKOeW7/C9mUC4Pi VBC5MsQUQITn2r Message-ID: <51811D36.2060104@gmx.de> Date: Wed, 01 May 2013 15:48:38 +0200 From: Juan Manuel Guerrero User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: djgpp-workers AT delorie DOT com Subject: Re: The encoding of S_IFREG References: <5180E8C7 DOT 4010609 AT gmx DOT de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Reply-To: djgpp-workers AT delorie DOT com Am 01.05.2013 14:24, schrieb Rugxulo: > On Wed, May 1, 2013 at 5:04 AM, Juan Manuel Guerrero > wrote: > > > > While I was trying to port patch 2.7.1, besides a lot of issues, I > > encountered > > the following problem: DJGPP file mode encodes S_IFREG with 0x0000. > > Unfortunately the patch code checks if the file mode is valid at all by > > checking against zero. > > > > We could replace 0x0000 by 0x6000. I am aware that this may introduce > > backward > > incompatibilities, but the benefits when a porting job is done are evident. > > At risk of stating the obvious, just #undef it locally and (re) > #define it with non-zero value. This is what I do. In the config.h file created by config.bat, a DJGPP specific section is added that redefines S_IFREG and S_ISREG so that they work with a value different from zero. > While it's possible that something would break if you changed this > globally, I'd be mighty surprised. AFAIK, the whole point of such > named constants is to avoid relying on hidden values. This approach does not work with git style patches. They may look like this: diff --git a/symlink b/symlink new file mode 120000 index 0000000..12a8d8a --- /dev/null +++ b/symlink @@ -0,0 +1 @@ +target1 \ No newline at end of file As can be seen the file mode is coded in the patch. The octal 120000 encodes S_IFLNK on linux but if this number is assigned to djgpp's st_mode it makes no sense. It certainly does not match djgpp's value of S_IFLNK and the port may work erratic when evaluated with S_ISLNK . Of course, I have written a macro that maps the linux S_IFMT bits to the corresponding djgpp ones leaving the rest unchanged. Regards, Juan M. Guerrero