Dear all,
Id like to provide you with very few examples to explain
what I was talking about:
These problems manifested themselves in the Win64 version
driver.c
void
NsWaitDriversShutdown(Ns_Time *toPtr)
{
Driver *drvPtr = firstDrvPtr;
int status = NS_OK;
On Aug 4, 2011, at 12:24 AM, Maurizio Martignano wrote:
inttrigger[2]; /* Wakeup trigger pipe. */ ß Why is
this an int when it was a SOCKET (any justification)
A Unix pipe is just a pair of file descriptors, and a file descriptor in Unix
is just an integer.
It's probably safer to define this as SOCKET, but windows.h says SOCKET is:
typedef u_int SOCKET;
And:
typedef unsigned intu_int;
Since Windows is LLP64 and most Unix-like systems are LP64, I don't
understand how AOLserver's defining trigger[2] as (int) is the problem
--
Dear Don,
I went back to my archives
This is the situation:
1. the code in CVS had always
int trigger[2];
2. I took the version 4.5.1 from the tar ball dated 2009-02-02 and I did the
change
SOCKET int trigger[2]; to make it work
3. then I recently took the Aolserver code from CVS Head
It is not a matter of understanding
It is a matter of testing
On Windows 64 int trigger[2] doesnt work whereas SOCKET trigger[2] does
work.
On top of that in several other places SOCKET has been used, so if for no
other reason, I suggest one of the code maintainers takes a proper walk on
On Win64, can you tell me what sizeof(SOCKET) and sizeof(int) are? Try
this simple program:
#include windows.h
#include winsock2.h
int main(int argc, char[] *argv)
{
printf(sizeof(SOCKET) = %d, sizeof(int) = %d\n,
sizeof(SOCKET), sizeof(int));
return 0;
}
I just learned
Dossy,
It is irrelevant...
Absolutely irrelevant..
With
int trigger[2]
static void
TriggerDriver(Driver *drvPtr)
{
if (send(drvPtr-trigger[1], , 1, 0) != 1) {
The send doesn't work and always returns error
With
SOCKET trigger[2];
It DOES Work...
Back to your question:
The
On Aug 4, 2011, at 7:20 AM, Maurizio Martignano wrote:
5. I have to disagree with your statement
A Unix pipe is just a pair of file descriptors, and a file descriptor in
Unix is just an integer.
Feel free to disagree with the official Linux documentation then:
Dear Don,
If you follow the last discussions even Dossy agrees that a SOCKET
is not an int on Windows 64
All of this depends on the week type system of C, were types with different
names, supposed to be used for different needs are considered equivalent is
their size is the same. If we
On Aug 4, 2011, at 9:55 AM, Maurizio Martignano wrote:
All of this depends on the week type system of C, were types with different
names, supposed to be used for different needs are considered equivalent is
their size is the same. If we had used Ada none of this would have had
happened:
Dossy Shiobara wrote:
It's probably safer to define this as SOCKET, but windows.h says
SOCKET is:
The source comment is misleading, because trigger is set up as a socket
pair, not as a pipe. Not sure why it's this way, but there it is. And
ns_sockpair is already prototyped as
Don
In Aolserver source code
95% of more of the times sockets are declared as SOCKET; the other times as
int.
This is an inconsistency and is a fact.
If you wanted to develop only for Unix why did you use SOCKET in some
occasions and int in some others?
The source code is inconsistent and it
Hi
It's a socket so it can be monitored by select and poll. It should be SOCKET, I
think it was in the past.
On windows lib-c file handles returned by _open aren't the same as sockets.
You can see this in the libc source Microsoft provides. They can't be
monitored with select. The
Maurizio,
I think we're all in agreement at this point. Could you put together a
patch?
-J
Maurizio Martignano wrote:
Don
In Aolserver source code
95% of more of the times sockets are declared as SOCKET; the other times as
int.
This is an inconsistency and is a fact.
If you wanted to
We are reasoning too much...
1. Compiling the code on Windows 64 made clear there's some inconsistency in
the code...
2. This inconsistence is on how sockets are declared: 95% and more of the times
as SOCKET and the rest of the times as int
3. On UNIX and WIN32 no problem cause SOCKET and int
Dear Rusty,
I started very politely, gently...
Stressing I was seeing that the code base was kind of separating, moving
away from Windows support... (I did see how SOCKETwere used).
Then I provided the examples
Then I stressed the int trigger[2];
Then I made it clear and I am
We are in violent agreement...
It was never my intention to raise the discussion to this level.
I just observed the code.
I may have used tones a bit too strong or too stressing...
I never used bad words...
I am going to provide a patch that will remove the inconsistencies I tried
to explain...
It
Hi all,
I'm implementing a minor enhancement to the adp parser to make null end
tags (aka empty elements or minimized tags) work. Or more simply, if
you have a registered adp tag where the end tag matches the opening tag,
then rather than
mytag name=value/mytag
you can simply write
mytag
Hi,
I'm looking at the code now -- definitely needs to be SOCKET in nsd.h. The
reason can be seen in ns_sockpair in fd/sock.c where the code for a socket pair
is done. It's just a wrapper around Unix socketpair() but has a bunch of extra
code to do the loopback-connect thing on Windows. The
Sounds good to me.
-Jim
On Aug 4, 2011, at 4:21 PM, Jeff Rogers wrote:
Hi all,
I'm implementing a minor enhancement to the adp parser to make null end tags
(aka empty elements or minimized tags) work. Or more simply, if you have a
registered adp tag where the end tag matches the
I am doing the scan and I am preparing the patch.
I will have also to do the testing as some of my customers do require the
Windows 64 version.
And I may offer to do this testing also in the future, non on a continuous
basis, but every now and then.
Ciao and thanks,
Maurizio
21 matches
Mail list logo
