From: Earnie B. <ea...@us...> - 2005-06-03 13:22:50
|
Any comments on Mark's request? Earnie ------ Original Message ------ Subject: [Mingw-msys] libgen.h (dirname, basename) and realpath implementation To: min...@li... From: Mark Junker <mj...@gm...> Date: Thu, 02 Jun 2005 21:41:39 +0200 Hi, I'd like to see an implementation for libgen.h (dirname and basename only) and realpath in MSYS (and MinGW itself). Here is my current replacement: /*---------------------------------------------------------------------------*/ static char *dirname(char *path) { static char buffer[260]; size_t len; if (path==NULL) { strcpy(buffer, "."); return buffer; } len = strlen(path); assert(len<sizeof(buffer)); if (len!=0 && (path[len-1]=='/' || path[len-1]=='\\')) { --len; } while (len!=0 && path[len-1]!='/' && path[len-1]!='\\') { --len; } if (len==0) { strcpy(buffer, "."); } else if (len==1) { if (path[0]=='/' || path[0]=='\\') { strcpy(buffer, "/"); } else { strcpy(buffer, "."); } } else { memcpy(buffer, path, len-1); } return buffer; } /*---------------------------------------------------------------------------*/ static char *basename(char *path) { static char buffer[260]; size_t len_start, len; if (path==NULL) { strcpy(buffer, "."); return buffer; } len = strlen(path); assert(len<sizeof(buffer)); if (len!=0 && (path[len-1]=='/' || path[len-1]=='\\')) { if (len==1) { strcpy(buffer, "/"); return buffer; } --len; } len_start = len; while (len!=0 && path[len-1]!='/' && path[len-1]!='\\') { --len; } if (len==0) { strcpy(buffer, "."); } else { memcpy(buffer, path + len, len_start - len); } return buffer; } /*---------------------------------------------------------------------------*/ static char *realpath(const char *path, char *resolved_path) { char *pszFilePart; if (GetFullPathNameA(path, MAXPATHLEN, resolved_path, &pszFilePart)==0) return NULL; return resolved_path; } /*---------------------------------------------------------------------------*/ ------------------------------------------------------- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 _______________________________________________ Mingw-msys mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-msys |
From: Christopher F. <me...@cg...> - 2005-06-03 16:03:50
|
On Fri, Jun 03, 2005 at 01:23:37PM +0000, Earnie Boyd wrote: >Any comments on Mark's request? FWIW, discussions in the gdb mailing list concerning a MinGW version of realpath have unearthed the fact that realpath is supposed to check for the existence of the path. GetFullPathName doesn't do that so a fully compliant version of realpath would be a little more complicated. Otherwise, I think I've previously suggested that these functions would be useful, so I think it's a good idea to include them. cgf >/*---------------------------------------------------------------------------*/ >static >char *realpath(const char *path, char *resolved_path) >{ > char *pszFilePart; > if (GetFullPathNameA(path, MAXPATHLEN, resolved_path, &pszFilePart)==0) > return NULL; > return resolved_path; >} >/*---------------------------------------------------------------------------*/ |
From: Danny S. <dan...@cl...> - 2005-06-03 21:22:07
|
----- Original Message ----- From: "Earnie Boyd > Any comments on Mark's request? > > Earnie > > ------ Original Message ------ > Subject: [Mingw-msys] libgen.h (dirname, basename) and realpath > implementation > To: min...@li... > From: Mark Junker > Date: Thu, 02 Jun 2005 21:41:39 +0200 > > > Hi, > > I'd like to see an implementation for libgen.h (dirname and basename > only) and realpath in MSYS (and MinGW itself). Here is my current > replacement: > This thread on GCC patches list may be relevant. http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01029.html I can see Mark Mitchell's point. Danny |
From: Earnie B. <ea...@us...> - 2005-06-04 00:17:10
|
On 9:18:48 pm 2005-06-03 Danny Smith <dan...@cl...> wrote: > > This thread on GCC patches list may be relevant. > http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01029.html > > I can see Mark Mitchell's point. > <quote who="Mark Mitchell" archive="gcc-patches at gcc dot gnu dot org"> Personally, I'd much rather MinGW not have an extension library, or at least that it be as small as possible. I think it's very desirable to have a GNU toolchain for Windows that is *just* that; for example, some people like/need to be able to compile GNU software with a non-GNU compiler. </quote> I understand this point as well. However, I also understand the point of the extension library. Perhaps some environment setting to control the addition of the mingwex library would keep everyone happy? Inclusion by default should remain the normal. Earnie |
From: Christopher F. <me...@cg...> - 2005-06-04 02:37:30
|
On Sat, Jun 04, 2005 at 12:18:04AM +0000, Earnie Boyd wrote: >On 9:18:48 pm 2005-06-03 Danny Smith <dan...@cl...> wrote: >>This thread on GCC patches list may be relevant. >>http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01029.html >> >>I can see Mark Mitchell's point. >> > ><quote who="Mark Mitchell" archive="gcc-patches at gcc dot gnu dot >org"> Personally, I'd much rather MinGW not have an extension library, >or at least that it be as small as possible. I think it's very >desirable to have a GNU toolchain for Windows that is *just* that; for >example, some people like/need to be able to compile GNU software with >a non-GNU compiler. </quote> > >I understand this point as well. However, I also understand the point >of the extension library. Perhaps some environment setting to control >the addition of the mingwex library would keep everyone happy? >Inclusion by default should remain the normal. There's also Ulrich Drepper's point about the destabilizing effects of having to maintain something with a completely different API in code that is primarily intended to be used with UNIX. I actually disagree with Mark's point (assuming I understand it) pretty strongly. I think that anything which moves system oddities away from core code of large projects like gcc is desirable. cgf |
From: Danny S. <dan...@cl...> - 2005-06-04 04:25:54
|
From: "Christopher Faylor" < Sent: Saturday, 4 June 2005 14:37 > On Sat, Jun 04, 2005 at 12:18:04AM +0000, Earnie Boyd wrote: > >On 9:18:48 pm 2005-06-03 Danny Smith wrote: > >>This thread on GCC patches list may be relevant. > >>http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01029.html > >> > >>I can see Mark Mitchell's point. > >> > > > ><quote who="Mark Mitchell" archive="gcc-patches at gcc dot gnu dot > >org"> Personally, I'd much rather MinGW not have an extension library, > >or at least that it be as small as possible. I think it's very > >desirable to have a GNU toolchain for Windows that is *just* that; for > >example, some people like/need to be able to compile GNU software with > >a non-GNU compiler. </quote> > > > >I understand this point as well. However, I also understand the point > >of the extension library. Perhaps some environment setting to control > >the addition of the mingwex library would keep everyone happy? > >Inclusion by default should remain the normal. > > There's also Ulrich Drepper's point about the destabilizing effects of > having to maintain something with a completely different API in code > that is primarily intended to be used with UNIX. > > I actually disagree with Mark's point (assuming I understand it) pretty > strongly. I think that anything which moves system oddities away from > core code of large projects like gcc is desirable. > Isn't that libiberty's job (which I thought was Mark's point) Anyway, if we are going to start adding more UNIX/BSD oddities to mingw, we need to have some policy about what is acceptable, what standard's documentation we follow and how the prototypes are guarded (or not) in headers I really don't want to see oddities like index polluting the namespace. Danny > cgf > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput > a projector? How fast can you ride your desk chair down the office luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Christopher F. <me...@cg...> - 2005-06-04 04:30:19
|
On Sat, Jun 04, 2005 at 04:23:42PM +1200, Danny Smith wrote: >Isn't that libiberty's job (which I thought was Mark's point) Could be, but libiberty is really only good for gcc/gdb/binutils and other GNU projects. Is that sufficient for MinGW's goals? Having these available in some standard MinGW library means you don't have to get approval to make changes. >Anyway, if we are going to start adding more UNIX/BSD oddities to >mingw, we need to have some policy about what is acceptable, what >standard's documentation we follow and how the prototypes are guarded >(or not) in headers > >I really don't want to see oddities like index polluting the namespace. There's always SUSv3. cgf |
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-06-06 07:04:10
|
Hi, > Anyway, if we are going to start adding more UNIX/BSD oddities to mingw, we need > to have some policy about what is acceptable, what standard's documentation we > follow > and how the prototypes are guarded (or not) in headers > > I really don't want to see oddities like index polluting the namespace. What I like about MinGW is that it's a Windows compiler with minimal overwheight. There's already Cygwin and commercial products for those who need POSIX compatibility. I see no point adding POSIX compatibility stuff to MinGW. Dimitri Papadopoulos |
From: Keith M. <kei...@nt...> - 2005-06-04 10:04:16
|
On Friday 03 June 2005 2:23 pm, Earnie Boyd wrote: > I'd like to see an implementation for libgen.h (dirname and basename > only) and realpath in MSYS (and MinGW itself). ... These are functions which I also have occasional use for. For realpath, I generally find #include <stdlib.h> #define realpath( p, r ) _fullpath( (r), (p), _MAX_PATH ) to be an adequate substitute, (although I guess the same limitation about checking if the resolved path exists, as mentioned earlier by Chris Faylor, will also be present, and there is an onus on the user to ensure that `r' refers to an allocated buffer of at least _MAX_PATH bytes, or is NULL, to allow _fullpath to allocate it itself). For basename, and dirname, I also wrote my own, several years ago -- I've attached copies for comparison with Mark's. I've also provided a small test program, demonstrating conformance with SUSv2, according to the following extract from the basename/dirname manpage, on my GNU/Linux box: > The functions dirname and basename break a null-terminated pathname > string into directory and filename components. In the usual case, > dirname returns the string up to, but not including, the final '/', and > basename returns the component following the final '/'. Trailing '/' > characters are not counted as part of the pathname. > > If path does not contain a slash, dirname returns the string "." while > basename returns a copy of path. If path is the string "/", then both > dirname and basename return the string "/". If path is a NULL pointer > or points to an empty string, then both dirname and basename return the > string ".". > > Concatenating the string returned by dirname, a "/", and the string > returned by basename yields a complete pathname. > > Both dirname and basename may modify the contents of path, so if you > need to preserve the pathname string, copies should be passed to these > functions. Furthermore, dirname and basename may return pointers to > statically allocated memory which may be overwritten by subsequent > calls. > > The following list of examples (taken from SUSv2) shows the strings > returned by dirname and basename for different paths: > > path dirname basename > "/usr/lib" "/usr" "lib" > "/usr/" "/" "usr" > "usr" "." "usr" > "/" "/" "/" > "." "." "." > ".." "." ".." If I run Mark's implementation's in my test case, (note that I've added three extra tests, to demonstrate proper handling of trailing dir separators), I see: [keith@banshee keith]$ gcc -o zz testcase.c mjscod.c [keith@banshee keith]$ ./zz path dirname basename status ---------- ---------- ---------- -------- /usr/lib /usr lib PASS /usr/ / usr PASS usr . . FAIL / . / FAIL . . . PASS .. . . FAIL /usr//// /usr// . FAIL /usr/// /usr// . FAIL /usr// /usr// . FAIL ---------- ---------- ---------- -------- 3 of 9 tests passed; 6 failed while, for my own implementation: [keith@banshee keith]$ gcc -o xx testcase.c basename.c dirname.c [keith@banshee keith]$ ./xx path dirname basename status ---------- ---------- ---------- -------- /usr/lib /usr lib PASS /usr/ / usr PASS usr . usr PASS / / / PASS . . . PASS .. . .. PASS /usr//// / usr PASS /usr/// / usr PASS /usr// / usr PASS ---------- ---------- ---------- -------- 9 of 9 tests passed; 0 failed I think my basename implementation is fairly solid; my dirname perhaps less so. Note that both will treat an initial `?:' as a drive designator, making it part of the dirname component of the path -- an issue which Mark doesn't address. testcase.c, basename.c and dirname.c, as attached, are my implementations. Feel free to use them, without copyright restriction, but equally without warranty of any kind. Best regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-06-06 11:19:01
|
On 7:03:54 am 2005-06-06 Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote: > Hi, > > > Anyway, if we are going to start adding more UNIX/BSD oddities to > > mingw, we need to have some policy about what is acceptable, what > > standard's documentation we follow > > and how the prototypes are guarded (or not) in headers > > > > I really don't want to see oddities like index polluting the > namespace. > > What I like about MinGW is that it's a Windows compiler with minimal > overwheight. There's already Cygwin and commercial products for those > who need POSIX compatibility. I see no point adding POSIX > compatibility stuff to MinGW. > Is it not possible to support both minimal and extended? Where extended includes whatever nicety we desire. So we ``#define _MINGWEX 1'' when we want to use the extended or ``#undef _MINGWEX'' when we don't. Switches can be created to control the definition in a more canonal approach, e.g. --noextend. Earnie -- MinGW - http://www.mingw.org/ Wiki - http://www.mingw.org/MinGWiki/ Bug Report - http://sourceforge.net/tracker/?group_id=2435&atid=102435 Submit Patch - http://sourceforge.net/tracker/?group_id=2435&atid=302435 SF Project - http://sourceforge.net/projects/mingw Job Listing - http://sf.net/people/viewjob.php?group_id=2435&job_id=21643 Job Listing - http://sf.net/people/viewjob.php?group_id=46778&job_id=22223 |
From: Christopher F. <me...@cg...> - 2005-06-06 18:11:34
|
On Mon, Jun 06, 2005 at 11:19:42AM +0000, Earnie Boyd wrote: >On 7:03:54 am 2005-06-06 Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote: >>>Anyway, if we are going to start adding more UNIX/BSD oddities to >>>mingw, we need to have some policy about what is acceptable, what >>>standard's documentation we follow and how the prototypes are guarded >>>(or not) in headers >>> >>>I really don't want to see oddities like index polluting the namespace. >> >>What I like about MinGW is that it's a Windows compiler with minimal >>overwheight. There's already Cygwin and commercial products for those >>who need POSIX compatibility. I see no point adding POSIX >>compatibility stuff to MinGW. > >Is it not possible to support both minimal and extended? Where >extended includes whatever nicety we desire. So we ``#define _MINGWEX >1'' when we want to use the extended or ``#undef _MINGWEX'' when we >don't. Switches can be created to control the definition in a more >canonal approach, e.g. --noextend. Since there are already UNIX functions included in mingwex (e.g., "getopt") I don't think the argument that POSIX compatibility should be avoided can really be made. I really don't see the harm in including a few simple/common functions for optional use. In fact, I'm working on a port of "index()" right now. :-) cgf |
From: Keith M. <kei...@nt...> - 2005-06-06 19:00:35
|
On Monday 06 June 2005 7:11 pm, Christopher Faylor wrote: > Since there are already UNIX functions included in mingwex (e.g., > "getopt") I don't think the argument that POSIX compatibility should be > avoided can really be made. > > I really don't see the harm in including a few simple/common functions > for optional use. I completely agree here, and see no need for any extra complication, by trying to conceal them with #ifndef MINGWEX, or whatever. > In fact, I'm working on a port of "index()" right now. :-) #define index strchr #define rindex strrchr work well for me -- unless, of course, you are building wide character support into your "index()" implementation. Best regards, Keith. |
From: Danny S. <dan...@cl...> - 2005-06-06 21:50:44
|
Keith Marshall wrote: > On Monday 06 June 2005 7:11 pm, Christopher Faylor wrote: > > Since there are already UNIX functions included in mingwex (e.g., > > "getopt") I don't think the argument that POSIX=20 > compatibility should=20 > > be avoided can really be made. > > > > In fact, I'm working on a port of "index()" right now. =A0:-) >=20 > #define index strchr > #define rindex strrchr >=20 > work well for me -- unless, of course, you are building wide=20 > character=20 > support into your "index()" implementation. >=20 This is the kind of namespace pollution I worry about. I have no real problesm with basename, dirname since they are documented by a standard and add new functionality. But a define like index is bound to cause problems without adding anything new. Danny > Best regards, > Keith. >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far=20 > can you shotput a projector? How fast can you ride your desk=20 > chair down the office luge track? If you want to score the=20 > big prize, get to know the little guy. =20 > Play to win an NEC 61" plasma display:=20 > http://www.necitguy.com/?r=3D20=20 > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li...=20 > https://lists.sourceforge.net/lists/listinfo/m> ingw-dvlpr >=20 > --=20 >=20 > No virus found in this incoming message. >=20 > Checked by AVG Anti-Virus. > Version: 7.0.323 / Virus Database: 267.6.2 - Release Date: 6/4/2005 > =20 >=20 --=20 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.6.2 - Release Date: 6/4/2005 =20 |
From: Keith M. <kei...@nt...> - 2005-06-08 16:08:35
|
On Monday 06 June 2005 10:51 pm, Danny Smith wrote: > > #define index strchr > > #define rindex strrchr > > > > work well for me -- unless, of course, you are building wide > > character support into your "index()" implementation. > > > > This is the kind of namespace pollution I worry about. I have no real > problesm with basename, dirname since they are documented by a standard > and add new functionality. > But a define like index is bound to cause problems without adding > anything new. Why is it *bound* to cause problems? In any case, I don't advocate that these defines should appear in any standard header -- simply that I have found them to be adequate, when porting any package which expects index()/rindex(), rather than strchr()/strrchr(), (man-1.5 is one such). In GNU/Linux, libc provides *both* index() and strchr(), and *both* rindex() and strrchr(); the only apparent distinction is that the manpage for strchr() and strrchr() *very* explicitly states that they work with strings where one character is *exactly* one byte. This caveat is not stated for index() and rindex(), leaving the implicit notion that these functions *may* be able to handle multibyte characters, in a locale dependent fashion. AIUI, one of the primary goals of MSYS/MinGW is to provide an environment on Win32, which will facilitate the running of the standard Open Source incantation "./configure && make && make install", and so facilitate the porting of Open Source packages to Win32. To properly achieve that goal, it is incumbent on us to provide implementations of everything which is standard on the Open Source platforms, and which Microsoft don't provide in msvcrt.dll, and even to provide replacements for functionality which may be broken in msvcrt.dll. This implies that if it's required by POSIX, we sould provide it; if it's in libc on GNU/Linux, any of the BSDs, or common UNIXes, then we should consider providing it. However, to get back to index() and rindex(): I wouldn't suggest simply adding the two defines I suggested to any standard header, because that would preclude any possible implementation which could handle multibyte characters. My preferred solution is to make configure check for the availability of index() and rindex(), where the package requires them, e.g. by use of autoconf's AC_CHECK_FUNCS macro, and have a globally included, project supplied header conditionally provide the replacement defines, when either HAVE_INDEX or HAVE_RINDEX is not defined, as appropriate. Best regards, Keith. |
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-06-09 08:07:36
|
Hi, > AIUI, one of the primary goals of MSYS/MinGW is to provide an environment on > Win32, which will facilitate the running of the standard Open Source > incantation "./configure && make && make install", and so facilitate the > porting of Open Source packages to Win32. To properly achieve that goal, it > is incumbent on us to provide implementations of everything which is standard > on the Open Source platforms, and which Microsoft don't provide in > msvcrt.dll, and even to provide replacements for functionality which may be > broken in msvcrt.dll. This implies that if it's required by POSIX, we sould > provide it; if it's in libc on GNU/Linux, any of the BSDs, or common UNIXes, > then we should consider providing it. That's absolutely not what I had understood. Cygwin already provides a POSIX compatibility layer. My understanding is that Cygwin provides the POSIX environment needed to seemlessly port whole Unix programs. On the other hand MSYS/MinGW is a port of gcc and other development tools to the Win32 environment. There are facilities supporting the standard "./configure && make && make install" incantation, but that's where it stops : these facilities help porting the *build system*, they don't help porting *source code*. If I'm wrong, what's the difference between Cygwin and MinGW? What's wrong with Cygwin? Will MinGW eventually encompass all the Cygwin functionality? Dimitri Papadopoulos |
From: Christopher F. <me...@cg...> - 2005-06-08 18:05:47
|
On Tue, Jun 07, 2005 at 09:51:03AM +1200, Danny Smith wrote: > Keith Marshall wrote: >> On Monday 06 June 2005 7:11 pm, Christopher Faylor wrote: >> > Since there are already UNIX functions included in mingwex (e.g., >> > "getopt") I don't think the argument that POSIX >> compatibility should >> > be avoided can really be made. >> > >> > In fact, I'm working on a port of "index()" right now. ?:-) >> >> #define index strchr >> #define rindex strrchr >> >> work well for me -- unless, of course, you are building wide >> character >> support into your "index()" implementation. >> > >This is the kind of namespace pollution I worry about. I have no real >problesm with basename, dirname since they are documented by a standard >and add new functionality. But a define like index is bound to cause >problems without adding anything new. For the record, I was just kidding about index(). cgf |
From: Keith M. <kei...@nt...> - 2005-06-10 11:26:12
|
On Thursday 09 June 2005 9:07 am, Dimitri Papadopoulos-Orfanos wrote: > > AIUI, one of the primary goals of MSYS/MinGW is to provide an environment > > on Win32, which will facilitate the running of the standard Open Source > > incantation "./configure && make && make install", and so facilitate the > > porting of Open Source packages to Win32. To properly achieve that goal, > > it is incumbent on us to provide implementations of everything which is > > standard on the Open Source platforms, and which Microsoft don't provide > > in msvcrt.dll, and even to provide replacements for functionality which > > may be broken in msvcrt.dll. This implies that if it's required by > > POSIX, we sould provide it; if it's in libc on GNU/Linux, any of the > > BSDs, or common UNIXes, then we should consider providing it. > > That's absolutely not what I had understood. Ok, so we have a difference in expectations for MinGW/MSYS. That's fine; in fact, that it can satisfy our differring expectations reasonably successfully is strong testament to its quality and value as a software product. But perhaps Earnie could be prevailed upon to clarify his stance wrt our different understandings. > Cygwin already provides a POSIX compatibility layer. It does. But it's a *huge* package to download and install, and its sheer size alone is sufficient to discourage many from even trying it. > My understanding is that Cygwin provides the POSIX environment needed to > seemlessly port whole Unix programs. Again, it does, and does a good job too. However, any programs so ported require a Cygwin installation on *every* host where they are to be deployed. IMO, this is it's main disadvantage. > On the other hand MSYS/MinGW is a port of gcc and other development > tools to the Win32 environment. There are facilities supporting the > standard "./configure && make && make install" incantation, but that's > where it stops : these facilities help porting the *build system*, they > don't help porting *source code*. AIUI, MinGW/MSYS is a fork of an early version of Cygwin, but set up to produce *native* Win32 executables, dependent on the functionality of the native msvcrt.dll, rather than any third party POSIX emulator; these can run on any Win32 host, *without* requiring the prior installation of any such POSIX emulator. This, for me, is why it beats Cygwin hands down -- I can port the collection of *nix tools which I use daily, copy them together with MSYS to a USB key, and carry them around in my pocket, for use on *any* Win32 host. That just would not be practical with Cygwin, IMO. > If I'm wrong, what's the difference between Cygwin and MinGW? What's > wrong with Cygwin? Will MinGW eventually encompass all the Cygwin > functionality? There's nothing wrong with Cygwin; it does its job of emulating a full POSIX system on top of Win32 very well. But, it is *huge*, and, because it does employ an emulator, it is generally slower than the native binaries generated by MinGW. It just isn't the best solution for everyone. But, just because some feature, which is lacking from msvcrt.dll, is provided by Cygwin, is that sufficient reason to refuse to add it to libmingwex.a? If you do that, IMO, then you diminish the overall value of MinGW as a product, in its own right. *You* may not have any use for such features, but there are many others who will have. You may point out that some effort will always be required, when migrating *nix code to Win32, and generally speaking that is so. There are many aspects in which the behaviour of Win32 is so completely incompatible with *nix, that this will always be the case. However, there are also a number of functions -- dirname and basename are examples -- which are fairly ubiquitous on *nix, which do not present any interoperability issues, but have simply been omitted from msvcrt.dll. It is functions such as these which I believe are good candidates for addition to libmingwex.a; indeed, I do not believe there is any real justification for *not* including them. They would simply be available to anyone who needed them, but would in no way affect any code which doesn't call them. Again, you may say that such functions are easily written from scratch, so why not address that as part of the porting operation? However, as can be seen by comparing Mark Junker's and my different implementations of dirname and basename, even functions as apparently trivial as these can present pitfalls for the unwary. I am sure my rough and ready implementations can be improved; as they stand, I think I demonstrated that, even in their present forms, they exhibit better standards conformance than Mark's -- not that there is anything wrong with Mark's offerings, which couldn't be fixed with further development and testing. The point I am trying to make is that, if two simple functions such as these require significant development and testing effort, then it can only be of benefit to the MinGW community as a whole, if well tested, debugged, and standards conformant implementations are provided in a supplied library. Best regards, Keith. |
From: Dimitri Papadopoulos-O. <pap...@sh...> - 2005-06-10 11:45:54
|
Hi, >>Cygwin already provides a POSIX compatibility layer. > > > It does. But it's a *huge* package to download and install, and its sheer > size alone is sufficient to discourage many from even trying it. Are you sure about that? As far as I know only the cygwin DLL is needed. The whole environment is huge, but executables built in this environment just need the POSIX layer DLL. > But, just because some feature, which is lacking from msvcrt.dll, is provided > by Cygwin, is that sufficient reason to refuse to add it to libmingwex.a? If > you do that, IMO, then you diminish the overall value of MinGW as a product, > in its own right. *You* may not have any use for such features, but there > are many others who will have. I don't really mind adding such features if they're needed. I just fear that MinGW may eventually grow as huge as Cygwin. I had chosen MinGW over Cygwin because of the smaller footprint of the environment. We had also ported our programs to Win32 so the POSIX compatibility layer meant uneeded complexity. On the other hand our build system did make use of the compatibility features of MinGW (make, etc.) I chose MinGW because it was small and simple. This doesn't mean it must stay that way if other users have different needs. Dimitri |
From: Earnie B. <ea...@us...> - 2005-06-10 13:14:59
|
On 11:45:35 am 2005-06-10 Dimitri Papadopoulos-Orfanos <pap...@sh...> wrote: > > I chose MinGW because it was small and simple. This doesn't mean it > must stay that way if other users have different needs. > Actually satisfying everyone is very much the ominus goal as demonstrated by my MinGW installer. I provided an all in one installer and ppl btch because it is too big. I provided a pick and choose installer and ppl btch because you have to download individual packages. Call for a vote on this issue: [ ] Add more POSIX extensions [ ] Don't add more POSIX extensions Earnie |
From: Paul G. <pga...@co...> - 2005-06-11 21:32:43
|
After reviewing my earlier post, it appears to me that I need to clarify some things. I also need to point out that I typically work best from an architectural level, not necessarily a functional level when dealing with things like Msys or MinGW. > Earnie, I am sure you or one of the other developers will probably check this and/or discard it, but felt I should at > least throw in my thoughts on the poll even though it may be discarded. > > My vote on the poll would be "Don't add more posix capability to MinGW". > > Msys, as far as I am concerned, is different than MinGW and has different needs. If there is to be any increase in terms of Posix support then it should, imho, be applied to Msys or the msys- 1.0.dll, not the MinGW (or the MinGW related libs: mingwex, mingw32 or mingwthrd ). I have long believed and maintained that MingGW itself should retain the Gnu approach to win32 development. Paul G. |
From: Keith M. <kei...@nt...> - 2005-06-10 14:27:13
|
On Friday 10 June 2005 12:45 pm, Dimitri Papadopoulos-Orfanos wrote: > >>Cygwin already provides a POSIX compatibility layer. > > > > It does. But it's a *huge* package to download and install, and its > > sheer size alone is sufficient to discourage many from even trying it. > > Are you sure about that? As far as I know only the cygwin DLL is needed. > The whole environment is huge, but executables built in this environment > just need the POSIX layer DLL. You are, of course, correct; a functional system can be set up with just the cygwin1.dll, and selected packages. However, setting up such a reduced installation is, itself not trivial, and the sheer size of the full Cygwin system is often sufficient to deter potential users from exploring. I *do* know this, because a number of my own colleagues, who could benefit from using Cygwin have told me so. Also, the dependency tracking in Cygwin's installer isn't always reliable; trying to install a subset of the full Cygwin system can leave you with a disfunctional system, with similar dependency hell to that caused by RPM, on GNU/Linux systems. > > I chose MinGW because it was small and simple. This doesn't mean it > > must stay that way if other users have different needs. So did I, and having used both Cygwin and MinGW, I find that MinGW is the better suited of the two, to my requirements. And, Earnie Boyd replied: > Actually satisfying everyone is very much the ominus goal as demonstrated > by my MinGW installer. I provided an all in one installer and ppl btch > because it is too big. I provided a pick and choose installer and ppl btch > because you have to download individual packages. > > Call for a vote on this issue: > [ ] Add more POSIX extensions > [ ] Don't add more POSIX extensions I would favour the inclusion of those functions which are not provided by M$, but which can be implemented reasonably easily. I would stop short of trying to replace the Win32 process model -- broken as I consider it to be -- with the fork/exec mechanism of POSIX, and I would also stick with porting to the Win32 threading model, rather than implementing POSIX threads. I suspect that these would be non-trivial to implement, but if someone were to achieve this, I would consider offering them as separate, add-on packages; indeed, *any* major extensions could be offered in this fashion. Best regards, Keith. |
From: Earnie B. <ea...@us...> - 2005-06-10 14:57:07
|
On 2:27:56 pm 2005-06-10 Keith Marshall <kei...@nt...> wrote: > And, Earnie Boyd replied: > > Actually satisfying everyone is very much the ominus goal as > > demonstrated by my MinGW installer. I provided an all in one > > installer and ppl btch because it is too big. I provided a pick > > and choose installer and ppl btch because you have to download > > individual packages. > > Call for a vote on this issue: > > [ ] Add more POSIX extensions > > [ ] Don't add more POSIX extensions > > I would favour the inclusion of those functions which are not > provided by M$, but which can be implemented reasonably easily. I > would stop short of trying to replace the Win32 process model -- > broken as I consider it to be -- with the fork/exec mechanism of > POSIX, and I would also stick with porting to the Win32 threading > model, rather than implementing POSIX threads. I suspect that these > would be non-trivial to implement, but if someone were to achieve > this, I would consider offering them as separate, add-on packages; > indeed, *any* major extensions could be offered in this fashion. > Thanks Keith. Vote call ammended to impose the restrictions as Keith has specified. Earnie |
From: Christopher F. <me...@cg...> - 2005-06-10 15:57:52
|
On Fri, Jun 10, 2005 at 02:58:05PM +0000, Earnie Boyd wrote: >On 2:27:56 pm 2005-06-10 Keith Marshall <kei...@nt...> >wrote: > >> And, Earnie Boyd replied: >> > Actually satisfying everyone is very much the ominus goal as >> > demonstrated by my MinGW installer. I provided an all in one >> > installer and ppl btch because it is too big. I provided a pick >> > and choose installer and ppl btch because you have to download >> > individual packages. >> > Call for a vote on this issue: >> > [ ] Add more POSIX extensions >> > [ ] Don't add more POSIX extensions >> >> I would favour the inclusion of those functions which are not >> provided by M$, but which can be implemented reasonably easily. I >> would stop short of trying to replace the Win32 process model -- >> broken as I consider it to be -- with the fork/exec mechanism of >> POSIX, and I would also stick with porting to the Win32 threading >> model, rather than implementing POSIX threads. I suspect that these >> would be non-trivial to implement, but if someone were to achieve >> this, I would consider offering them as separate, add-on packages; >> indeed, *any* major extensions could be offered in this fashion. >> > >Thanks Keith. Vote call ammended to impose the restrictions as Keith has >specified. I vote (assuming I get a vote) is for more POSIX extensions which can be implemented relatively easily. That means no fork/exec. No signals. No unix domain sockets. etc. How about if every proposed addition is reviewed to make sure that it matches the "not too complicated" criteria? cgf |
From: <ad...@sh...> - 2005-06-13 04:55:55
|
---------- Original Message ---------- > I would favour the inclusion of those functions which are not provided by M$, > but which can be implemented reasonably easily. I would stop short of trying > to replace the Win32 process model -- broken as I consider it to be -- with > the fork/exec mechanism of POSIX, and I would also stick with porting to the > Win32 threading model, rather than implementing POSIX threads. I suspect > that these would be non-trivial to implement, but if someone were to achieve > this, I would consider offering them as separate, add-on packages; indeed, > *any* major extensions could be offered in this fashion. > > Best regards, > Keith. I agree with Keith in general. Maybe there could be some simple criteria to judge whether a specific function should be included in MinGW? E.g. * Functions should not impose an additional emulation layer * Functions should be declared in their separate header, or in <unistd.h>, but not in the standard headers * ... I do not think separating functions in two different libraries attractive. I would prefer that no additional "-l" options be required, or be used like the UNIX way. Best regards, Yongwei |
From: Aaron W. L. <aar...@aa...> - 2005-06-13 06:28:50
|
ad...@sh... wrote: > I do not think separating functions in two different libraries attractive. I would prefer that no additional "-l" options be required, or be used like the UNIX way. Why? I really hate the way most Unix clones put both standard C interfaces and standard operating system interfaces into the same 'libc,' as these two things are really entirely unrelated. I'm not sure what you mean by `additional "-l" options,' as certainly I am not advocating that any user be forced to add a -l to the gcc command line unless he is doing something unusual. Any change would be entirely transparent to the user, visible only in the case where a user had a particular preference regarding Unix compatibility. Regarding performance, I would be suprised if splitting the libraries here made any code slower at compiletime, but it could easily some code faster, in the case that no Unix compatibility was needed. Aaron W. LaFramboise |