atoi

[Nezhate]

Hi all,
Can you help me? Why this warning appears in the next simple code ?
warning: passing argument 1 of ‘atoi’ makes pointer from integer
without a cast.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int i;
char line[100];

int main ()
{
printf("Enter line:\n");
fgets(line,sizeof(line),stdin);
line[strlen(line)-1]='\0';
for (i=0;i<strlen(line);i++)
{
printf("line[%d]=%d\n",i,atoi(line[i]));
}
exit(0);
}

when excuting:
$ ./test
Enter line:
this is a test
Segmentation fault

[Richard Heathfield]

Nezhate said:

Hi all,
Can you help me? Why this warning appears in the next simple code ?
warning: passing argument 1 of ?atoi? makes pointer from integer
without a cast.

That's because you're passing atoi a char (which is a kind of integer)
rather than a string (which is passed as a pointer).

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int i;
char line[100];

Make these local.

int main ()
{
printf("Enter line:\n");
fgets(line,sizeof(line),stdin);
line[strlen(line)-1]='\0';
for (i=0;i<strlen(line);i++)
{
printf("line[%d]=%d\n",i,atoi(line[i]));
}

I *think* you're trying to do this:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main ()
{
size_t i = 0;
char line[100] = {0};
size_t len = 0;

printf("Enter line (no more than 98 characters):\n");
if(fgets(line,sizeof(line),stdin) != NULL)
{
len = strlen(line);
line[len - 1]='\0';
for (i = 0; i < len; i++)
{
printf("line[%d]=%d\n", (int)i, atoi(line + i));
}
}
return 0;
}

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Nezhate wrote:

Hi all,
Can you help me? Why this warning appears in the next simple code ?
warning: passing argument 1 of ?atoi? makes pointer from integer
without a cast.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int i;
char line[100];

int main ()
{
printf("Enter line:\n");
fgets(line,sizeof(line),stdin);
line[strlen(line)-1]='\0';

This is not needed. Fgets will always terminate the input with a null
character.

for (i=0;i<strlen(line);i++)
{
printf("line[%d]=%d\n",i,atoi(line[i]));

The function atoi expects a char * parameter. Here you are passing it
char objects which are really just integers in C. That's what your
compiler is complaining about.

}
exit(0);
}

when excuting:
$ ./test
Enter line:
this is a test
Segmentation fault

I think you may want something like this:

#include <stdio.h>
#include <stdlib.h>
#define LINE_SIZE 16

int main(void) {
char input[LINE_SIZE];
int val;

puts("Enter an integer:");
if (fgets(input, sizeof input, stdin) == NULL) exit(EXIT_FAILURE);
val = atoi(input);
printf("You entered: %s\nAtoi returned: %d\n", input, val);
return 0;
}

But be aware that atoi provides no error detection or recovery. If you
pass it wrong or out-of-range numeric strings, it will merrily invoke
undefined behaviour. The strto* set of functions like strtol, strtoul,
etc., are much more robust. See your C library documentation for all
these functions.

[Richard Heathfield]

santosh said:

Nezhate wrote:

>Hi all,
Can you help me? Why this warning appears in the next simple code ?
warning: passing argument 1 of ?atoi? makes pointer from integer
without a cast.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int i;
char line[100];

int main ()
{
printf("Enter line:\n");
fgets(line,sizeof(line),stdin);
line[strlen(line)-1]='\0';

This is not needed. Fgets will always terminate the input with a null
character.

He's not terminating, santosh - he's wiping the newline character. If he
were terminating, he wouldn't be using strlen!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Barry Schwarz]

On Thu, 24 Apr 2008 02:33:00 -0700 (PDT), Nezhate
<ma************@gmail.comwrote:

>Hi all,
Can you help me? Why this warning appears in the next simple code ?
warning: passing argument 1 of ‘atoi’ makes pointer from integer
without a cast.

This is one of the few diagnostics that really is self explanatory.
atoi requires that the argument be a pointer to char. Your argument
is line[i]. Since line is an array of char, line[i] is obviously one
of the char in the array. You should recognize that char is a
completely different thing than a pointer to char. They are not
interchangeable nor is there any implicit conversion between them.
Hence the compiler is obligated to tell you that your are calling atoi
with an illegal type.

>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int i;
char line[100];

int main ()
{
printf("Enter line:\n");
fgets(line,sizeof(line),stdin);
line[strlen(line)-1]='\0';
for (i=0;i<strlen(line);i++)
{
printf("line[%d]=%d\n",i,atoi(line[i]));

You appear to be printing out the elements of line one char at a time.
Go back to your reference and convince yourself that atoi is not the
function to convert an individual char to int. You should be able to
determine how atoi knows where to start looking for characters (yes
the plural is a hint) and how atoi knows when to stop looking.

Then ask yourself what, IF ANYTHING (that is another hint), you need
to do to line[i] so that printf can print it as an int.

}
exit(0);
}

when excuting:

Until you are a lot more experienced, it is a waste of time to execute
code that did not compile cleanly.

>$ ./test
Enter line:
this is a test
Segmentation fault

Believe it or not, this is one of the preferred manifestations of
undefined behavior.
Remove del for email

[Chris Dollin]

Keith Thompson wrote:

or maybe:

if (c>='0' && c<='9')

Or you could add "#include <ctype.h>" and use isdigit() here.

If not using `isdigit` I'd write it as

if ('0' <= c && c <= '9') ...

so that the two occurences of `c` were next to each other
(making it obvious that it's the same `c`).

It's a shame that C lost BCPL's

'0' <= c <= '9'

(also a shame that in at least one BCPL compiler the generated
code for this was buggy if `c` had side-effects).

--
"In vain I have struggled. It will not do." /Pride and Prejudice/

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[CBFalconer]

Keith Thompson wrote:

Nezhate <ma************@gmail.comwrites:

.... snip ...

>

>int char2int(char c) {
int num;
if ((c>='0')&&(c<='9'))

The extra parentheses really aren't necessary. The >= and <=
operators bind more tightly than &&. I'd write this with some
extra whitespace as:

if (c >= '0' && c <= '9')

I approve of the extra spaces, and also the extra parentheses.
They make the expression action completely understandable at first
glance.

Note that making a practice of separating all operators with blanks
avoids accidentally creating such things as a '+=' operator.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>Nezhate <ma************@gmail.comwrites:

... snip ...

>>

>>int char2int(char c) {
int num;
if ((c>='0')&&(c<='9'))

The extra parentheses really aren't necessary. The >= and <=
operators bind more tightly than &&. I'd write this with some
extra whitespace as:

if (c >= '0' && c <= '9')

I approve of the extra spaces, and also the extra parentheses.
They make the expression action completely understandable at first
glance.

So you prefer this?

if ((c >= '0') && (c <= '9'))

This is a matter of taste. I'm not going to disagree with you, but I
will say that my own taste differs. The fact that the relational
operators bind more tightly than "&&" seems to me to be sufficiently
obvious that the extra parentheses are IMHO unnecessary. Similarly, I
wouldn't use:

x = (y + z);

because it's even more obvious that "+" binds more tightly than "=".

Again, I'm not saying I disagree, merely that my own taste differs on
this point (and anyone *reading* C code needs to be able to deal with
either style).

Note that making a practice of separating all operators with blanks
avoids accidentally creating such things as a '+=' operator.

How would that happen? I don't believe there's any context in which
the tokens "+" and "=" can be adjacent in a legal program. (In early
pre-K&R C, the "-=" token was spelled "=-", which meant that "x=-1"
would decrement x rather than assigning the value -1 to it; it was
changed to "=-" for exactly this reason.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

.... snip ...

>

>Note that making a practice of separating all operators with blanks
avoids accidentally creating such things as a '+=' operator.

How would that happen? I don't believe there's any context in which
the tokens "+" and "=" can be adjacent in a legal program. (In early
pre-K&R C, the "-=" token was spelled "=-", which meant that "x=-1"
would decrement x rather than assigning the value -1 to it; it was
changed to "=-" for exactly this reason.)

It can turn faulty code into error-free (according to compiler)
code. Another nuisance area is code using ++ and --.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

... snip ...

>>

>>Note that making a practice of separating all operators with blanks
avoids accidentally creating such things as a '+=' operator.

How would that happen? I don't believe there's any context in which
the tokens "+" and "=" can be adjacent in a legal program. (In early
pre-K&R C, the "-=" token was spelled "=-", which meant that "x=-1"
would decrement x rather than assigning the value -1 to it; it was
changed to "=-" for exactly this reason.)

It can turn faulty code into error-free (according to compiler)
code.

Um, how? How can leaving out blanks accidentally create a "+="
operator? Can you provide an example?

Another nuisance area is code using ++ and --.

How so?

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 27 Apr 2008 03:47:39 -0700, Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>Keith Thompson wrote:

>>CBFalconer <cb********@yahoo.comwrites:

... snip ...

>>>
Note that making a practice of separating all operators with blanks
avoids accidentally creating such things as a '+=' operator.

How would that happen? I don't believe there's any context in which
the tokens "+" and "=" can be adjacent in a legal program. (In early
pre-K&R C, the "-=" token was spelled "=-", which meant that "x=-1"
would decrement x rather than assigning the value -1 to it; it was
changed to "=-" for exactly this reason.)

It can turn faulty code into error-free (according to compiler) code.

Um, how? How can leaving out blanks accidentally create a "+="
operator? Can you provide an example?

If you want to write

*p++ = 3;

and you accidentally write

*p+ = 3;

the compiler will complain.

If you want to write

*p++=3;

and you accidentally write

*p+=3;

the compiler won't complain.

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

.... snip ...

>

>It can turn faulty code into error-free (according to compiler)
code.

Um, how? How can leaving out blanks accidentally create a "+="
operator? Can you provide an example?

a + = b; /* invalid */
becomes: a+=b; /* valid */

>

>Another nuisance area is code using ++ and --.

How so?

a = b++ + ++c; /* valid */
becomes: a=b+++++c; /* invalid */

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **