Subject Re: Interserver Win32 Development
Author ft@cluedup.com
Thanks Mark, sorry about the delay responding, I'm still tied up with
other work but here is some clarification for now:

>Im also curious about getting the outofmemory exception with
PreparedStatement. Do you have a simple test case that reproduce the
problem? Im using CallableStatements and seem to get a slow memory
leak, but Im not sure if the problem is on the client or server side.
So Im interested in your problem.

fred:

The code involved lists the tables, finds the primary and
foreign keys in them, and constructs select queries with each of
those as parameter, also some other queries. When it gets to
PrepareStatement the error occurs.

As this was specific to the bcc5.5 version, I'll leave it until I can
test with a VC++ compiled build of the the same (updated by David)
code. Ken has kindly sent me his build results and I will report once
I've compared the two.


>1>) --------------------------------
In Error.cpp, I was wonderinf if this should be under a BCC guard,
since perhaps they are required for the MSVC compilation.

+//fredt@u...
+// commented out as declarations exist in stdlib.h (bcc32 v.5.5)
+// better include with ifdef where necessary
+//extern int sys_nerr; /* # of error message strings in sys
table */
+//extern char *sys_errlist[]; /* the system error message
table */
+//end fredt@u...

fred:

They may well be required for MSVC, I don't know.
They are defined in stdlib.h and errno.h. I have not checked the spec
to see whether they are ANSI defined values but isn't everything in
those files supposed to be required by ANSI C.

The original #ifndef linux .... #endif guard is a hack
we may as well get rid of. What is linux (which library)?

I suggest if they are not in VC++ headers, we use:

#ifdef defined(_MSC_VER) && defined(_WIN32)

and add other platforms if necessary when they are targetted.

>2)-----------------------------------------------

In NetTCP.cpp I also wasn't sure about the following.
I haven't looked too far on these, but they just looked like there may
potentially be a problem. socklen_t should have been defined by
including sys/socket.h. So Iwasn't quite sure where we are leading
with the following but In (mandrake 7.2) its the same as redhat 7.0.

+// fredt@u... changed socklen_t type to int
//david jencks 1-19-2001 begin
// int clilen, on;
#ifndef socklen_t //problem on ms compiler
-#define socklen_t size_t //problem on rhlinux 7, socklen_t is uint,
size_t is int
+#define socklen_t int //problem on rhlinux 7, socklen_t is uint,
size_t is int
#endif


fredt:

All socklen_t is used for is in the call to accept() further down.
this is the winsock.h version:

SOCKET PASCAL FAR accept (
IN SOCKET s,
OUT struct sockaddr FAR *addr,
IN OUT int FAR *addrlen);

I think the best solution is to start with David's #define and
later cast &clilen when it's used as argument to whatever type addrlen
might be on the system.