Regarding standared i/o functions

[venkat]

Hi,

i have a program like

main()
{
char a[10]= " hello";
printf("%s", a);
fork();
}

which prints twice. i have similar program ,

main()
{
char a[10]= " hello";
write(1, a , sizeof a);
fork();
}


which will print only once. I am not sure whether it belongs to C or
Unix. How does the printf(buffered) works over write(unbuffer). Please
also refer pointers to it if any?

Thanks,
Vikas.

 

[Keith Thompson]

i have a program like

main()
{
char a[10]= " hello";
printf("%s", a);
fork();
}

which prints twice. i have similar program ,

main()
{
char a[10]= " hello";
write(1, a , sizeof a);
fork();
}


which will print only once. I am not sure whether it belongs to C or
Unix. How does the printf(buffered) works over write(unbuffer). Please
also refer pointers to it if any?

Both fork() and write() are defined by POSIX, not by C. Try
comp.unix.programmer.

 

[Richard Bos]

main()
{
char a[10]= " hello";
write(1, a , sizeof a);
fork();
}

which will print only once. I am not sure whether it belongs to C or
Unix.

I am. Both write() and fork() belong to Unix. Or to M$ Windows. Or to
some other OS. And they may behave differently in all of those, so you
need to ask this question in an OS-specific newsgroup - for Unix, start
in comp.unix.programmer.
(Oh, and write int main(void), and return 0; from main().)

Richard

 

[Army1987]

Hi,

i have a program like

main()
{
char a[10]= " hello";
printf("%s", a);
fork();
}

which prints twice. i have similar program ,

stdout is typically line-buffered, so the output won't be actually written
until a '\n' is printed, the buffer is full, or the stream is flushed with
fflush(stdout). Returning from (or falling off of) [1] main calls exit(),
which in turn flushes all the output streams.
<ot>Of course, if meanwhile you fork, that flushing will occur in both
processes.</ot>
In general, it is better to terminate the output with a newline, an
implementation needn't even support text files (including stdout) ending
with a partial line. Try to modify the program above with printf("%s\n",
a), or adding fflush(stdout); after the printf call. Check the difference
when when fflush is called before or after fork.

[1] In C99 falling off of main() is equivalent to returning 0, but in C99
you need to explicitly specify the return type of main. In C89 falling off
is... well... it calls exit with an indeterminate value, doesn't it? But
indeterminate values always cause UB in C89, right? So practically all
programs in K&R2 which fall off of main have UB, right? Er... I'm a little
confused...

main()
{
char a[10]= " hello";
write(1, a , sizeof a);
fork();
}


which will print only once. I am not sure whether it belongs to C or
Unix. How does the printf(buffered) works over write(unbuffer). Please
also refer pointers to it if any?

<ot>write doesn't use the stdio library, so the above doesn't apply.</ot>
BTW (that also applies to fwrite(a, 1, sizeof a, stdout)): sizeof a is the
size of the array, i.e. 10. You're printing four null characters after the
'o'. Use strlen(a), or remember the size (e.g. #define A_LEN 6), or, for
string literals, use sizeof a - 1.

 

[David Thompson]

On Sat, 29 Dec 2007 10:52:17 +0000 (UTC), Army1987

[1] In C99 falling off of main() is equivalent to returning 0,

Yes. (For the initial invocation of main, on a hosted implementation.)

but in C99 > you need to explicitly specify the return type of main.

In C89 falling off
is... well... it calls exit with an indeterminate value, doesn't it? But
indeterminate values always cause UB in C89, right? So practically all
programs in K&R2 which fall off of main have UB, right? Er... I'm a little
confused...

Not quite. Falling off and returning to _a C caller_ which uses the
indeterminate value is UB. But the runtime isn't necessarily in C, and
in fact this part probably isn't. Instead there's a specific statement
in 5.1.2.2.3 that 'the termination status ... is undefined' -- so the
program does terminate. What happens in the environment after, and as
a result of, ANY termination is outside the scope of the C standard.

The formerly-popular cautionary example, now fading into the mists of
history*, was VMS where nearly any 32-bit exit status of a program run
under the (usual) command interpreter could be and was interpreted to
have some meaning -- often resulting in the display of spurious and
alarming error messages such as 'tape dismount failure' or maybe even
'fire suppression system activated'.

(* Yes I know some folks still use OVMS. Not many.)

- formerly david.thompson1 || achar(64) || worldnet.att.net