Menu
▾
▴
mingw-users
|
From: Danny S. <dan...@cl...> - 2007-06-15 01:19:18
|
> -----Original Message----- > From: min...@li... > [mailto:min...@li...] On Behalf > Of Laia Manrique > Sent: Friday, 15 June 2007 12:07 p.m. > To: min...@li... > Subject: [Mingw-users] glibc searching and sorting > > > I am trying to compile in Windows a piece of code that uses some of > the "Searching and sorting" functions in the GNU C Library. To be > honest, I am not very familiar with Windows, but I was definitely not > expecting any problems in finding ports for glibc (or, at least, for > the parts of glibc that are not too related to Linux). > > After a few hours searching, though, all I've been able to find is a > couple of excedingly outdated ports (LibGW32C actually contained a > port for tsearch and the other functions I am interested in). Is there > anything newer and more regularly mantained, hopefully related to > MinGW? Are you after: tsearch, tfind, tdelete, twalk, tdestroy - manage a binary tree ? I use those myself and can point to code. Should these be in libmingwwex.a (with uglified __names)? Danny > > Thanks in advance. > > Laia > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
|
From: Danny S. <dan...@cl...> - 2007-06-23 00:27:20
|
> > If anyone things that I can be helpful in adding these functions to > MinGW, please do not hesitate to ask (although, remember, I am no real > programmer :) > I have added twalk, tsearch, tdelete and tfind to libmingwex. http://www.cygwin.com/ml/cygwin-cvs/2007-q2/msg00050.html These are standardized and documented by Posix. I am not familiar with tdestroy, so some help there would be appreciated. Danny > Laia. > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
|
From: Keith M. <kei...@us...> - 2007-06-15 10:12:46
|
On Friday 15 June 2007 02:19, Danny Smith wrote: > Are you after: tsearch, tfind, tdelete, twalk, tdestroy - manage a > binary tree ? > I use those myself and can point to code. =A0Should these be in > libmingwwex.a (with uglified __names)? I'm generally in favour of providing any extensions which make the code=20 porters life easier. I wouldn't object to adding them to libmingwex.a,=20 if they are considered generally useful, and a majority of users are=20 happy to accept the increased download size for mingw-runtime. An alternative option would be to provide a separate contributed library=20 package, as we did recently for Tor Lillqvist's port of glibc regex. But why uglify the names? Just because Microsnot do it, doesn't mean we=20 have to follow suit. Better IMO to keep the same names as are used in=20 glibc; uglification serves only to unnecessarily increase the porting=20 burden, in deference to an irrelevant Microsnot convention, (unless=20 there is a naming conflict to resolve). Regards, Keith. |
|
From: Danny S. <dan...@cl...> - 2007-06-15 19:19:24
|
> But why uglify the names? Because some people want ANSI standard. Just because Microsnot do it, > doesn't mean we > have to follow suit. Better IMO to keep the same names as > are used in > glibc; uglification serves only to unnecessarily increase the porting > burden, It avoid polluting the namespace with non-standard symbols in deference to an irrelevant Microsnot convention, (unless > there is a naming conflict to resolve). Actually, MS is doing the right thing here. Danny > > Regards, > Keith. > > -------------------------------------------------------------- > ----------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
|
From: Laia M. <man...@gm...> - 2007-06-15 22:03:19
|
Thank you all for your answers. Here is a summary of my thoughts: 1) Yes, what I was after was the binary tree search and management functions (tsearch, tfind, tdestroy, and so on). Under glibc, these are defined in the header search.h. To make things a little more confusing, it turns out that MinGW already has a search.h, but it does not contain the same stuff as the glibc one. 2) When it comes to what should be the appropriate course of action, I really have no clue. As a Linux person that needs to maintain some ports of my Linux programs for Windows, what I am most concerned is consistency between libraries (having a straighforward port of the search part of glibc would be nice) and function names (and here I am not very concerned about adherence to standards). I realize, though, that these are MY needs, which may not be consistent with the needs of most other people. 3) I have found a solution to MY problem. It turns out that Cygwin does have a port of the binary tree search functions, which is totally consistent with glibc. Using Cygwin, thus, I can just take my code and compile it for Windows without a change :) I hope this thread will be useful for other people in the future, and I will definitely keep an eye for further developments in MinGW. Laia |
|
From: Keith M. <kei...@us...> - 2007-06-16 00:51:25
|
On Friday 15 June 2007 23:03, Laia Manrique wrote: > 3) I have found a solution to MY problem. It turns out that Cygwin > does have a port of the binary tree search functions, which is > totally consistent with glibc. Using Cygwin, thus, I can just take my > code and compile it for Windows without a change :) That's not strictly true. You can compile it for *Cygwin* without change, but it then becomes dependent on cygwin-1.dll, and it will not run natively on Windows, without it. This means that, if you choose to distribute your application, you must either:-- 1) Distribute cygwin-1.dll with it, requiring you to GPL your entire application, and make full source available, or 2) Require your end users to install Cygwin, before they can deploy your application. With a port of the required functions for use with MinGW, your application will run natively, without any such additional DLL dependency, and these restrictions can be avoided. Of course, if the Cygwin distribution limitations aren't a concern, then the Cygwin solution may best suit your needs. Regards, Keith. |
|
From: Laia M. <man...@gm...> - 2007-06-16 01:49:26
|
Keith, thanks for clarifying this. Option 1 > 1) Distribute cygwin-1.dll with it, requiring you to GPL your entire > application, and make full source available, or would probably be fine. I work in science and the source code of my programs is freely available anyway: the point is to make the algorithms I design widely available to anyone wanting to use (and improve) them. That being said---yes, it would be nice being able to forget about such "technicalities" and just provide people with an executable. So, going back to Danny's reply yesterday. Danny, you mentioned that you use these functions and that you can point to code. Any more details? Thank you all again for being so helpful. Laia |
|
From: Danny S. <dan...@cl...> - 2007-06-17 11:02:00
Attachments:
tsearch.tar.gz
|
> So, going back to Danny's reply yesterday. Danny, you mentioned that > you use these functions and that you can point to code. Any more > details? > Attached archive is modified search.h header and source files that could be put in libmingwex.a. Since search.h is a non-ANSI header, there is no need to protect the user against polluting ANSI namespace. HTH Danny |
|
From: Laia M. <man...@gm...> - 2007-06-22 21:53:19
|
Thank you Danny for sharing your code, and all the others for sharing your ideas and helping me out with this. Such a lively forum is the best argument to use MinGW. I thought I would post a wrap-up message for future reference with some information about how I finally addressed the issue. I ended up choosing the solution suggested by Ralf---using the tsearch module in gnulib (I had to change tsearch.c and search.h a little, though, to get things working). The program now compiles and runs in Windows. This solution, however, required using autoconf and automake, with which I was not really familiar. I was willing to (auto)make the extra effort to learn that stuff, but I am not sure whether other people with the same problem will do the same, so I still think that providing these functions in MinGW would be helpful (if Danny's code is added to libmingwex, though, tdestroy would be nice to have, too). As I already mentioned, a minor additional annoyance during the process is that there is already a search.h in MinGW, which does not correspond with those in gnulib or glibc. If anyone things that I can be helpful in adding these functions to MinGW, please do not hesitate to ask (although, remember, I am no real programmer :) Laia |
|
From: Charles W. <cwi...@us...> - 2007-06-16 03:19:54
|
Keith Marshall wrote: > 1) Distribute cygwin-1.dll with it, requiring you to GPL your entire > application, and make full source available, or > > 2) Require your end users to install Cygwin, before they can deploy your > application. Actually, in BOTH cases you are required to GPL your entire applicationsand make full source available (unless you negotiate with Red Hat a separate licensing arrangement). If you distribute a binary application or library that is linked against the cygwin runtime, that application or library is a "combined work" and falls under the GPL -- regardless of whether you distribute the cygwin dll itself. IANAL; please address cygwin licensing concerns to the appropriate list (cyg...@cy...), etc etc... If GPL issues aren't a concern, then the real fly in the ointment is distribution: in case (1) you're a so-called "third party provider" http://cygwin.com/acronyms/#3PP (which is not a term of endearment) because by squirreling multiple copies of cygwin1.dll on an end-user's system, you may actually break completely unrelated programs (like a pre-existing cygwin environment). One cygwin1.dll per machine, please. Then (2) is bad, because who wants to install a whole "environment" just a use Thad's Latest And Greatest Chat Application? (or cd burner, or whathaveyou). It's not a good situation; standalone deployable apps are best served on windows as full windows ports (e.g. mingw-compiled) if you can manage it. And I say that as a mainly cygwin guy. -- Chuck |
|
From: Brian D. <br...@de...> - 2007-06-16 03:23:52
|
Charles Wilson wrote: > Actually, in BOTH cases you are required to GPL your entire > applicationsand make full source available (unless you negotiate with > Red Hat a separate licensing arrangement). > > If you distribute a binary application or library that is linked against > the cygwin runtime, that application or library is a "combined work" and > falls under the GPL -- regardless of whether you distribute the cygwin > dll itself. Actually, GPL is not required, just an OSI-approved license. The CYGWIN_LICENSE file contains the following exception: In accordance with section 10 of the GPL, Red Hat permits programs whose sources are distributed under a license that complies with the Open Source definition to be linked with libcygwin.a without libcygwin.a itself causing the resulting program to be covered by the GNU GPL. But yes, there are logistical problems with distributing software ported with Cygwin so as not to interfere with existing Cygwin installs. Brian |
|
From: Keith M. <kei...@us...> - 2007-06-16 02:06:31
|
On Friday 15 June 2007 20:19, Danny Smith wrote: Sigh. You are entitled to your opinion, of course, but here we must=20 agree to disagree. I've seen all these stale old arguments before, and=20 with respect, not one of them bears scrutiny. > > But why uglify the names? =A0 > > Because some people want ANSI standard. =A0 And we satisfy that by providing the core set of functions, each=20 behaving *exactly* as specified, as required by whichever version of=20 the ANSI Standard for which we wish to claim conformance. That alone=20 is a necessary and sufficient condition of conformance. If we choose=20 to provide additional functions, however we choose to name them, they=20 have no bearing whatsoever on ANSI conformance. > > Just because Microsnot do it, doesn't mean we > > have to follow suit. =A0Better IMO to keep the same names as > > are used in > > glibc; uglification serves only to unnecessarily increase the > > porting burden, > > It avoid polluting the namespace with non-standard symbols Huh? What namespace? The functions in question would present a C=20 interface, and formally, there is no such thing as a namespace in C, so=20 how can it possibly be polluted? If you mean an ANSI pseudo-namespace,=20 which of course is an arbitrary and fictitious entity, then all symbols=20 which are not defined as required by the ANSI standard "pollute" that=20 pseudo-namespace; this is equally true, however the extra symbols are=20 named. Whether uglified or not, the extent of the "pollution" is=20 identical, for each symbol name. > > in deference to an irrelevant Microsnot convention, (unless > > there is a naming conflict to resolve). > > Actually, MS is doing the right thing here. Actually, MS is doing nothing more than adopting a convention; there is=20 nothing wrong in that, but it is entirely arbitrary, and therefore does=20 not qualify as being exclusively "right". POSIX defines many functions=20 which are not required by ANSI, yet these do not have uglified names. =20 Is the POSIX Standards Committee "wrong" to *not* adopt the MS=20 uglification convention? I think not! Indeed, of the tsearch, tfind, tdelete, twalk, tdestroy functions under=20 discussion here, all but tdelete are defined by POSIX, with *exactly*=20 those simple names. None of these functions is provided by any MS API,=20 so, if you make them available, the MS purist will not be using them,=20 and therefore should not care how you name them. However, the porter=20 of a POSIX application will expect to call them by name, *exactly* as=20 specified by POSIX, and will not thank you for uglifying those names;=20 you will both increase his work load, and force him to uglify his own,=20 otherwise portable code, just to accommodate an irrelevant convention=20 you've "borrowed" from Microsnot. If you do insist on these uglified=20 names, then you'd better also define aliases representing them by their=20 POSIX standard names, in an appropriate header file; congratulations:=20 you just *doubled* the pseudo-namespace pollution you set out to avoid. Regards, Keith. |
|
From: Greg C. <chi...@co...> - 2007-06-16 04:03:55
|
On 2007-06-16 02:06Z, Keith Marshall wrote:
> On Friday 15 June 2007 20:19, Danny Smith wrote:
[Keith had asked:]
>>> But why uglify the names?
>> Because some people want ANSI standard.
>
> And we satisfy that by providing the core set of functions, each
> behaving *exactly* as specified, as required by whichever version of
> the ANSI Standard for which we wish to claim conformance. That alone
> is a necessary and sufficient condition of conformance. If we choose
> to provide additional functions, however we choose to name them, they
> have no bearing whatsoever on ANSI conformance.
Suppose they were guarded with __STRICT_ANSI__ instead?
Would that meet everyone's goals here?
Consider:
C:/tmp[0]$cat m_e.c
#include <math.h>
int M_E(int x) { return x; }
int main() { M_E(0); return 0; }
C:/tmp[0]$/MinGW-20061119/bin/gcc -ansi m_e.c
C:/tmp[0]$/MinGW-20061119/bin/gcc m_e.c
m_e.c:3: error: syntax error before numeric constant
m_e.c: In function `main':
m_e.c:5: error: called object is not a function
I think that's a "strictly conforming program" (C99 [4.5]),
which every "conforming hosted implementation" (C99 [4.6])
must accept.
And 'gcc -ansi' should be a "conforming hosted implementation",
as in the first compile command above. But 'gcc' without '-ansi'
needn't be, as in the second compile command.
Either guarding with __STRICT_ANSI__ or uglification with a
leading '_[_A-Z]' would preserve conformance, AIUI. Also, BTW,
AIUI, that kind of uglification isn't specific to one monopoly;
it's just a consequence of [7.1.3/1] and [4.6] footnote 3.
That footnote seems to be the crux of this matter.
In the M_E case above, somebody, probably a decade ago, just
happened to choose the __STRICT_ANSI__ method, but both
ways have advantages.
__STRICT_ANSI__ lets people call twalk() by its POSIX name.
Or use M_E by its X/Open name.
Uglification prevents polluting the namespace if whatever
header POSIX puts it in is included, but people define their
own function called twalk() that doesn't do what the POSIX
one does. I could have defined rwalk(), swalk()... without
knowing about POSIX. Once, I tried defining an enumeration
with the standard postal abbreviations of US states as
enumerators:
enum us_states
{AK // Alaska
...
,OK // Oklahoma
...
but some nonconforming implementation (not gcc) had defined
a non-uglified OK macro.
|
|
From: James S. <jam...@op...> - 2007-06-16 08:17:52
|
On Sat, 2007-06-16 at 03:06 +0100, Keith Marshall wrote: > Indeed, of the tsearch, tfind, tdelete, twalk, tdestroy functions under > discussion here, all but tdelete are defined by POSIX, with *exactly* > those simple names. None of these functions is provided by any MS API, > so, if you make them available, the MS purist will not be using them, > and therefore should not care how you name them. However, the porter > of a POSIX application will expect to call them by name, *exactly* as > specified by POSIX, and will not thank you for uglifying those names; > you will both increase his work load, and force him to uglify his own, > otherwise portable code, just to accommodate an irrelevant convention > you've "borrowed" from Microsnot. If you do insist on these uglified > names, then you'd better also define aliases representing them by their > POSIX standard names, in an appropriate header file; congratulations: > you just *doubled* the pseudo-namespace pollution you set out to avoid. I think Keith may have already suggested, why not just try compiling the tsearch.c source from glibc as a separate library as was done for the regex functions recently? They are all LGPL, so the license poop is not restrictive (i.e. you can distribute your own closed source app, and link to and provide a LGPL'd tsearch dll with it). Isn't this the sane thing to do? I'd be happy to try on Monday if there's any interest ;-) Regards, James. |
|
From: Ralf W. <Ral...@gm...> - 2007-06-16 08:42:50
|
Hello, * James Steward wrote on Sat, Jun 16, 2007 at 10:17:43AM CEST: > I think Keith may have already suggested, why not just try compiling the > tsearch.c source from glibc as a separate library as was done for the > regex functions recently? If gnulib is acceptable, its tsearch module can simply be used. <http://www.gnu.org/software/gnulib/MODULES.html#module=tsearch> Without also using Autoconf and Automake that won't be fun though. Cheers, Ralf |
|
From: Pedro A. <ped...@po...> - 2007-06-15 19:46:46
|
Hi, Keith Marshall wrote: > I'm generally in favour of providing any extensions which make the code > porters life easier. I wouldn't object to adding them to libmingwex.a, > if they are considered generally useful, and a majority of users are > happy to accept the increased download size for mingw-runtime. > I don't have a saying here, but, let me share experience: On the WinCE port of MinGW (where a lot more stuff is missing from MSFT's runtime compared to msvcrt.dll), I also prefer to add stuff to mingwex over having it done over and over again. I have one rule that I think is important - Only add stuff that doesn't maintain state. Since libmingex.a is a static lib, if the new code needs global vars, chances are, it will cause troubles when more than one image (exe/dll) in the same process uses it. In those cases, a separate lib is preferred. Then, the porter can choose to built it as static, dll, or import the sources into his project. > An alternative option would be to provide a separate contributed library > package, as we did recently for Tor Lillqvist's port of glibc regex. > Cheers, Pedro Alves |
