Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > puzzling error

Reply
Thread Tools

puzzling error

 
 
Bill Cunningham
Guest
Posts: n/a
 
      05-05-2011
I am not quite sure what is going on here but this is my tested and
compiled code. As written below at compile time I get this warning.

p.c: In function `main':
p.c:9: warning: assignment makes pointer from integer without a cast

I don't see the int in this code.

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

int main(void)
{
char p[] = "hello to all";
char *a;
printf("%s\n", p);
printf("%s\n", a = strfry(p)); //error on this line.
return 0;
}

strfry() is a GNU extension. It takes a char* as is sole argument and
returns a char*. Now if I change that char p[] to a char *p I get a
segmentation fault. What's up with that?

Bill


 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      05-05-2011
"Bill Cunningham" <(E-Mail Removed)> writes:

> I am not quite sure what is going on here but this is my tested and
> compiled code. As written below at compile time I get this warning.
>
> p.c: In function `main':
> p.c:9: warning: assignment makes pointer from integer without a cast
>
> I don't see the int in this code.
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char p[] = "hello to all";
> char *a;
> printf("%s\n", p);
> printf("%s\n", a = strfry(p)); //error on this line.
> return 0;
> }
>
> strfry() is a GNU extension. It takes a char* as is sole argument and
> returns a char*.


An undeclared function is assumed to return int. string.h is not
declaring strfry so the compiler assumes it returns an it and complains
when you assign the result to a char * variable.

The man page (or some other documentation) should tell you how to get
strfry declared properly. Adding -D_GNU_SOURCE to the compile line
works for me.

> Now if I change that char p[] to a char *p I get a
> segmentation fault. What's up with that?


p then points to the string rather than being an array initialised by
it. The content of strings can't be modified, so passing p to any
function that tried to alter its contents gives rise to undefined
behaviour. A segmentation fault is a Good Result for undefined
behaviour.

--
Ben.
 
Reply With Quote
 
 
 
 
Ike Naar
Guest
Posts: n/a
 
      05-05-2011
On 2011-05-05, Bill Cunningham <(E-Mail Removed)> wrote:
> I am not quite sure what is going on here but this is my tested and
> compiled code. As written below at compile time I get this warning.
>
> p.c: In function `main':
> p.c:9: warning: assignment makes pointer from integer without a cast
>
> I don't see the int in this code.
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char p[] = "hello to all";
> char *a;
> printf("%s\n", p);
> printf("%s\n", a = strfry(p)); //error on this line.
> return 0;
> }
>
> strfry() is a GNU extension. It takes a char* as is sole argument and
> returns a char*. Now if I change that char p[] to a char *p I get a
> segmentation fault. What's up with that?


Apparently not all versions of the GNU toolset provide the strfry() function.
If the function is not provided, the strfry(p) call in your program is
a call to an undefined function, and the compiler will assume int for the
return type. You then assign the (presumably int) returnvalue to char *a,
hence the warning about the pointer-from-integer conversion.
 
Reply With Quote
 
Marc Boyer
Guest
Posts: n/a
 
      05-05-2011
Le 05-05-2011, Bill Cunningham <(E-Mail Removed)> a écritÂ*:
> p.c: In function `main':
> p.c:9: warning: assignment makes pointer from integer without a cast
>
> I don't see the int in this code.
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char p[] = "hello to all";
> char *a;
> printf("%s\n", p);
> printf("%s\n", a = strfry(p)); //error on this line.
> return 0;
> }
>
> strfry() is a GNU extension. It takes a char* as is sole argument and
> returns a char*.


When I compile, I get also warning
warning: implicit declaration of function ‘strfry’
and when I read the man page, I see that you need to
define macro _GNU_SOURCE to use this function.

So, without _GNU_SOURCE, the function strfry is assumed
to return an int, and the expression
a = strfry(p)
puts an int into a char*.

> Now if I change that char p[] to a char *p I get a
> segmentation fault. What's up with that?


Because
char * p = "hello to all";
defines a pointer p on a *read only* string "hello to all",
and strfry tries to write into a read-only memory?

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot=130
 
Reply With Quote
 
August Karlstrom
Guest
Posts: n/a
 
      05-05-2011
On 2011-05-05 14:44, Bill Cunningham wrote:
> I am not quite sure what is going on here but this is my tested and
> compiled code. As written below at compile time I get this warning.
>
> p.c: In function `main':
> p.c:9: warning: assignment makes pointer from integer without a cast
>
> I don't see the int in this code.
>
> #include<stdio.h>
> #include<string.h>
>
> int main(void)
> {
> char p[] = "hello to all";
> char *a;
> printf("%s\n", p);
> printf("%s\n", a = strfry(p)); //error on this line.
> return 0;
> }
>
> strfry() is a GNU extension. It takes a char* as is sole argument and
> returns a char*. Now if I change that char p[] to a char *p I get a
> segmentation fault. What's up with that?


The clang compiler will give you a bit more information (even without
warnings enabled):

$ clang test.c
test.c:9:24: warning: implicit declaration of function 'strfry' is
invalid in
C99 [-Wimplicit-function-declaration]
printf("%s\n", a = strfry(p)); //error on this line.
^
test.c:9:22: warning: incompatible integer to pointer conversion
assigning to
'char *' from 'int'
printf("%s\n", a = strfry(p)); //error on this line.
^ ~~~~~~~~~
2 warnings generated.


/August

--
The competent programmer is fully aware of the limited size of his own
skull. He therefore approaches his task with full humility, and avoids
clever tricks like the plague. --Edsger Dijkstra
 
Reply With Quote
 
osmium
Guest
Posts: n/a
 
      05-05-2011
"Bill Cunningham" wrote:

> I am not quite sure what is going on here but this is my tested and
> compiled code. As written below at compile time I get this warning.
>
> p.c: In function `main':
> p.c:9: warning: assignment makes pointer from integer without a cast
>
> I don't see the int in this code.
>
> #include <stdio.h>
> #include <string.h>
>
> int main(void)
> {
> char p[] = "hello to all";
> char *a;
> printf("%s\n", p);
> printf("%s\n", a = strfry(p)); //error on this line.
> return 0;
> }
>
> strfry() is a GNU extension. It takes a char* as is sole argument and
> returns a char*. Now if I change that char p[] to a char *p I get a
> segmentation fault. What's up with that?


Do you think you have now mastered C and want to take on Unix as a
challenge? Or what?

This is the wrong newsgroup for Unix based questions.


 
Reply With Quote
 
Angel
Guest
Posts: n/a
 
      05-05-2011
On 2011-05-05, Bill Cunningham <(E-Mail Removed)> wrote:
>
> strfry() is a GNU extension. It takes a char* as is sole argument and
> returns a char*. Now if I change that char p[] to a char *p I get a
> segmentation fault. What's up with that?


RTFM, RTFF.

--
The perfected state of a spam server is a smoking crater.
- The Crater Corollary to Rule #4
 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      05-05-2011
osmium wrote:

> Do you think you have now mastered C and want to take on Unix as a
> challenge? Or what?
>
> This is the wrong newsgroup for Unix based questions.


This is a GNU function. GNUs Not Unix.

Bill


 
Reply With Quote
 
Bill Cunningham
Guest
Posts: n/a
 
      05-05-2011
Ike Naar wrote:

> Apparently not all versions of the GNU toolset provide the strfry()
> function. If the function is not provided, the strfry(p) call in your
> program is
> a call to an undefined function, and the compiler will assume int for
> the return type. You then assign the (presumably int) returnvalue to
> char *a, hence the warning about the pointer-from-integer conversion.


Ok but my implementation does support strfry and it does compile and
work. I just get that warning so the compiler must be smart enough to get it
right in the end.

Bill


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      05-05-2011
Ben Bacarisse <(E-Mail Removed)> writes:
> "Bill Cunningham" <(E-Mail Removed)> writes:
>> I am not quite sure what is going on here but this is my tested and
>> compiled code. As written below at compile time I get this warning.
>>
>> p.c: In function `main':
>> p.c:9: warning: assignment makes pointer from integer without a cast
>>
>> I don't see the int in this code.
>>
>> #include <stdio.h>
>> #include <string.h>
>>
>> int main(void)
>> {
>> char p[] = "hello to all";
>> char *a;
>> printf("%s\n", p);
>> printf("%s\n", a = strfry(p)); //error on this line.
>> return 0;
>> }
>>
>> strfry() is a GNU extension. It takes a char* as is sole argument and
>> returns a char*.

>
> An undeclared function is assumed to return int.


In C90. C99, dropped implicit int, so attempting to call an undeclared
function is a constraint violation.

"gcc -std=c99" gives:
c.c: In function 'main':
c.c:9:5: warning: implicit declaration of function 'strfry'
c.c:9:22: warning: assignment makes pointer from integer without a cast

(Yes, it's still following the C90 implicit int rule, but that's ok as
long as it always warns about constraint violations.)

> string.h is not
> declaring strfry so the compiler assumes it returns an it and complains
> when you assign the result to a char * variable.


Right.

> The man page (or some other documentation) should tell you how to get
> strfry declared properly. Adding -D_GNU_SOURCE to the compile line
> works for me.


In fact, the man page says:

#define _GNU_SOURCE
#include <string.h>

char *strfry(char *string);

where "#define _GNU_SOURCE" in the source is equivalent to
"-D_GNU_SOURCE" on the command line.

*Never* use a function you're not completely familiar with without
first reading the documentation.

>> Now if I change that char p[] to a char *p I get a
>> segmentation fault. What's up with that?

>
> p then points to the string rather than being an array initialised by
> it. The content of strings can't be modified, so passing p to any
> function that tried to alter its contents gives rise to undefined
> behaviour. A segmentation fault is a Good Result for undefined
> behaviour.


Correction: the contents of string *literals* can't be modified.

More precisely, the contents of the array (which exists at run
time) which is associated with a string literal (which exists
only in your program source file) can't be modified. Even more
precisely, "can't be modified" means that attempting to modify them
is undefined behavior; an implementation could permit modifications,
but it wouldn't be doing you any favors.

This is an odd corner case. It would have made more sense for
string literals to be "const", so the compiler would (usually)
warn you about attempts to modify them, but that would have broken
a lot of pre-ANSI C code. C++, with less concern about backward
compatibility, does make string literals "const".

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Puzzling error msg. Ian Kelly Python 0 12-03-2012 06:27 PM
Re: Puzzling error msg. Steven D'Aprano Python 0 12-03-2012 06:12 PM
Puzzling JNI error message Roedy Green Java 9 10-12-2008 12:31 AM
puzzling error from GCC 3.4.4 drn@nadler.com C++ 6 10-08-2007 01:39 PM
puzzling error in script that copies files before processing them Ted Perl Misc 0 07-12-2006 03:25 PM



Advertisments