On Thu, Nov 08, 2007 at 04:20:28PM -0500, Nick Mathewson <[EMAIL PROTECTED]>
wrote:
> Would it be possible to fix the warnings instead of disabling them?
I doubt it, the warnings are not valid.
> Compiler warnings can catch a lot of problems in C code, and disabling
> them makes me nervous.
I cna understand this use of warnings, but enabling them in production
builds/releases is an extremely bad idea: gcc (for which they are enabled
by default) gains and loses warnings at a very fast rate, so even if your
goal is to provide warning-safe code, users will still be scared by many
warnings just because they happen to use a different compiler version than
you.
Its much better to specifically enable the warnings you personally
subscribe to and then leave them enabeld at all times, as gcc rarely changes
the meaning of a warning much.
Also: -Wall just provides some subset of warnings, so if you find warnings
so useful, you would have to tell us why you don't enable more of them for
libevent, but only some of the warnings of gcc.
So think about why disabling them makes you nervous, when, in fact, you
don't enable all of them either. Obviously there is a selection effect, in
that you enable some warnings but not others and then code to that "arning
standard".
> I can try to write a patch some time, if you like.
You are free to try, but note that some of the warnings are caused by
compatibility features required for other c compilers, or could only be
avoided by making the code harder to understand and/or maintain, which I
think is not acceptable. And some are outright bogus.
> > win32.c is only accidentally included. libev uses its select backend and
> > file descriptors on windows too. This is an incompatibility I will not
> > address, as I think libev should use fds on all architectures (and the
> > typical way I see sockets being used for portable programs is using fds).
>
> Ah, I think we have a misunderstanding.
No, windows has fds too, you can use them or not use them. If you use raw
winsockets, you cannot use those fds as winsockets isn't compatible to any
posix standard, and there it is a problem (but you can always convetrt he
handles to fds).
> The "sockets" I'm talking about are kind of fd-like; they're not win32
> handles. In other words, with the current libevent, the following code
> works on win32 and on
1. It is using different interfaces. If you use an interface that works
with fds (which is very common under many windows environments) you are
out of luck.
2. This uses an undocumented "feature" of libevent in that it doesn't work
with fds on windows (even with socket fds) but expects operating system
handles, completely contrary to the documentation.
3. If the code works under windows, then its only accidentally: libevent
uses "int" (which is a signed 32 bit integer type under windows), while
socket handles are either "unsigned int" or "unsigned long long" (64
bit), neither value is fully compatible with the other (compilers are not
required to do "the right thing", in the case of 64 bit handles, they even
cannot do that). If you get an out-of-range socket handle the conversion to
the "int fd" used by libevent will destroy it.
As such, expecting OS handles instead of file descriptors under windows is:
a) against the documented interface which explicitly takes about file
descriptors (and using fds under windows will not work with libevent!).
b) is a bug w.r.t. the win32 API, where socket handle value ranges are generally
bigger than the usable range of an int (even on 32 bit this might bite you
as compilers get smarter).
I do not think it makes sense to codify bugs in an API, which is why I
think the only correct thing to do for libev is to stick to the same API on
all platforms.
The alternative would be:
a) to document that the APIs work different on windows vs. posix systems.
b) to change the interface definition to use a SOCKET and not an int.
c) to make the internal management more complex and slower on all platforms.
This is possible to implement, but I think the simpler solution to stick
to documentation and keep API compatibility accross platforms is better.
> you can't use fds with the windows networking code
I can, and so does anybody else (for example of a larger project that does
this, take activatestate perl which does this, or strawberry perl, both
windows distributions of perl which use fds).
> It's kind of a mess, actually. Unfortunately, if you want to do
> portable network programming on win32, it's about the best you can do.
Except the libevent way of doing things isn't even compatible with
diferent versions of windows, unless there is a guarentee that socket
handles always stay within the range of a signed int.
> Right; I'm not proposing that libev should accept Windows HANDLEs
> right now -- libevent sure doesn't.
It uses socket handles, which are windows handles, not fds.
> > Hmm, how does libevent handle that (I use the same confgiure etc. stuff as
> > libevent, and libevent also requires extra libraries such as -lrt).
>
> Through libtool, automake, and autoconf, I thought. I'm not really
> sure what went wrong here. :( I'll try to poke at it more next chance
> I get.
automake and autoconf do nothing here, but libtool might. I might have
forgotten -lm, but I only made very minor changes to the configure etc.
script and would be surprised if -lrt would be missing due to my changes
(which is entirely possible).
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
