469,927 Members | 1,799 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

Is the behaviour defined

Hi,
A collegue of mine is of the opinion that the behaviour of the
following program is defined,but I am a little apprehensive.

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

int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}

The program prints the same value "abc" on multiple platforms and I even
tried it with multiple compilers.I can make out that its trying to write
to the pointer address and so probably the max it can write is 3 bytes +
'\0'.But even if I try to copy more that 4 bytes it prints the whole
string without any crashes.

Changed line >> strcpy(c,"abcdefg");

Now I know that this behaviour is undefined(writing more than 4 bytes)
as the sizeof the pointer is 4 bytes(on the machine I tested on).

Can anyone comment if this is compliant code and is the behaviour
guaranteed.

Thanks
~
Nov 15 '05 #1
31 1238
> int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}

It should be return 0;
The spell of the return is wrong in the test program above.I did not
have it in my test program which I compiled , but added it while
composing this mail , of the fear of getting battered by the C language
purists ;).
Nov 15 '05 #2
grid wrote on 01/10/05 :
A collegue of mine is of the opinion that the behaviour of the following
program is defined,
At minimum, it's implementation-dependent. But the result of putting
any value in a pointer may have an undefined result (trap
representation). There is a possibility of undefined behaviour.
but I am a little apprehensive.
You can!
#include<stdio.h>
#include<string.h>

int main()
{
char *c;
c = &c;
Types are incompatible. (c is a char * and &c is a char**)
strcpy(c,"abc");
The result of the 'sizeof char* == sizeof "abc"' expression is
implementation-dependent.

You need a space of 4 bytes for "abc".

For example, on a x86 in real mode (16-bit) model small, pointers are
16-bit wide, which means 2 bytes on this machine. Too small for "abc"
puts(&c);
retun 0;
}


--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair
Nov 15 '05 #3
"grid" <pr******@gmail.com> wrote in message
news:QK************@news.oracle.com...
A collegue of mine is of the opinion that the behaviour of the
following program is defined,but I am a little apprehensive.

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

int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}


The above code is broken. You attempt to store 4 chars/bytes
(1+strlen("abc")==4) to the variable c, but you don't know whether c
(pointer to a char) is big enough to hold 4 chars/bytes. On some platforms
it can be 2 or even 1, hence you're risking to overwrite something else.
Tell your collegue first to learn C better before advising a code such as
the above.

Alex
Nov 15 '05 #4
>> char *c;
c = &c;

Types are incompatible. (c is a char * and &c is a char**)


That is just to make c point to the first byte of the string.We will
anyhow require a cast for this to silence the compiler, since they are
really incompatible types as you mentioned

c = (char *)&c;

Thanks,
~
Nov 15 '05 #5
grid wrote on 01/10/05 :
char *c;
c = &c;


Types are incompatible. (c is a char * and &c is a char**)


That is just to make c point to the first byte of the string.We will anyhow
require a cast for this to silence the compiler, since they are really
incompatible types as you mentioned

c = (char *)&c;


The result of the cast is implementation-dependent.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair
Nov 15 '05 #6
> The above code is broken. You attempt to store 4 chars/bytes
(1+strlen("abc")==4) to the variable c, but you don't know whether c
(pointer to a char) is big enough to hold 4 chars/bytes. On some platforms
it can be 2 or even 1, hence you're risking to overwrite something else.


I gave the example for my particular machine/hardware just to make it a
point that this might not be a portable code.But apart from that, is it
guaranteed to function as intended where the pointer sizes are 4 bytes
or more.

Also writing past 4 bytes on a machine with 4 byte pointers dosent seem
to affect,though I am aware that undefined behaviour can really be
anything and that could also mean that it dosent manifests itself at
all.But this kind of non-compliant behaviour probably compels people to
write non-portable code in the first place rather than any significant
gain in efficiancy.

Thanks
~
Nov 15 '05 #7
"grid" <pr******@gmail.com> wrote in message
news:Fj************@news.oracle.com...
The above code is broken. You attempt to store 4 chars/bytes
(1+strlen("abc")==4) to the variable c, but you don't know whether c
(pointer to a char) is big enough to hold 4 chars/bytes. On some platforms it can be 2 or even 1, hence you're risking to overwrite something else.
I gave the example for my particular machine/hardware just to make it a
point that this might not be a portable code.


It's not portable. It's portable around your machine's hard drive, but not
much further :) Or you should probably ask such portability and undefined
behavior questions at comp.lang.c.x86 or something like that :)
But apart from that, is it
guaranteed to function as intended where the pointer sizes are 4 bytes
or more.
I see no good reason for such code to exist at first place. Perhaps you
could tell me it, if there is.
It's much more easier and portable to declare a local 4-char array. If you
need to use that space either for a pointer or for an array of 4 chars (one
of them at a time), there's a union keyword for that.
Also writing past 4 bytes on a machine with 4 byte pointers dosent seem
to affect,though I am aware that undefined behaviour can really be
anything and that could also mean that it dosent manifests itself at
all.But this kind of non-compliant behaviour probably compels people to
write non-portable code in the first place rather than any significant
gain in efficiancy.


Unportable code is the result of not following the standard (usually not
knowning anything about it and not reading good books that were written with
the standard in mind or not paying attention to those important details) but
instead making own assumptions and relying on something that might or might
not be true. If there's a need for any hardware/CPU-specific code, the
proper way of doing it is to define the API and put portable code on one
side of it and that platform specific code on the other side and never move
a tiny bit of it to the portable part. Unportable code is mixing portable
things with non-portable. Often times those non-portable things are due to
writing say 4 when it must be sizeof(int) or sizeof(int*), improperly
aligning data, improperly calculating sizes of structures and offsets of
their members, reading/writing integers as bytes with big/little endian
problems, ignoring casting to long in multiplication of ints (ignoring the
fact that int and long aren't necessarily types of the same physical size),
etc. The thing is, many books don't mention many practical things and hence
the programmer must invent some way to them, often a quick and durty
non-portable hack.

Alex
Nov 15 '05 #8
grid <pr******@gmail.com> writes:
int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0; }

It should be return 0;
The spell of the return is wrong in the test program above.I did not
have it in my test program which I compiled , but added it while
composing this mail , of the fear of getting battered by the C
language purists ;).


This is why you should *always* copy-and-paste the actual code that
you fed to the compiler, rather than re-typing it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #9
Emmanuel Delahaye wrote:
grid wrote on 01/10/05 :
char *c;
c = &c;

Types are incompatible. (c is a char * and &c is a char**)


That is just to make c point to the first byte of the string.We will
anyhow require a cast for this to silence the compiler, since they are
really incompatible types as you mentioned

c = (char *)&c;


The result of the cast is implementation-dependent.


Surely it is defined as producing a pointer to the first byte of c? If
it was *not* (char*), (unsigned char*) or (signed char*) I would agree
with you.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Nov 15 '05 #10
# Now I know that this behaviour is undefined(writing more than 4 bytes)
# as the sizeof the pointer is 4 bytes(on the machine I tested on).

Pointers aren't always four bytes. What you're looking for is
sizeof c>=strlen(string)+1

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Death is the worry of the living. The dead, like myself,
only worry about decay and necrophiliacs.
Nov 15 '05 #11
grid wrote:
int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0; }


It should be return 0;
The spell of the return is wrong in the test program above.I did not
have it in my test program which I compiled , but added it while
composing this mail , of the fear of getting battered by the C language
purists ;).


Let me be the first to warn of impending doom. You define c an object of
type char*. For sake of argument, the compiler arbitrarily places c at
address 0100. Now you assign this address to c itself. If your warnings
are high enough, you will be told about this. c has type char* while &c
has type char**. The two are incompatible types.

Assuming you got away with the assingment 'c = &c;' your c doesn't point
to usable memory. With 'strcpy(c,"abc");' the Devil steps in, destroying
c and anything else the Devil chooses. You are toast.

Given the prototype in stdio.h as..

int puts(const char *);

What on earth do you think 'puts(&c);' will do?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #12
In article <QK************@news.oracle.com> grid <pr******@gmail.com> wrote:
A collegue of mine is of the opinion that the behaviour of the
following program is defined, but I am a little apprehensive.

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

int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}
This code does not even compile:

% strictcc t.c
t.c: In function `main':
t.c:7: error: assignment from incompatible pointer type
t.c:9: error: passing arg 1 of `puts' from incompatible pointer type
t.c:10: syntax error before `0'
%

Fixing the obvious typo (so that line 10 says "return" instead of
"retun") still gives two error messages and no executable.

Adding the two obvious casts gives a program that fails when run
on some machines -- the "return" does something very bad, since
the bytes beyond &c that were overwritten held the return stack
frame. (Amazingly enough, it *does* work on both the Data General
Eclipse and the Cray, with the casts.)
Can anyone comment if this is compliant code and is the behaviour
guaranteed.


Obviously the answer (to both questions) is "no".
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 15 '05 #13
Joe Wright <jw*****@comcast.net> wrote:
# grid wrote:
# >> int main()
# >> {
# >> char *c;
# >> c = &c;
# >> strcpy(c,"abc");
# >> puts(&c);
# >> retun 0; }

# Assuming you got away with the assingment 'c = &c;' your c doesn't point
# to usable memory. With 'strcpy(c,"abc");' the Devil steps in, destroying

It points to an n-char wide local variable, where n=sizeof c.

# c and anything else the Devil chooses. You are toast.

As long as you copy n-1 or fewer chars (+ null byte terminator),
the only possible risk is if a pointer value in memory, not a
register, can trap to some kind of representation error.

# What on earth do you think 'puts(&c);' will do?

If the pointer value is interpretable as a n-1 (or less)
character string, it would print that string.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
I have no idea what you just said.
I get that alot.
Nov 15 '05 #14
SM Ryan wrote:
Joe Wright <jw*****@comcast.net> wrote:
# grid wrote:
# >> int main()
# >> {
# >> char *c;
# >> c = &c;
# >> strcpy(c,"abc");
# >> puts(&c);
# >> retun 0; }

# Assuming you got away with the assingment 'c = &c;' your c doesn't point
# to usable memory. With 'strcpy(c,"abc");' the Devil steps in, destroying

It points to an n-char wide local variable, where n=sizeof c.

# c and anything else the Devil chooses. You are toast.

As long as you copy n-1 or fewer chars (+ null byte terminator),
the only possible risk is if a pointer value in memory, not a
register, can trap to some kind of representation error.

# What on earth do you think 'puts(&c);' will do?

If the pointer value is interpretable as a n-1 (or less)
character string, it would print that string.


#include <stdio.h>
#include <string.h>
int main(void) {
char *c;
c = &c;
strcpy(c, "abc");
puts(&c);
return 0;
}

smr.c: In function `main':
smr.c:5: warning: assignment from incompatible pointer type
smr.c:7: warning: passing arg 1 of `puts' from incompatible pointer type

I assume you get similar results. Even if it "works" this is not a
decent program.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #15
Chris Torek wrote:
In article <QK************@news.oracle.com> grid <pr******@gmail.com> wrote:
A collegue of mine is of the opinion that the behaviour of the
following program is defined, but I am a little apprehensive.

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

int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}

This code does not even compile:

% strictcc t.c
t.c: In function `main':
t.c:7: error: assignment from incompatible pointer type
t.c:9: error: passing arg 1 of `puts' from incompatible pointer type
t.c:10: syntax error before `0'
%

Fixing the obvious typo (so that line 10 says "return" instead of
"retun") still gives two error messages and no executable.

Adding the two obvious casts gives a program that fails when run
on some machines -- the "return" does something very bad, since
the bytes beyond &c that were overwritten held the return stack
frame. (Amazingly enough, it *does* work on both the Data General
Eclipse and the Cray, with the casts.)

Can anyone comment if this is compliant code and is the behaviour
guaranteed.

Obviously the answer (to both questions) is "no".


I use DJGPP and a batch file to invoke the compiler as..

@echo off
gcc -W -Wall -ansi -pedantic -s -O2 %1.c -o %1.exe -lm

I get the same complaints as you except they are warnings. And there is
an executable produced and it "works" in that it produces

abc

I'm not defending the program, I wonder why I get warnings and you get
errors.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #16
"Joe Wright" <jw*****@comcast.net> wrote in message
news:I7******************************@comcast.com. ..
....
I use DJGPP and a batch file to invoke the compiler as..

@echo off
gcc -W -Wall -ansi -pedantic -s -O2 %1.c -o %1.exe -lm .... I'm not defending the program, I wonder why I get warnings and you get
errors.


There is a command line switch telling the compiler to turn the warnings
into errors, either
-pedantic-errors
or
-Werror
or both will do that -- I've never tried.

Alex
Nov 15 '05 #17
In article <I7******************************@comcast.com>,
Joe Wright <jw*****@comcast.net> wrote:
....
I use DJGPP and a batch file to invoke the compiler as..

@echo off
gcc -W -Wall -ansi -pedantic -s -O2 %1.c -o %1.exe -lm

I get the same complaints as you except they are warnings. And there is
an executable produced and it "works" in that it produces

abc

I'm not defending the program, I wonder why I get warnings and you get
errors.


Obviously, because we don't know what's behind Chris's "strictcc" command.

(But I suspect it is an invocation of some C compiler that includes a cmd
line option akin to gcc's "-Werror")

Nov 15 '05 #18
In article <I7******************************@comcast.com>
Joe Wright <jw*****@comcast.net> wrote:
[Given a source file for which the C standards require "diagnostics"
and using DJGPP,] I get the same complaints as you except they are
warnings. And there is an executable produced ... I wonder why I
get warnings and you get errors.


I have a stricter compiler. (Or rather, essentially the same
compiler with some minor gimmicking.)

The C standards say that "a diagnostic" is required, after which
anything may happen. Using "strictcc" I get a diagnostic and no
executable. See also -Werror and/or -pedantic-errors.

(At work, I use both Diab and gcc, which produce somewhat different
sets of warnings. Some code I consider "just fine" produces warnings
with Diab but not with gcc, e.g.:

#define MIN(a, b) ((a) < (b) ? (a) : (b))
...
x = MIN(x, limit);

will draw a warning with Diab under some flags [I have not yet
attempted to determine which ones]. Hence I cannot *always* have
"all warnings treated as errors". It is nice to use "strictcc" or
equivalent for personal projects, though, where I control all
aspects of the project, not just the C source file in question.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 15 '05 #19
Chris Torek wrote:
grid <pr******@gmail.com> wrote:

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

int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}


This code does not even compile:
Adding the two obvious casts gives a program that fails when run
on some machines -- the "return" does something very bad, since
the bytes beyond &c that were overwritten held the return stack
frame.


How about the 'fixed' version:

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

int main(void)
{
if ( sizeof(char *) >= sizeof "abc" )
{
char *c;
c = (char *)&c;
strcpy(c,"abc");
puts(&c);
}
return 0;
}

I think this is always well-defined. It's legal to cast any
object's address to (char *) and that pointer must point to
the object's representation. It's legal to modify memory
that has been allocated by you. This code never actually
evaluates "c" after the strcpy, so the issue of a trap
representation doesn't arise.

Nov 15 '05 #20
Old Wolf wrote:
#include <stdio.h>
#include <string.h>

int main(void)
{
if ( sizeof(char *) >= sizeof "abc" )
{
char *c;
c = (char *)&c;
strcpy(c,"abc");
puts(&c);
Of course I meant:
puts( (char *)&c );
}
return 0;
}


Nov 15 '05 #21
"Old Wolf" <ol*****@inspire.net.nz> writes:
Old Wolf wrote:
#include <stdio.h>
#include <string.h>

int main(void)
{
if ( sizeof(char *) >= sizeof "abc" )
{
char *c;
c = (char *)&c;
strcpy(c,"abc");
puts(&c);
Of course I meant:
puts( (char *)&c );


Or just
puts(c);
}
return 0;
}


--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #22
Joe Wright (jw*****@comcast.net) wrote:
: grid wrote:
: >> int main()
: >> {
: >> char *c;
: >> c = &c;
: >> strcpy(c,"abc");
: >> puts(&c);
: >> retun 0; }
: >
: > It should be return 0;
: > The spell of the return is wrong in the test program above.I did not
: > have it in my test program which I compiled , but added it while
: > composing this mail , of the fear of getting battered by the C language
: > purists ;).

: Let me be the first to warn of impending doom. You define c an object of
: type char*. For sake of argument, the compiler arbitrarily places c at
: address 0100. Now you assign this address to c itself. If your warnings
: are high enough, you will be told about this. c has type char* while &c
: has type char**. The two are incompatible types.

: Assuming you got away with the assingment 'c = &c;' your c doesn't point
: to usable memory.
"c doesn't point to usable memory"

No, c is on the stack and so &c is pointing at one end of the free space
on the stack.

This sort of trick would be seen in code such as an operating system.
The idea is to get the current address of the top of the stack so as to
"malloc" yourself some memory from the stack without using a memory
manager. If you want to use C instead of assembler to manipulate what
goes on inside the computer then you may need to use that sort of trick,
just like when you point your C variables at hard coded video address or
port addresses, etc.

In this case though, the call to strcpy is very problematic because strcpy
will be using that same area of the stack for its call frame. So in the
above there is a possibility of corrupting the stack. I think exactly one
byte can be safely written since we don't know in general which direction
the stack grows, or the endianess of the pointer.

In assembler you would commonly do the equivalent to the above, (take the
address of the memory which is the stack), but you would then move the
stack pointer before using the memory.

That is exactly what the old malloc variant "alloca()" did, but I don't
recall seeing that call available in any modern system.

It certainly isn't good for any normal application to do this trickery.

$0.10

--

This programmer available for rent.
Nov 15 '05 #23

In article <43********@news.victoria.tc.ca>, yf***@vtn1.victoria.tc.ca (Malcolm Dew-Jones) writes:

No, c is on the stack and so &c is pointing at one end of the free space
on the stack.
&c points to the first byte of the contents of c. Nothing more is
guaranteed by the language.

The C language does not require a "stack" in this sense (a contiguous
area of memory from which automatic variables, and other things, can
be allocated). It requires some stack-equivalent mechanism to
support the function-call semantics, but that can be, for example,
chained activation records.

There need not be any "free space" adjacent to any automatic
variable, and the implementation certainly need not allow the program
access to it.
I think exactly one
byte can be safely written since we don't know in general which direction
the stack grows, or the endianess of the pointer.


There are conforming implementations where this is not true.

As Old Wolf noted, C guarantees that we can inspect and alter the
contents of the "c" variable using a character pointer. It does not
guarantee that we can do anything outside the extent of that object
using a pointer to it; in fact, any such access invokes undefined
behavior.

--
Michael Wojcik mi************@microfocus.com

Cooperation is just like two pagodas, one hardware and one software.
-- Wen Jiabao
Nov 15 '05 #24
Michael Wojcik (mw*****@newsguy.com) wrote:

: In article <43********@news.victoria.tc.ca>, yf***@vtn1.victoria.tc.ca (Malcolm Dew-Jones) writes:
: >
: > No, c is on the stack and so &c is pointing at one end of the free space
: > on the stack.

: &c points to the first byte of the contents of c. Nothing more is
: guaranteed by the language.

Well I agree, I didn't mean to imply that the language required what I
described, only that the idiom of taking the address of an auto variable
is not some thoughtless bug, but is a real technique used in situations
when the alternative might be assembler language or FORTH or such like.

Nov 15 '05 #25
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
Old Wolf wrote:
#include <stdio.h>
#include <string.h>

int main(void)
{
if ( sizeof(char *) >= sizeof "abc" )
{
char *c;
c = (char *)&c;
strcpy(c,"abc");
puts(&c);


Of course I meant:
puts( (char *)&c );

Or just
puts(c);

}
return 0;
}



No. puts(c); will probably segfault (it does here) because c is neither
an array nor a pointer. This seems to "work"..

#include <stdio.h>
#include <string.h>
int main(void) {
char *c;
c = (char*)&c;
strcpy(c, "abc");
puts((char*)&c);
return 0;
}

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #26
Joe Wright <jw*****@comcast.net> writes:
Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
Old Wolf wrote:

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

int main(void)
{
if ( sizeof(char *) >= sizeof "abc" )
{
char *c;
c = (char *)&c;
strcpy(c,"abc");
puts(&c);

Of course I meant:
puts( (char *)&c );

Or just
puts(c);
}
return 0;
}


No. puts(c); will probably segfault (it does here) because c is
neither an array nor a pointer. This seems to "work"..

#include <stdio.h>
#include <string.h>
int main(void) {
char *c;
c = (char*)&c;
strcpy(c, "abc");
puts((char*)&c);
return 0;
}


A quibble: Yes, c is a pointer object, since it's declared as
"char *c;". But you're right, it doesn't contain a valid pointer
value; it contains the bytes 'a', 'b', 'c', and '\0' (plus other
garbage if sizeof(char*)>4). I was thrown off by the fact that c
contains its own address; that doesn't imply that c and &c are the
same value. I should have tried my own code before posting it.

"puts((char*)&c);" is correct (or as correct as anything can be in a
silly program like this one). "puts(c);" is wrong; it attempts to
dereference a garbage pointer.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #27
Joe Wright wrote:

Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:
Old Wolf wrote: char *c;
c is neither an array nor a pointer.


c is a pointer to char.

--
pete
Nov 15 '05 #28
pete wrote:

Joe Wright wrote:

Keith Thompson wrote:
"Old Wolf" <ol*****@inspire.net.nz> writes:

>Old Wolf wrote: char *c;

c is neither an array nor a pointer.


c is a pointer to char.


.... with indeterminate value,

OK

--
pete
Nov 15 '05 #29
Le 01-10-2005, grid <pr******@gmail.com> a écrit*:
Hi,
A collegue of mine is of the opinion that the behaviour of the
following program is defined,but I am a little apprehensive.

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

int main()
{
char *c;
c = &c;
strcpy(c,"abc");
puts(&c);
retun 0;
}


As other have sayed, the two problems are the conversion
(char**) -> (char*) and the sizeof(char*).

Here is a well defined program:

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

int main(){
void* p= &p;
if ( strlen("abc") < sizeof(p) ){
memcpy(p, "abc", strlen("abc")+1 );
puts( (char*) p );
} else {
puts("Pointers too small");
}
return 0;
}

Marc Boyer
Nov 15 '05 #30
Marc Boyer wrote:
Here is a well defined program:

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

int main(){
void* p= &p;
if ( strlen("abc") < sizeof(p) ){
memcpy(p, "abc", strlen("abc")+1 );
puts( (char*) p );


It's not defined and these issues have
already been gone over in this thread.

p is an indeterminate pointer after the memcpy call.

Accessing the value of p at that point,
as the cast operator does, is undefined.

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

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

int main(void)
{
void *p = &p;

if (strlen("abc") < sizeof(p)) {
strcpy(p, "abc");
puts((char *)&p);
} else {
puts("Pointers too small");
}
return 0;
}

--
pete
Nov 15 '05 #31
Le 07-10-2005, pete <pf*****@mindspring.com> a écrit*:
Marc Boyer wrote:
Here is a well defined program:

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

int main(){
void* p= &p;
if ( strlen("abc") < sizeof(p) ){
memcpy(p, "abc", strlen("abc")+1 );
puts( (char*) p );
It's not defined and these issues have
already been gone over in this thread.

p is an indeterminate pointer after the memcpy call.


Yes, sorry. I ve not posted the right version.
Accessing the value of p at that point,
as the cast operator does, is undefined.
Of course.
#include <stdio.h>
#include <string.h>

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

int main(void)
{
void *p = &p;

if (strlen("abc") < sizeof(p)) {
strcpy(p, "abc");
puts((char *)&p);
} else {
puts("Pointers too small");
}
return 0;
}


Yes
--
À vélo, prendre une rue à contre-sens est moins dangeureux
que prendre un boulevard dans le sens légal. À qui la faute ?
Nov 15 '05 #32

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Joona I Palaste | last post: by
29 posts views Thread by Enrico `Trippo' Porreca | last post: by
13 posts views Thread by Chris Croughton | last post: by
8 posts views Thread by wkaras | last post: by
26 posts views Thread by Frederick Gotham | last post: by
285 posts views Thread by Sheth Raxit | last post: by
30 posts views Thread by Ioannis Vranos | last post: by
173 posts views Thread by Ron Ford | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.