Well then, I think I was doing things out of order. My dialog has all the pieces broken out so I performed the following steps:
Server::Initialize, wsa = 0
Client::Initialize, wsa = 0
Server::Listen, wsa = 0
Client::Connect wsa = 10035
Client::OnConnect() is called
Server::OnAccept() is called
Client::OnSend() is called
As noted earlier, I have all those methods defined but with no body and a breakpoint in each. Is this normal behavior? If so,...
Does Client::OnConnect() need to do anything?
Same for Server::OnAccept and Client::OnSend?
I am getting close. Next Step?
Thanks for your time
Edit again: I have this code in the function C_Server::Class_Accept() that is called via a button in the dialog.
Now I that I see C_Server::OnAccept() called, that code should be moved into the OnAccept method and executed automatically after the client connects. Then I would NOT have a manually called Accept() method in the server class.
There are numerous versions of the basic copy function, too many now. some of the new versions are declared safer because they incorporate a limiting count value. However, all the ones I have tried and inadvertenly tested just crash the application. I find that rather rude.
Are there any versions of ...cpy...() and ...printf...() that limit the count of characters copied to the space found in the destination string. Without an ungracefull app crash?
Are there any versions of ...cpy...() and ...printf...() that limit the count of
characters copied to the space found in the destination string.
Without an ungracefull app crash?
Unfortunately, No. Strcpy and printf are two of the most common functions that hackers use to exploit programming errors to "hack" into a program. When using these functions you need to pay extra attention to the size of your memory buffers and the actions you are performing on them.
You may have better luck with the C++ Standard Library.
The std::string class will manage your memory buffers, copies and concatenations.
std::cout doesn't have the program crash issues that you are running into.
In that case I wish to go on record as saying that we need a new set of these functions. These functions should be named ...strcpy_l(...) and ...printf_l(...), with the "l" (lower case L) standing for Limited. Under the covers, the function will examine the destination, determine the length of the destination, and quietly refuse to move more characters than the destination string can hold.
These will do what you are asking. Read the descriptions though, strncpy will not NULL terminate your string if it can't write all of the data to the buffer. This would open yourself up to another set of possibilities to crash your program.
I think both strncpy() and snprintf() sucks. Once I searched for hours for a bug that was caused by strncpy(). Here is the problem: strncpy() is suboptimal because even if you copy a 1 byte string, it fills the whole remaining part of the destination buffer with zeros unnecessarily, and on the other hand it doesn't zero terminate the string if its length equals to or bigger than the size of the dest buffer. The missing zero terminator character in similar cases is true for snprintf() too. I highly discourage everyone from using these functions.
Here is my opinion: strcpy is totally useless and totally unsafe. Use a string class in C++ and assign one string to another instead of strcpy. You can even implement refcounting if you write your own string class and then assignment will be super fast. You can of course use std::string for your needs.
If you write you own string class or if you extend your own string class from std::string then you can put in a format and vformat function (similarly to the MFC CString class) and you can do formatting so that the buffer size will be managed automatically for you. Here is an example to that: How to Format a String[^]. I would mention only one thing regarding this formatting function in the link: The use of the std::vector is unnecessary, you could put the string formatting directly to the string. even in that case the string resizing unnecessarily fills the whole string with a fill character before formatting the string into its buffer. With a custom string you can write more optimal code for this task.
The type safety of format parameters with the vararg nature of format functions is still endangering your program. Using the bad parameter types make your program crash at runtime when the formatting code gets executed. Example to a buggy formatting statement: format("Name: %s\n", 5). Gcc has an __attribute__ format printf to defend against such mistakes at compile time. You can mark you format function with this attribute and then gcc will catch such errors, it would find out for exmple that "%s" and 5 are not compatible. Unfortunately visual C++ doesn't have such feature but our current project is crossplatform so we compile it with both VC++ and gcc and this gcc feature is priceless.
Unfortunately this kind of formatting is too widespread and comfortable without similarly comfortable alternatives so this wont be dropped easily from C++. However a feature like the one gcc has can make this stuff quite usable and safe.
Environment: Windows 7, Visual Studio 2008, MFC, CPP
Goal: start with an int, and put the character string equivilant into a text format such that a static control variable from a dialog will accept it. mp_C_Client is a pointer to a class that contains the TCP/IP code. The error code is returned as expected.l
Note the _s on the end and the L prefixing the "%d"
This nonsense with all the different character types is way out of hand. After I get over this hurdle of writing some async TCP/IP code, I think I should re-create the project and get rid of all the multibyte and unicode nonsense.
Thanks for your time
Edit: The post was nicely formated in the preview, but looks bad after being submitted.
Unicode is the default compile type for Visual Studio projects.
If you would like to work in multi-byte only, you can change that property in your compiler settings on the General page.
The _stprintf_s function compiles using the character format based on that compiler setting.
If you don't want to mess with the compiler settings, you can use a char rather than a TCHAR, and the function sprintf_s,
or if you want to force the unicode type use the data type wchar_t, and the function wsprintf_s.
Note the _s on the end and the L prefixing the "%d"
The _s is a good thing as it helps to protect against buffer overflow, but less critical when you are sure that your buffer is big enough. The L prefix on your string is wrong, however, as you are using TCHAR so your buffer could be ASCII or Unicode. You should use the _T() macro around your strings, and the _countof() macro to specify the size thus:
I looked up _countof and discovered the return type is not declared anywhere. Is it an int, unsigned int, size_t, or something else?
The _countof function does not accomodate the null that belongs at the end of a character string. That is important because,...
The various versions of ...printf...( destination, count, source ) that I have tried appear to put a limiting number on the count of characters transferred. However, that limit takes the form of a program crash. Downright nasty! Just as bad as ASSERT.
IMNSHO, these functions should use the count argument to limit the number of characters being transfered rather than crashing the program. Do any of these "safe", or maybe "less dangerous" functions simply limit the number of character moves rather than crashing the app?
I looked up _countof and discovered the return type is not declared anywhere.
If you look closely you will see that it is a macro which invokes the sizeof() operator, so it returns the same type as that.
The various versions of ...printf.
The functions with the _s suffix and the buffer length parameter will avoid the crash by giving you an error return or ASSERT if you attempt to overwrite the buffer, so these functions should always be used for safety. The old "unsafe" versions are part of the base C libraries and remain for backwards compatibility. As you so rightly say, they should not be used any more.
You can trap any ASSERTs that may be raised by adding your own handler as described here[^].
It always pays to read the documentation (including any linked pages) thoroughly. Not that I do so very often.
One of these days I'm going to think of a really clever signature.
dose any one know how to mirror system image list , iam developing RTL application on LTR windows xp , so i want to mirror image before setting listctrl so it will not look upside down ,
her what i did so far and i failed :
I am good through the point where the server calls the Listen() method. There is no client at this time and the code paused for a second or so then continues. My server class has the base class: CAsyncSocket so I presume the OS will eventually send a notification as to when a client connects. What part of the code says to the OS, when the client connects, call function X?
The next operation is to call the Accept( ) method. Under topic Accepting Connections Wilson suddenly uses m_sConnected as the argument to Accept without explanation. Looking at the downloaded code I think this is an instance of his class MyEchoSocket. But all he does with that class is call methods from the base class CAsyncSocket. Why not just call the CAsyncSocket methods directly?
Edit: The link did not work for me. Try again. I think it is Ok now.
Edit 14 Sep 2012
I think I am beginning to understand.
For question 1:
The programmer must override a set of methods from the base class. These include OnAccept(), OnConnect(), OnReceive(), etc. Windows calls these methods when the event has happened.
For question 2:
When the server code runs, it initiates a listen activity, Windows is listening for a client to connect. When one does, skipping some stuff, an instance of the class written to handle the traffic is created and put into action. That would be an instance of the MyEchoSocket. That class then performs all the sends and receives with the client. Meanwhile, the original server object is fee to go back to listening for another client connect.
No one has posted a reply and this is what I think is supposed to happen. I am still working my code. Please jump in if you have any corrections or comments.
The call to Listen is opening a socket for your server and it basically says "I'm interested in new requests..."
All that is happening at this point is some state has been setup.
The call to accept is actually where the connection is made. The variable m_sConnected is the variable that will receive the new connected socket. Notice how the rest of the calls made if Accept() succeeds are performed on m_sConnected.
In the meantime, m_sListener is still there ready to accept more connections. So if you start another client and then call Accept() with another socket variable, you would have two active client sessions in your application.