Re: [1/2OT] a buggy TCP client program

On Tue, 18 Dec 2007 09:20:53 +0100, RoS <Ros@xxxxxxxxx> wrote:

in windows xp
the problem is that if i have a tcp sever istalled in the port 1000 in
my computer, and "cli.exe" is the C program "client program" below and
type

cli 127.1.1.1 1000

connect of client fail with "WSAECONNREFUSED 10061"
don't understand why

there is someone expert in this there?
what is the answer?

then there is someone can point out some C program for the use api
"ReadFile" with an handle return by api "socket"?

thank you
----------------------------------------------------

#include <WINSOCK2.H>
#include <stdio.h>
#include <windows.h>
#include <winbase.h>
#include <wincon.h>

Only 1 out of 5 of these headers are standard C headers. The rest are
specific to Microsoft Windows. This newsgroup is about discussing
topics related to Standard C, and has nothing to do with
Windows-specific or any other OS-specific matters.

#define P printf
#define R return
#define F for
#define G goto
#define uns unsigned

These #defines are absolutely horrendous, to an exponential degree.

Think about it--anyone who reads your code and sees a use of these
#defines will immediately have to go back to these #defines to see
what they mean.

You, in your own mind, may have memorized that "P" means "printf" and
"F" means "for", but can you really expect that the readers of your
code can be trained to memorize these like you? I know I can't--and
won't.

And what was it that you think you really accomplished with these
#defines? These types of things belong in an obfuscation code contest,
not in real-world code.

[rest snipped because off-topicality]

--
jay
.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... but you can hardly blame the consequences on the Standard headers. ... to use strndup, it's personal matter between user and his C ...
    (comp.lang.c)
  • Re: Header Files and Interfaces Yet Again
    ... >> Standard, I will have to adjust my headers to match the implementation. ... I can use the declarations in the headers to compile my ... > I do not that much about compiler design as to asses whether this is ...
    (comp.lang.cpp)
  • Re: .h for standard headers
    ... The fundamental arrogance in the C++ Standard was thinking that ... It declares all names within namespace std. ... the world on notice that headers like will one day go ... a couple of libraries do meet these requirements. ...
    (comp.lang.cpp)