From: manubee <ma...@wa...> - 2003-10-13 18:42:56
|
Paul Eggert wrote: [...] >Even if the fix is correct, I'd rather substitute a 'rename' >implementation that works as 'patch' expects, using a wrapper, rather >than modify the mainline source. See the pc/djgpp subdirectory for >how this is done for DJGPP. A similar directory could be set up for >mingw, if a mingw expert has the time and inclination to maintain one. I'm far from being an expert unfortunately, though is there a CVS repository for GNU patch. I tried the one from savannah: http://savannah.gnu.org/projects/diffutils/ The CVS seems empty. Manu. |
From: manubee <ma...@wa...> - 2003-10-13 22:13:15
|
Paul Eggert wrote: >"manubee" writes: > >> The CVS seems empty. > >There is no CVS for GNU patch, yet. Where can I get the sources of patch 2.5.9? The latest from GNU ftp is ftp://ftp.gnu.org/gnu/patch/patch-2.5.4.tar.gz Thanks in advance. Manu. |
From: Paul E. <eggert@CS.UCLA.EDU> - 2003-10-14 03:41:28
|
"manubee" <ma...@wa...> writes: > Where can I get the sources of patch 2.5.9? I haven't a clue. I haven't been able to upload a new version to alpha.gnu.org for months. This is starting to be of some concern to me, but unfortunately the people who control alpha.gnu.org haven't been responding to my email. |
From: Eli Z. <el...@el...> - 2003-10-14 05:46:02
|
> From: Paul Eggert <eggert@CS.UCLA.EDU> > Date: 13 Oct 2003 20:40:52 -0700 > > > Where can I get the sources of patch 2.5.9? > > I haven't a clue. I haven't been able to upload a new version to > alpha.gnu.org for months. This is starting to be of some concern to > me, but unfortunately the people who control alpha.gnu.org haven't > been responding to my email. Well, Google comes up with a few places where one can get Patch 2.5.9. If you, Paul, didn't upload it to any GNU site, one wonders how did the various GNU/Linux distributions got a hold of it? |
From: Stepan K. <ka...@uc...> - 2003-10-14 07:24:58
|
Hi, On Tue, Oct 14, 2003 at 07:46:12AM +0200, Eli Zaretskii wrote: > Well, Google comes up with a few places where one can get Patch 2.5.9. > If you, Paul, didn't upload it to any GNU site, one wonders how did > the various GNU/Linux distributions got a hold of it? I can save Paul a few kestrokes: it used to be on alpha.gnu.org . After a hack has been discovered, all contents of ftp.gnu.org and alpha.gnu.org was to be approved. Paul is complaining that a problem in communication prevented patch 2.5.9 from getting back to the new alpha.gnu.org . So people can fairly safely grab the sources from a Linux distribution or another place. Stepan |
From: Stephan T. L. <st...@ca...> - 2003-10-22 07:57:51
|
I have fixed the "assertion failed" problem which occurs when patch = 2.5.9 is compiled for MinGW and used on certain files and patches without = --binary. My fix is simple: when HAVE_SETMODE_DOS is enabled, binary mode is = *forced*. The --binary switch is silently ignored. I would in fact suggest that patch should work with everything in binary = at all times on all systems. Text mode is an abomination from the depths = of 1970s evil and we shouldn't have to put up with it anymore. This would require slightly more extensive changes than I'm comfortable with = making, so I haven't done it. I tested this using the plain patch 2.5.9 sources and my original patch = to patch: C:\Temp\test\patch-2.5.9>patchOLD -p1 < patch-2.5.9-mingw.patch patching file dirname.h Assertion failed: hunk, file patch.c, line 340 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. C:\Temp\test\patch-2.5.9>patchNEW -p1 < patch-2.5.9-mingw.patch patching file dirname.h patching file util.c C:\Temp\test\patch-2.5.9> I now believe that my hacked patch 2.5.9 works as well on MinGW as it = does on GNU/Linux. I can appreciate that my brute force fixes aren't elegant = and aren't suitable for the mainline; nevertheless, they get it working, and that makes me happy. I do look forward to a patch 2.5.10 or 2.6 that fixes some or all of = these problems in a better way, so that I don't need to maintain my own micro-fork. (Manu's fix for the mkdir thing sounds better than my = direct hacking of the source, but since I don't fully understand what's going = on, I'll stick with what I've got until his fix makes it into the official sources.) My new patch for patch 2.5.9 is: diff -aur patch-2.5.9/common.h patch-2.5.9-mingw/common.h --- patch-2.5.9/common.h 2003-05-18 23:57:36.000000000 -0700 +++ patch-2.5.9-mingw/common.h 2003-10-21 23:42:06.000000000 -0700 @@ -283,7 +283,7 @@ #endif =20 #if HAVE_SETMODE_DOS - XTERN int binary_transput; /* O_BINARY if binary i/o is desired */ +# define binary_transput O_BINARY #else # define binary_transput 0 #endif diff -aur patch-2.5.9/dirname.h patch-2.5.9-mingw/dirname.h --- patch-2.5.9/dirname.h 2001-05-12 08:46:36.000000000 -0700 +++ patch-2.5.9-mingw/dirname.h 2003-10-12 16:34:00.000000000 -0700 @@ -30,7 +30,11 @@ # endif =20 # ifndef ISSLASH -# define ISSLASH(C) ((C) =3D=3D DIRECTORY_SEPARATOR) +# ifdef __MINGW32__ +# define ISSLASH(C) ((C) =3D=3D '/' || (C) =3D=3D '\\') +# else +# define ISSLASH(C) ((C) =3D=3D DIRECTORY_SEPARATOR) +# endif # endif =20 # ifndef FILESYSTEM_PREFIX_LEN diff -aur patch-2.5.9/patch.c patch-2.5.9-mingw/patch.c --- patch-2.5.9/patch.c 2003-05-20 06:55:03.000000000 -0700 +++ patch-2.5.9-mingw/patch.c 2003-10-21 23:43:02.000000000 -0700 @@ -752,9 +752,6 @@ verbosity =3D VERBOSE; break; case CHAR_MAX + 3: -#if HAVE_SETMODE_DOS - binary_transput =3D O_BINARY; -#endif break; case CHAR_MAX + 4: usage (stdout, 0); diff -aur patch-2.5.9/util.c patch-2.5.9-mingw/util.c --- patch-2.5.9/util.c 2003-05-20 07:04:53.000000000 -0700 +++ patch-2.5.9-mingw/util.c 2003-10-12 16:34:00.000000000 -0700 @@ -153,7 +153,11 @@ goto rename_succeeded; } =20 - if (errno =3D=3D EXDEV) +#ifdef __MINGW32__ + if (errno =3D=3D EXDEV || errno =3D=3D EEXIST) +#else + if (errno =3D=3D EXDEV) +#endif { if (! backup) { @@ -879,10 +883,14 @@ for (f =3D filename; f <=3D flim; f++) if (!*f) { - mkdir (filename, - S_IRUSR|S_IWUSR|S_IXUSR - |S_IRGRP|S_IWGRP|S_IXGRP - |S_IROTH|S_IWOTH|S_IXOTH); +#ifdef __MINGW32__ + mkdir (filename); +#else + mkdir (filename, + S_IRUSR|S_IWUSR|S_IXUSR + |S_IRGRP|S_IWGRP|S_IXGRP + |S_IROTH|S_IWOTH|S_IXOTH); +#endif *f =3D '/'; } } Stephan T. Lavavej http://nuwen.net |
From: Eli Z. <el...@el...> - 2003-10-22 17:50:31
|
[I'm not the maintainer of GNU Patch, but I did work on its port to DJGPP, which is a free environment for developing programs for MS-DOS and MS-Windows. That is why I allow myself a few comments on your suggested changes. Please wait for Paul to give you the definitive response.] > From: "Stephan T. Lavavej" <st...@ca...> > Date: Wed, 22 Oct 2003 00:14:01 -0700 > > I have fixed the "assertion failed" problem which occurs when patch 2.5.9 is > compiled for MinGW and used on certain files and patches without --binary. > My fix is simple: when HAVE_SETMODE_DOS is enabled, binary mode is *forced*. > The --binary switch is silently ignored. Can you tell why does the assertion fail with the original code? The DJGPP port doesn't have this problem, although the last version I worked with was Patch 2.5.4. However, I don't think there were any significant changes in this area since that version. > I would in fact suggest that patch should work with everything in binary at > all times on all systems. Text mode is an abomination from the depths of > 1970s evil and we shouldn't have to put up with it anymore. I disagree. To be a good Windows citizen, the ported Patch must be able to work on files with both Unix- and DOS-style end-of-line (EOL) format alike. Imagine, for example, that you have a source file that came from a Unix .tar.gz archive, and which therefore has the Unix single-newline EOL format, and a patch file that was created by a Windows mail client from a mail message, and thus will most probably have a DOS-style CR-LF EOL format. If you use --binary, the patch will fail to apply (because there's an extra CR character at the end of each line of context in the hunks). Moreover, it will fail in a mysterious way, since the user cannot easily understand what is wrong here. Dealing with this problem is a nuisance, and a gratuitous nuisance at that. If Patch works in text mode, this kind of problem goes away. There are many situations like that, that's why (IMHO) --binary cannot be turned on by default on DOS/Windows platforms. Programmers who work on those platforms expect their development tool to work well with both styles of EOL format. For example, the compiler is expected to compile both Unix- and DOS-style source files, the editor is expected to be able to edit both types of files (a test that the infamous Notepad fails miserably), Make is expected to process Makefiles written either on Unix or on Windows, Diff is expected to be able to compare a Unix-style file with a DOS-style file, etc. Why should Patch be any different? > C:\Temp\test\patch-2.5.9>patchOLD -p1 < patch-2.5.9-mingw.patch > patching file dirname.h > Assertion failed: hunk, file patch.c, line 340 > > This application has requested the Runtime to terminate it in an unusual > way. What exactly does this last sentence mean? Presumably, Windows is trying to tell us something important about the way Patch terminated, but what is it? Is it just the fact that Patch exits with a non-zero exit code, or is there something else? > I do look forward to a patch 2.5.10 or 2.6 that fixes some or all of these > problems in a better way I cannot speak for Paul, who maintains Patch, but I doubt if this will happen unless you tell the details about why the assertion fails. How can we expect Paul, or anyone else, to fix the code, if the problem is not understood? > # ifndef ISSLASH > -# define ISSLASH(C) ((C) == DIRECTORY_SEPARATOR) > +# ifdef __MINGW32__ > +# define ISSLASH(C) ((C) == '/' || (C) == '\\') > +# else > +# define ISSLASH(C) ((C) == DIRECTORY_SEPARATOR) > +# endif This should IMHO be handled differently: some MinGW-specific header should define ISSLASH as suitable for Windows. The whole point of "#ifndef ISSLASH" in this snippet is to move ugly system-dependent stuff out of the mainline code, so that the mainline code remains clean and yet portable. > -#if HAVE_SETMODE_DOS > - binary_transput = O_BINARY; > -#endif Note, btw, that this change affects _all_ platforms that have HAVE_SETMODE_DOS defined, not only MinGW. I, for one, would object to this change to affect the DJGPP port, which also defines HAVE_SETMODE_DOS. > +#ifdef __MINGW32__ > + if (errno == EXDEV || errno == EEXIST) > +#else > + if (errno == EXDEV) > +#endif I think Paul already responded to this change: it sounds like the library function `rename' fails when the target file already exists. The proper solution should be to write a Posix-compatible version of `rename', which doesn't fail in that case, and use it instead of the one provided by the Windows/MinGW runtime. (A simple strategy to implement such a version of `rename' is to call the original `rename', and if it fails with EEXIST or EACCES, remove the target file and try again.) > +#ifdef __MINGW32__ > + mkdir (filename); > +#else > + mkdir (filename, > + S_IRUSR|S_IWUSR|S_IXUSR > + |S_IRGRP|S_IWGRP|S_IXGRP > + |S_IROTH|S_IWOTH|S_IXOTH); > +#endif Same here: I suggest to write a Posix-comlpiant version of `mkdir', which accepts (and largely ignores) the additional argument, and use that instead of the Windows version. HTH |
From: Paul E. <eggert@CS.UCLA.EDU> - 2003-10-22 16:59:02
|
"Eli Zaretskii" <el...@el...> writes: > [I'm not the maintainer of GNU Patch, but I did work on its port to > DJGPP, which is a free environment for developing programs for MS-DOS > and MS-Windows. That is why I allow myself a few comments on your > suggested changes. Please wait for Paul to give you the definitive > response.] I pretty much agree with everything you wrote. I don't want to munge the mainline code; the MinGW stuff should be in the 'pc' subdirectory. As long as the changes are in the subdirectory I'm pretty much willing to trust the judgment of whoever does the MinGW port. My own feeling is that the mainline code shouldn't have to worry about CRLF issues; it should just use '\n'. There are a few concessions, to handling files improperly imported from the DOS world, but I'd rather not add more cruft like that. In general, people should import files correctly rather than modify all their tools to deal with bad files. |
From: Eli Z. <el...@el...> - 2003-10-22 18:14:40
|
> From: Paul Eggert <eggert@CS.UCLA.EDU> > Date: 22 Oct 2003 09:19:57 -0700 > > My own feeling is that the mainline code shouldn't have to worry about > CRLF issues; it should just use '\n'. Text-mode I/O, which is the default in the DJGPP port, achieves precisely that. > In general, people should import files > correctly rather than modify all their tools to deal with bad files. I agree with the goal, but my experience has taught me that in practice it is very hard to achieve that. So if we have an easy way to deal with that nuisance without adding too much cruft to the mainline code, our users will thank us. |
From: Earnie B. <ea...@us...> - 2003-10-24 03:08:44
|
Eli Zaretskii wrote: >>From: Paul Eggert <eggert@CS.UCLA.EDU> >>Date: 22 Oct 2003 09:19:57 -0700 >> >>My own feeling is that the mainline code shouldn't have to worry about >>CRLF issues; it should just use '\n'. > > > Text-mode I/O, which is the default in the DJGPP port, achieves > precisely that. > I agree in heart but enjoy the freedom of not having to defend the position. > >>In general, people should import files >>correctly rather than modify all their tools to deal with bad files. > > > I agree with the goal, but my experience has taught me that in > practice it is very hard to achieve that. So if we have an easy way > to deal with that nuisance without adding too much cruft to the > mainline code, our users will thank us. > I think that could be achieved. The main problems reside with a \n file with a \r\n patchfile and vice versa. So on a DOSISH_FILE_SYSTEM check for \r at the end of the string and replace it with \0 for both reads. If --binary is given then the output file is also opened in binary mode. Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Benjamin R. <Ben...@ep...> - 2003-10-23 12:04:11
|
Hi Eli, "Eli Zaretskii" <el...@el...> writes: > I disagree. To be a good Windows citizen, the ported Patch must be > able to work on files with both Unix- and DOS-style end-of-line > (EOL) format alike. The test case that was presented on mingw-users for that runtime problem did have CRLF at most lines and LF at one. It wasn't consistent about it. Which also just happens in real life, I have to add. (Most of you probably know the rest of what I am going to say, but I'd like to state my train of thoughts here anyway for completeness.) The C runtime library of course isn't required to support "both Unix- and DOS-style end-of-line" as long as you just argue from the C specs. You are either on Unix or on DOS/Windows, and the runtime only needs to handle the native convention. Actually it would be hard for the C runtime to know all other generally interesting conventions that may be out there. You can define more requirements for a specific runtime implementation, but you can not expect other compilers' runtime to conform to your additional requirements. So, to be portable, every application has to define it's own technique to do this. Actually in most cases using binary input and simple wrappers for fgetc(), fgets() and possibly fread() can do it, I think. Then there is the problem of tools that need to support text and binary on the same channel (like e.g. cat), because for some use cases binary files are processed and at other times text files. For these tools you need to add (and use) command line switches to the application. benny |
From: Eli Z. <el...@el...> - 2003-10-25 13:57:03
|
> From: Benjamin Riefenstahl <Ben...@ep...> > Date: Thu, 23 Oct 2003 12:52:15 +0200 > > The test case that was presented on mingw-users for that runtime > problem did have CRLF at most lines and LF at one. Text-mode I/O ought to have handled this. It does in the DJGPP port. Perhaps the problem is that fseek/ftell that MinGW uses don't work well in text mode. The DJGPP library has special code to handle this, so this problem doesn't happen there. > You are either on Unix or on DOS/Windows, and the runtime only needs > to handle the native convention. I don't think I understand this. ``Normal'' C code is written with the Unix EOL format in mind, so it assumes a single \n at the end of each line. Text-mode I/O was invented to make this happen automagically on DOS/Windows platforms. Unfortunately, most implementations of text I/O didn't go far enough and didn't make sure that fseek/ftell work well in text mode. So programs that rely on the fact that ftell's results are consistent with counts of characters returned by, say, getc, will generally break on Windows. The solution is to fix the library function or to use binary I/O (and remove the \r characters manually) or to replace fseek/ftell with equivalent code. |
From: Benjamin R. <Ben...@ep...> - 2003-10-25 04:32:29
|
Hi Eli, >> From: Benjamin Riefenstahl <Ben...@ep...> >> You are either on Unix or on DOS/Windows, and the runtime only >> needs to handle the native convention. "Eli Zaretskii" <el...@el...> writes: > I don't think I understand this. ``Normal'' C code is written with > the Unix EOL format in mind, so it assumes a single \n at the end of > each line. Text-mode I/O was invented to make this happen > automagically on DOS/Windows platforms. I agree, but I'd phrase it slighly different. The definition is made in the C specs without reference to specific platforms. C code sees line ends as \n, where \n is a single character whose actual value is defined by the compiler vendor. The C runtime translates that to and from an external format as required on the platform. In practice on Unix the translation is trivial, \n == LF, \r == CR and this is also the platform convention. On Mac OS Classic CR was the external convention, and there are two types of implmentations, either \r and \n are switched during I/O or they are just re-defined as \n == CR and \r == LF (nasty but legal). On Windows the external representation is CRLF, so this is translated to and from \n on I/O. There are even other conventions, or so I have heard. Each platform only cares for it's particular native format and Unix format is not special on the other platforms. In the age of Internet and cross-platform exchange of files of all kinds, we may not like those limited definitions, but that is how the C language is defined (modulo my own misunderstandings, of course). The fact that reading Unix text files on Windows usually works with C programs is pure coincidence, it is not intentional in the sanse that it is fully supported by VC++ or Borland. If it doesn't work for some operation, you're on your own. > The solution is to fix the library function You usually don't do that with commercial compilers because of licenses and/or practical problems such as hassles with upgrading and the need to re-patch. You could try to persuade the vendor to change it's implementation, but that would go into the category "new feature", not into "bugs." So in the end this is not really an option for portable C code. > or to use binary I/O (and remove the \r characters manually) or to > replace fseek/ftell with equivalent code. As I said. benny |
From: Eli Z. <el...@el...> - 2003-10-24 22:19:45
|
> From: Benjamin Riefenstahl <Ben...@ep...> > Date: Fri, 24 Oct 2003 17:55:19 +0200 > > > The solution is to fix the library function > > You usually don't do that with commercial compilers because of > licenses and/or practical problems such as hassles with upgrading and > the need to re-patch. I didn't mean to patch the library, I meant to write a substitute for it. For example, you write a function called fixed_mkdir that does the right thing with the second argument, then say #define mkdir fixed_mkdir in some header included by all the sources except the one that defines fixed_mkdir's code. |
From: Paul E. <eggert@CS.UCLA.EDU> - 2003-10-24 23:04:13
|
"Eli Zaretskii" <el...@el...> writes: > #define mkdir fixed_mkdir > > in some header included by all the sources except the one that > defines fixed_mkdir's code. Yes, that was what I meant. Similarly for fseek/ftell. The advantage of this approach is twofold: * The porting hacks are localized into a subdirectory containing only mingw-specific files. The main code for the application ('patch' in this case) doesn't need to change at all. * The porting hacks can be more easily shared among various applications that need to be ported to mingw. In the long run, perhaps mingw mkdir, fseek, ftell can be fixed. (Or perhaps not -- there may be some reason that mingw has to depart from POSIX here.) But in the short run it ought to be relatively easy to take the approach outlined above. The approach already works for djgpp. |
From: Benjamin R. <Ben...@ep...> - 2003-10-25 13:42:28
|
Hi Eli, "Eli Zaretskii" <el...@el...> writes: >> > The solution is to fix the library function > I didn't mean to patch the library, I meant to write a substitute > for it. Sure, agreed. benny |
From: Manu <ma...@wa...> - 2003-10-25 15:19:15
|
Eli Zaretskii wrote: [...] > I didn't mean to patch the library, I meant to write a substitute for > it. For example, you write a function called fixed_mkdir that does > the right thing with the second argument, then say > > #define mkdir fixed_mkdir > > in some header included by all the sources except the one that > defines fixed_mkdir's code. I'm missing something or this doesn't work: I experimentally added "#define mkdir fixed_mkdir" in config.h. Then: util.c: In function `makedirs': util.c:885: too many arguments to function `fixed_mkdir' make: *** [util.o] Error 1 If I change it to: "#define mkdir(name, mode) ((fixed_mkdir) (name, mode))", Then: gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"ed\" -I. -I. -g -O2 addext.c In file included from C:/DEV/MSYS/1.0/mingw/include/unistd.h:9, from addext.c:49: C:/DEV/MSYS/1.0/mingw/include/io.h:145:39: macro "mkdir" requires 2 arguments, but only 1 given make: *** [addext.o] Error 1 Same problem if I move it to common.h. Manu. |
From: Earnie B. <ea...@us...> - 2003-10-25 21:34:34
|
Manu wrote: > Eli Zaretskii wrote: > [...] > >>I didn't mean to patch the library, I meant to write a substitute for >>it. For example, you write a function called fixed_mkdir that does >>the right thing with the second argument, then say >> >> #define mkdir fixed_mkdir >> >>in some header included by all the sources except the one that >>defines fixed_mkdir's code. > > > I'm missing something or this doesn't work: > > I experimentally added "#define mkdir fixed_mkdir" in config.h. > Then: > util.c: In function `makedirs': > util.c:885: too many arguments to function `fixed_mkdir' > make: *** [util.o] Error 1 > > If I change it to: > "#define mkdir(name, mode) ((fixed_mkdir) (name, mode))", > Then: > gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\"ed\" -I. -I. -g -O2 addext.c > In file included from C:/DEV/MSYS/1.0/mingw/include/unistd.h:9, > from addext.c:49: > C:/DEV/MSYS/1.0/mingw/include/io.h:145:39: macro "mkdir" requires 2 arguments, but only 1 given > make: *** [addext.o] Error 1 > > Same problem if I move it to common.h. > You've defined mkdir before you included the io.h header. You could try setting _NO_OLDNAMES to avoid it, but that would most likely cause you other unwanted results. Your best bet is to create the mkdir definition after you've included unistd.h. Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Eli Z. <el...@el...> - 2003-10-25 17:32:32
|
> From: "Manu" <ma...@wa...> > Date: Sat, 25 Oct 2003 17:29:00 +0200 > > I experimentally added "#define mkdir fixed_mkdir" in config.h. > Then: > util.c: In function `makedirs': > util.c:885: too many arguments to function `fixed_mkdir' > make: *** [util.o] Error 1 This seems to indicate that some header where you have a prototype of mkdir (which on your system takes 1 argument) was seen by the compiler _after_ config.h, and thus it was processed as the prototype of fixed_mkdir. You need to "#define mkdir fixed_mkdir" after all the header files are included. Thus, config.h is not a good place for it. |
From: Paul E. <eggert@CS.UCLA.EDU> - 2003-10-25 21:15:59
|
"Eli Zaretskii" <el...@el...> writes: > This seems to indicate that some header where you have a prototype of > mkdir (which on your system takes 1 argument) was seen by the > compiler _after_ config.h, and thus it was processed as the prototype > of fixed_mkdir. Yes; the header is <unistd.h>, which apparently includes <io.h>. Perhaps we can work around the problem on mingw by defining our own unistd.h, which looks like this: #include "/path/to/mingw's/unistd.h" #define mkdir(d, m) ((mkdir) (d)) That way, we wouldn't have to modify the existing source code or .m4 files at all. |
From: Filip N. <xn...@vo...> - 2003-10-25 22:56:19
|
----- Original Message ----- From: "Paul Eggert" <eggert@CS.UCLA.EDU> To: "Eli Zaretskii" <el...@el...> Cc: "Manu" <ma...@wa...>; <Ben...@ep...>; <min...@li...>; <bug...@gn...>; <bug...@gn...>; <st...@ca...> Sent: Saturday, October 25, 2003 11:11 PM Subject: Re: [Mingw-users] Re: More patch 2.5.9 hacking ... > Perhaps we can work around the problem on mingw by defining our own > unistd.h, which looks like this: > > #include "/path/to/mingw's/unistd.h" > #define mkdir(d, m) ((mkdir) (d)) Or better: #include_next <unistd.h> #define mkdir(d, m) ((mkdir) (d)) > > That way, we wouldn't have to modify the existing source code or .m4 > files at all. Filip |
From: Manu <ma...@wa...> - 2003-10-25 21:55:10
|
Paul Eggert wrote: > "Eli Zaretskii" <el...@el...> writes: > > > This seems to indicate that some header where you have a prototype of > > mkdir (which on your system takes 1 argument) was seen by the > > compiler _after_ config.h, and thus it was processed as the prototype > > of fixed_mkdir. > > Yes; the header is <unistd.h>, which apparently includes <io.h>. > > Perhaps we can work around the problem on mingw by defining our own > unistd.h, which looks like this: > > #include "/path/to/mingw's/unistd.h" > #define mkdir(d, m) ((mkdir) (d)) > > That way, we wouldn't have to modify the existing source code or .m4 > files at all. If MinGW developers accept the following changes to MinGW's unistd.h, it would definitely fix that problem, in a very clean way: <unistd.h> /* * This file is part of the Mingw32 package. * * unistd.h maps (roughly) to io.h */ #ifndef __STRICT_ANSI__ #include <io.h> #include <process.h> #ifndef mkdir # define mkdir(name, mode) ((mkdir) (name)) #endif #endif </unistd.h> Since unistd.h is not a standard header under Windows, adding a bit more of Unix inside shouldn't bring the chaos, it would fix a very common and so boring problem, then porters will concentrate their efforts on something more _consistent_. Manu. |
From: <dan...@ya...> - 2003-10-26 05:28:21
|
--- Manu > > If MinGW developers accept the following changes to MinGW's unistd.h, > it would definitely fix that problem, in a very clean way: > > <unistd.h> > /* > * This file is part of the Mingw32 package. > * > * unistd.h maps (roughly) to io.h > */ > > #ifndef __STRICT_ANSI__ > #include <io.h> > #include <process.h> > > #ifndef mkdir > # define mkdir(name, mode) ((mkdir) (name)) > #endif > > #endif > > </unistd.h> > > Since unistd.h is not a standard header under Windows, > adding a bit more of Unix inside shouldn't bring the chaos, > it would fix a very common and so boring problem, then > porters will concentrate their efforts on something more > _consistent_. > But it will break projects that expect mkdir to behave as documented in MS doc's but include <unistd.h> for other reasons. Other major projects (eg binutils, gcc) seem to be able to live with a one-arg mkdir. I don't like the idea of hacking system headers just to accomodate one project -- not a good precedent. Danny > Manu. > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: The SF.net Donation Program. > Do you like what SourceForge.net is doing for the Open > Source Community? Make a contribution, and help us add new > features and functionality. Click here: http://sourceforge.net/donate/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://personals.yahoo.com.au - Yahoo! Personals New people, new possibilities. FREE for a limited time. |
From: Earnie B. <ea...@us...> - 2003-10-26 15:30:12
|
Danny Smith wrote: >>Since unistd.h is not a standard header under Windows, >>adding a bit more of Unix inside shouldn't bring the chaos, >>it would fix a very common and so boring problem, then >>porters will concentrate their efforts on something more >>_consistent_. >> > > > But it will break projects that expect mkdir to behave as documented in > MS doc's but include <unistd.h> for other reasons. > If projects are using the MS mkdir as documented then they will be using _mkdir and not mkdir. > Other major projects (eg binutils, gcc) seem to be able to live with a one-arg > mkdir. I don't like the idea of hacking system headers just to accomodate > one project -- not a good precedent. > You mean that a project may be defining mkdir already and then start getting errors because we add this definition ourselves causing grief for the maintainers of those projects? I think this should have been done in our implementation of unistd.h already so those projects would not have had to deal with the one argument mkdir themselves. I don't think that it accomodates just one project but instead it's a benefit to many. It will be one less portability point to deal with. Earnie -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |
From: Earnie B. <ea...@us...> - 2003-10-26 15:17:22
|
Manu wrote: > > If MinGW developers accept the following changes to MinGW's unistd.h, > it would definitely fix that problem, in a very clean way: > > <unistd.h> > /* > * This file is part of the Mingw32 package. > * > * unistd.h maps (roughly) to io.h > */ > > #ifndef __STRICT_ANSI__ Add an error here: #ifdef mkdir # error You have defined mkdir as a macro #endif > #include <io.h> > #include <process.h> > > #ifndef mkdir Remove this conditional since we've already check for definition and presented an error. > # define mkdir(name, mode) ((mkdir) (name)) Change this to #define mkdir(name, mode) ((_mkdir) (name)) You must use the MS defined _mkdir reference. > #endif > > #endif > > </unistd.h> > > Since unistd.h is not a standard header under Windows, > adding a bit more of Unix inside shouldn't bring the chaos, > it would fix a very common and so boring problem, then > porters will concentrate their efforts on something more > _consistent_. > Yes I agree. Earnie. -- http://www.mingw.org Powered by SourceForge <http://sourceforge.net/projects/mingw> |