atoi doesn't accept NULL argument

[Maurice]

Hello back:

Also I noticed that with version 5.5 "atoi" doesn't accept NULL argument
is there something equivalent that accept it??

Regards
Maurice

[Alan Bellingham]

"Maurice" <mori...@yahoo.fr> wrote:

>Also I noticed that with version 5.5 "atoi" doesn't accept NULL argument
>is there something equivalent that accept it??

If you're treating NULLs as actual strings, you will keep falling over
these problems.

It's fairly easy to write quick little wrappers though:

inline int my_atoi(char const* text)
{
return text ? atoi(text) : 0;
}

(Returning a valid value when handed an invalid string is not what I'd
normally recommend, but you seem to want to.)

Alan Bellingham
--
Team Browns
<url:http://www.borland.com/newsgroups/> Borland newsgroup descriptions
<url:http://www.borland.com/newsgroups/netiquette.html> netiquette

[Thomas Maeder [TeamB]]

"Maurice" <mori...@yahoo.fr> writes:

> Also I noticed that with version 5.5 "atoi" doesn't accept NULL
> argument is there something equivalent that accept it??

Testing for NULL before invoking functions that don't accept NULL
pointers (as Alan already wrote).

Also, note that atoi() is rarely a good choice, since strtol() offers
the same functionality plus error checking.

[Maurice]

"Alan Bellingham" <al...@episys.com> wrote in message
news:bis0s3lb0pems1kh5...@4ax.com...

Hi:

In fact, I'm moving my old programs to v5.5, atoi of v5.2 accept NULL
arguments. It's the case of typing a command line with optional parameters.
In some cases, I like that without parameters, the corresponding value was
0.

Thanks
Maurice

[Alan Bellingham]

"Maurice" <mori...@yahoo.fr> wrote:

>In fact, I'm moving my old programs to v5.5, atoi of v5.2 accept NULL
>arguments. It's the case of typing a command line with optional parameters.
>In some cases, I like that without parameters, the corresponding value was
>0.

According to the C++ Standard (the bible in these things), supplying
NULL to functions such as strlen(), strcpy(), atoi(), etc. etc. causes
undefined behaviour. Now, what undefined behaviour actually evinces
itself as is ... well, undefined. It *may* actually do something
sensible.

The problem is that there are absolutely no guarantees. Moving from one
compiler to another may bring totally different behaviour, because the
standard has said nothing about what should be happening.

The reason why passing NULL is a bad idea is due to the spirit of C. The
standard is usually written to give the implementers the best possible
chance of producing the fastest code. This means that, for example, it's
not required to check for NULL in atoi(). (It *can* do, and that would
appear to be what happens in 5.2). After all, if the user wants the
check, he can put it in. But if the user *knows* no NULL would ever be
passed, there would be no way of *taking out* an unnecessary check in
the library function. So the Standard says the library function need not
check, with the assumption that the user will add the check if wanted.

Alan Bellingham
--
Team Browns

ACCU Conference 2008: 2-5 April 2008 - Oxford, UK

[Ed Mulroy [TeamB]]

Your stated problems are that the functions supplied by the language fail to
provide features which their specifications say that they do not provide.

The most productive path is to write your code in a manner which does not
require that functions have a behavior that they are specified to not have.

As Mr Bellingham is saying, when designing a program it is incumbent upon
the programmer to work with the features and limitations of the items which
he is using.

. Ed

> Maurice wrote in message
> news:47c2...@newsgroups.borland.com...

[Maurice]

"Alan Bellingham" <al...@lspace.org> wrote in message
news:o475s3lrpoejtam3v...@4ax.com...

Totally convicted, Thank you

Maurice