Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Is the behaviour defined

Reply
Thread Tools

Is the behaviour defined

 
 
SM Ryan
Guest
Posts: n/a
 
      10-01-2005
# 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.
 
Reply With Quote
 
 
 
 
Joe Wright
Guest
Posts: n/a
 
      10-01-2005
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 ---
 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      10-02-2005
In article <QKw%e.3$(E-Mail Removed)> grid <(E-Mail Removed)> 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 (4039.22'N, 11150.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.
 
Reply With Quote
 
SM Ryan
Guest
Posts: n/a
 
      10-02-2005
Joe Wright <(E-Mail Removed)> 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.
 
Reply With Quote
 
Joe Wright
Guest
Posts: n/a
 
      10-02-2005
SM Ryan wrote:
> Joe Wright <(E-Mail Removed)> 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 ---
 
Reply With Quote
 
Joe Wright
Guest
Posts: n/a
 
      10-02-2005
Chris Torek wrote:
> In article <QKw%e.3$(E-Mail Removed)> grid <(E-Mail Removed)> 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 ---
 
Reply With Quote
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-02-2005
"Joe Wright" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
....
> 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


 
Reply With Quote
 
Kenny McCormack
Guest
Posts: n/a
 
      10-02-2005
In article <(E-Mail Removed)>,
Joe Wright <(E-Mail Removed)> 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")

 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      10-03-2005
In article <(E-Mail Removed)>
Joe Wright <(E-Mail Removed)> 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 (4039.22'N, 11150.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.
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      10-03-2005
Chris Torek wrote:
> grid <(E-Mail Removed)> 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.

 
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: __STDC_IEC_559__ (defined or !defined ?) Keith Thompson C Programming 0 08-17-2010 04:36 PM
User-defined exception: "global name 'TestRunError' is not defined" jmike@alum.mit.edu Python 1 07-10-2008 12:37 PM
defined? for recursive function call v/s defined? for function call stack Alok Ruby 3 04-13-2006 11:53 AM
Using parenthesis with defined (#if defined(...)) Angel Tsankov C++ 1 04-05-2006 10:00 PM
#if (defined(__STDC__) && !defined(NO_PROTOTYPE)) || defined(__cplusplus) Oodini C Programming 1 09-27-2005 07:58 PM



Advertisments