atoi(), itoa() ... make system getting crash

[kempofighter]

I do not know why you said that these APIs are deprecated?

Thanks,
Nguyen

You could try a google search on the word deprecated.
http://en.wikipedia.org/wiki/Deprecation

My earlier suggestion was similar to something that John mentioned. There could be something wrong with the CString object itself or the memory. Creating your own temporary inside that function isn't going to change what the compiler is already doing for you during compilation. Sometimes the compiler will create temporary variables as a result of some operation or cast you have written. Creating intermediate variables may not help too much unless it is for debugging purposes. Sometimes having the intermediates is useful when stepping so that you can see that a conversion is actually working.

By the way, when you say that your software is crashing how is it crashing? Are you able to get anything useful out of the call stack? Is it crashing in debug mode or only release mode? I haven't seen you post any details about what you have done to try to debug the problem (other than changing the code, recompiling, and re-running). What tools do you have available for debugging?

[PeterNguyen]

You could try a google search on the word deprecated.
http://en.wikipedia.org/wiki/Deprecation


By the way, when you say that your software is crashing how is it crashing? Are you able to get anything useful out of the call stack? Is it crashing in debug mode or only release mode? I haven't seen you post any details about what you have done to try to debug the problem (other than changing the code, recompiling, and re-running). What tools do you have available for debugging?

Thanks you much. I have just go through the link you suggested, but it likely no proof that these APIs are deprecated. You mean that we should not use these APIs since they are deprecated? Instead that we should use some safer, more secure functions??? My system based on VSC++6.0 and running on Windows XP or Windows 2000. It suddenly get crashes by "Runtime Error". Yes, it happened on release mode!



Thanks,

Nguyen

[laserlight]

I have just go through the link you suggested, but it likely no proof that these APIs are deprecated. You mean that we should not use these APIs since they are deprecated?

Those functions from the C standard library are not deprecated. However, itoa() is non-standard, and may cause buffer overflow if you do not provide it with a destination string of sufficient length, while atoi(), atof() and atol() do not provide a way for you to check for errors in conversion.

[ckweius]

I do not know why you said that these APIs are deprecated?

Most CRT functions have corresponding more secure version with the '_s' suffix. To put it simple, deprecated functions will simply crash the application when errors (such as buffer overrun) occured.

However, newer CRT functions are not meant to fix security issues, but to catch and divert control to most appropriate error handler (rather than crashing).

[laserlight]

Most CRT functions have corresponding more secure version with the '_s' suffix. To put it simple, deprecated functions will simply crash the application when errors (such as buffer overrun) occured.

However, those functions are non-standard, at least for now. As such, the "deprecation" of the standard library functions is not technically deprecation, but discouragement by a certain family of compilers via compiler warnings which can be disabled.

[PeterNguyen]

I got your idea and suggestions. Your support was highly appreciated. Thanks all!

[PeterNguyen]

One more thing I'm confusing that is: These APIs e.g atoi, atof, strtod,.. etc only can covert ASCII string to number? If we use convert from Unicode to number, what is the problem?

Thanks,
Nguyen

[ckweius]

One more thing I'm confusing that is: These APIs e.g atoi, atof, strtod,.. etc only can covert ASCII string to number? If we use convert from Unicode to number, what is the problem?

To convert Unicode string to integer, use _wtoi().

[PeterNguyen]

Most CRT functions have corresponding more secure version with the '_s' suffix. To put it simple, deprecated functions will simply crash the application when errors (such as buffer overrun) occured.

However, newer CRT functions are not meant to fix security issues, but to catch and divert control to most appropriate error handler (rather than crashing).

'_s' suffix may be used only on .NET, but out system is based on VSC++6? Is there any more secure version can work on VSC++ to catch and divert control to most appropriate error handler (rather than crashing)

Thanks,
Nguyen

[Paul McKenzie]

'_s' suffix may be used only on .NET, but out system is based on VSC++6? Is there any more secure version can work on VSC++ to catch and divert control to most appropriate error handler (rather than crashing)

You'll have to write your own routines if you're (still) using VC 6.0.

Regards,

Paul McKenzie

[PeterNguyen]

It may be that the problem still exists with sprintf too, but the error is not 'fatal'. The errors associated with these sort of functions is usually the data being sent to them. Array overruns, non-terminated strings, double & int pointers being cast to each other and dereferenced can all cause weird and wonderful errors.

If you can, consider using the C++ streaming classes as they are typesafe and can reduce the chances of silly errors being introduced.

// itoa equivalent.
int value;
ostringstream oss;
oss << value;

string text_value(oss.str()); // text_value contains the string representation of value

// atoi equivalent.
int value;

istringstream iss("1234");
iss >>  value;

For atof replace the int by a float.

// sprintf equivalent
int i_value = 0;
double d_value = 1.2;

ostringstream oss;
oss << "The integer value is " << i_value << "\nThe double value is " << d_value << "\n";
 
string text(oss.str());

Hi all,

The link below show that STL std::string class causes crashes and memory corruption on multi-processor machines
http://support.microsoft.com/kb/813810

Could you have any suggestions?

Thanks,
Nguyen

[laserlight]

The link below show that STL std::string class causes crashes and memory corruption on multi-processor machines
http://support.microsoft.com/kb/813810

Could you have any suggestions?

The suggestions are given in the very article that you linked to:

• Upgrade to a newer version of MSVC, or,
• Use a replacement standard library implementation.