What is printed?

[DJ]

What is printed to the screen?

#include <stdio.h>

int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

[Giannis Papadopoulos]

DJ wrote:

What is printed to the screen?

#include <stdio.h>

int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

"Hello!"

However, where "Goodbye!" goes? Is this default behaviour?

--
one's freedom stops where other's begin

Giannis Papadopoulos
http://dop.users.uth.gr/
University of Thessaly
Computer & Communications Engineering dept.

[Alexei A. Frounze]

"DJ" <An********@comcast.net> wrote in message
news:SM********************@comcast.com...

What is printed to the screen?

#include <stdio.h>

int main(void)
{
printf("Hello!\n");
fclose(stdout);

I suppose just hi. What a pervert code anyway.

Alex

[Alexei A. Frounze]

"Giannis Papadopoulos" <ip******@inf.uth.gr> wrote in message
news:dc**********@volcano1.grnet.gr...
....

fclose(stdout);
printf("Goodbye!\n");

.... However, where "Goodbye!" goes? Is this default behaviour?

I'd expect default to be undefined. And the app may crash at either of those
two function calls.

Alex

[Walter Roberson]

In article <dc**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

DJ wrote:

What is printed to the screen?
#include <stdio.h>
int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

"Hello!" However, where "Goodbye!" goes? Is this default behaviour?

It doesn't go anywhere. The printf() will return an error
because the output file is closed.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[Emmanuel Delahaye]

Walter Roberson wrote on 31/07/05 :

In article <dc**********@volcano1.grnet.gr>,
Giannis Papadopoulos <ip******@inf.uth.gr> wrote:

DJ wrote:

What is printed to the screen?
#include <stdio.h>
int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

"Hello!"

However, where "Goodbye!" goes? Is this default behaviour?

It doesn't go anywhere. The printf() will return an error
because the output file is closed.

Well done

#include <stdio.h>

int main(void)
{
int ret = printf("Hello!\n");
fprintf(stderr, "ret = %d\n", ret);

fclose(stdout);

ret = printf("Goodbye!\n");

fprintf(stderr, "ret = %d\n", ret);
return 0;
}

gives :

Hello!
ret = 7
ret = -1

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

"Clearly your code does not meet the original spec."
"You are sentenced to 30 lashes with a wet noodle."
-- Jerry Coffin in a.l.c.c++

[Richard Tobin]

In article <mn***********************@YOURBRAnoos.fr>,
Emmanuel Delahaye <em***@YOURBRAnoos.fr> wrote:

#include <stdio.h>

int main(void)
{
int ret = printf("Hello!\n");
fprintf(stderr, "ret = %d\n", ret);

fclose(stdout);

ret = printf("Goodbye!\n");

fprintf(stderr, "ret = %d\n", ret);
return 0;
}

gives :

Hello!
ret = 7
ret = -1

Not necessarily. The result of using a FILE pointer after it has been
closed is undefined. Fprintf() may return -1, but equally the program
may crash. Consider an implementation that malloc()s all FILEs and
free()s them when they are closed.

-- Richard

[Chris Torek]

In article <SM********************@comcast.com>
DJ <An********@comcast.net> wrote:

#include <stdio.h>

int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

Your code has undefined behavior. You might as well use this:

% cat v.c
short main[] = {
0x4800,0x0005,0x7fe8,0x02a6,0x3860,0x0001,0x3c5f,0 x0000,
0x3882,0x002c,0x38a0,0x0006,0x3800,0x0004,0x4400,0 x0002,
0x6000,0x0000,0x3860,0x0000,0x3800,0x0001,0x4400,0 x0002,
0x6865,0x6c6c,0x6f0a
};
% cc -o v v.c
% ./v
hello
%

Yes, the above really works. No, not on the x86. Can you figure
out which machine(s) it works on?

What the heck, here is a big hint as to how I generated the above:

% cat u.s
.globl _main
_main:
bl 1f
1:
mflr r31
li r3,1
addis r2,r31,ha16(hello-1b)
la r4,lo16(hello-1b)(r2)
li r5,6
li r0,4
sc
nop
li r3,0
li r0,1
sc
hello:
.ascii "hello\12"
% as -o u.o u.s
% hexdump u.o
[snippage]

(There probably should be a second nop after the second sc, but it
seems to work without it. I am not as familiar with this architecture
as I am with the 386 and sparc; the code above is rather crude.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Kenneth Brody]

DJ wrote:

What is printed to the screen?

#include <stdio.h>

int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

Once the nasal demons smash the monitor, it doesn't really matter, does it?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Ravi Uday]

HI Chris,

I have no clue why you mentioned that (your solution)
for the OPs question !
Are you demonstrating an UB ?

Please elaborate on your program

- Ravi

Chris Torek wrote:

In article <SM********************@comcast.com>
DJ <An********@comcast.net> wrote:

#include <stdio.h>

int main(void)
{
printf("Hello!\n");
fclose(stdout);
printf("Goodbye!\n");
return 0;
}

Your code has undefined behavior. You might as well use this:

% cat v.c
short main[] = {
0x4800,0x0005,0x7fe8,0x02a6,0x3860,0x0001,0x3c5f,0 x0000,
0x3882,0x002c,0x38a0,0x0006,0x3800,0x0004,0x4400,0 x0002,
0x6000,0x0000,0x3860,0x0000,0x3800,0x0001,0x4400,0 x0002,
0x6865,0x6c6c,0x6f0a
};
% cc -o v v.c
% ./v
hello
%

Yes, the above really works. No, not on the x86. Can you figure
out which machine(s) it works on?

What the heck, here is a big hint as to how I generated the above:

% cat u.s
.globl _main
_main:
bl 1f
1:
mflr r31
li r3,1
addis r2,r31,ha16(hello-1b)
la r4,lo16(hello-1b)(r2)
li r5,6
li r0,4
sc
nop
li r3,0
li r0,1
sc
hello:
.ascii "hello\12"
% as -o u.o u.s
% hexdump u.o
[snippage]

(There probably should be a second nop after the second sc, but it
seems to work without it. I am not as familiar with this architecture
as I am with the 386 and sparc; the code above is rather crude.)

[Chris Torek]

[top-posting fixed]

Chris Torek wrote:

Your code has undefined behavior. You might as well use [a

program with "short main[] = { ... };"].

In article <1123139608.999384@sj-nntpcache-3>
Ravi Uday <ra******@gmail.com> wrote:I have no clue why you mentioned that (your solution)
for the OPs question !
Are you demonstrating an UB ?
Yes. The effect of undefined behavior is, well, undefined behavior.
The code I posted really does work ... on *some* systems. Similarly,
C code with undefined behavior -- like calling fclose(stdout) and
then calling printf() -- works on *some* systems, and fails on some.
Please elaborate on your program

The data inside the main[] array constitute machine instructions:
load up some registers, and make two system calls (SYS_write and
SYS_exit respectively). This particular operating system and
compiler pair do not place too great a distinction between code
and data, so as long as the main[] array is correctly aligned, it
works. (Making it "int main[]", and changing the data values,
would help avoid potential alignment problems.)

Again, the point is that "undefined behavior" does *not* mean "code
does not work". It also does *not* mean "code works OK". What
it means is "the C standard no longer tells you what the code
does." You must therefore look outside the standard.

Strictly conforming "standard C" code *always* works on *every*
"standard C" implementation (subject of course to things like
running out of memory in malloc(), for instance). Other code
*sometimes* works on *some* implementations. Which is better?
Well, that is a bit like asking whether a sailboat is better than
a motorboat -- it depends on whether you have fuel available and
need to get somewhere fast, too. There are tradeoffs in everything:
nonstandard code may achieve something that *cannot* be done with
standard code -- in which case, you have to use it -- or it might
run much faster, or be much easier to write. Or it may simply fail
to work in the places where it is needed, so that the standard code
would have been better, despite being longer or slower or harder.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.