Re: Follow-up on patch to ser-tcp.c

Mark Kettenis
2005-04-06T07:41:23Z

Date: Tue, 05 Apr 2005 11:05:24 -0700
From: Mark Mitchell <mark@codesourcery.com>

Mark --

A while back, I posted a patch to change ser-tcp.c to support Windows, here:

http://sources.redhat.com/ml/gdb-patches/2005-03/msg00331.html

Apologies for not getting back to you.

You had some objections:

1. The configury change to link with -lws2_23 on Windows.

2. The use of #ifdef WINAPI.

3. The asymmetry I introduced by adding the "read_prim" member to
"struct serial" without a corresponding "write_prim" member.

4. Changes to support differences between BSD and Windows socket APIs.

5. Modifications to strerror.

I don't see a way around (1). The question is really not whether the
library is available; the question is whether we should use it. On
MinGW, we should; on Cygwin, we should not.

Not happy with it, but I suppose you're right. But please read on.

The impact of (2) can be mitigated by using __MINGW32__ instead of
WINAPI. That will avoid the defs.h change, and localize the changes to
the actual conditional code.

Actually I think the WINAPI thingy is more descriptive. In light of
the discussion above, I think there should be a single spot in
configure.ac where we decide whether we want to use the native Windows
API or the proper POSIX interfaces that Cygwin provides get used.
Some sort of "Windows but not Cygwin" would than add -lws2_23 and
define something like USE_WIN32API, and we'd use that define
everywhere where there is a choice between the native Windows API and
the proper POSIX interfaces.

In my local version of the patch, I've corrected (3); the symmetry is
now complete. I've also mitigated (4), in that I've determined that
send/recv should work fine on all targets. That means that we don't
need an #ifdef to decide whether to use "read" or "recv"; we can just
always use "recv", as that function is available both on Windows and
elsewhere.

Great! In this area we also have the ioctlsock v.s. ioctl issue. Is
it possible to keep using the proper POSIX interfaces in the code and
#define ioctl ioctlsock in the USE_WIN32API case instead of the other
way around? I think that makes it easier for non-Windows programmers
to understand the code.

I can drop (5) from the patch, and we can come back to that later.

That'd be a good idea. I get the feeling that errno values and
Windows OS errors are fundamentally different things. Perhaps the
best way to solve this would be to translate the Windows OS errors
into the appropriate errno value ate the appropriate place.

With the set of changes described here, would you be willing to consider
the patch again? If so, I will post the modified version.

Please do so.

Mark