strange behavior with **double

[Charlie Gordon]

I think you really need to learn the basics of C.

HA HA HA. You made me laugh. Why did you say that ? Explain.

Array subscripting
in C works by converting the array to a pointer (to its first element)
and then adding the subscript and dereferencing.

I never use array because one day gcc ask me a cast because I was
assuming that an int[] is an int *, but for it no, it's two different
types.

QED

 

[Joachim Schmitz]

checkout the FAQs athttp://c-faq.com/, esp. Chapter 6

Very very strange.

//example
#include <stdio.h>
#include <stdlib.h>

void aff (int *a)
{
int i;
for (i = 0; i < 6; i++)
printf ("%d", a);
}

int main (void)
{
int a[6] = {1, 2, 3, 4, 5, 6};
aff (a);
return 0;
}

//end of example

Whether this code prints ``123456'' or nothing is implementation defined.

Is it? Because of the missing putchar('\n') or fflush(stdout)? Isn't the
latter implicitly done on return from main()?

Bye, Jojo

 

[Charlie Gordon]

checkout the FAQs athttp://c-faq.com/, esp. Chapter 6

Very very strange.

//example
#include <stdio.h>
#include <stdlib.h>

void aff (int *a)
{
int i;
for (i = 0; i < 6; i++)
printf ("%d", a);
}

int main (void)
{
int a[6] = {1, 2, 3, 4, 5, 6};
aff (a);
return 0;
}

//end of example

Whether this code prints ``123456'' or nothing is implementation defined.

Is it? Because of the missing putchar('\n') or fflush(stdout)? Isn't the
latter implicitly done on return from main()?

No, it is implementation defined whether the list line of output requires a
new-line or not (J.3.12)

 

[Richard Tobin]

No, it is implementation defined whether the list line of output requires
a new-line or not (J.3.12)

[/QUOTE]

Appendix J is not normative...

But each item in J.3.12 refers to a normative section, in this case
7.19.2, which says:

Whether the last line requires a terminating new-line character
is implementation defined.

It doesn't seem to say what happens if the implementation does require
one and you don't provide it: is the result implementation-defined or
undefined behaviour?

-- Richard

 

[Joachim Schmitz]

<[email protected]> a écrit dans le message de
(e-mail address removed)...
checkout the FAQs athttp://c-faq.com/, esp. Chapter 6

Very very strange.

//example
#include <stdio.h>
#include <stdlib.h>

void aff (int *a)
{
int i;
for (i = 0; i < 6; i++)
printf ("%d", a);
}

int main (void)
{
int a[6] = {1, 2, 3, 4, 5, 6};
aff (a);
return 0;
}

//end of example

Whether this code prints ``123456'' or nothing is implementation
defined.

Is it? Because of the missing putchar('\n') or fflush(stdout)? Isn't the
latter implicitly done on return from main()?

No, it is implementation defined whether the list line of output requires
a new-line or not (J.3.12)

Appendix J is not normative...

Bye, Jojo

 

[Joachim Schmitz]

<[email protected]> a écrit dans le message de
(e-mail address removed)...
checkout the FAQs athttp://c-faq.com/, esp. Chapter 6

Very very strange.

//example
#include <stdio.h>
#include <stdlib.h>

void aff (int *a)
{
int i;
for (i = 0; i < 6; i++)
printf ("%d", a);
}

int main (void)
{
int a[6] = {1, 2, 3, 4, 5, 6};
aff (a);
return 0;
}

//end of example

Whether this code prints ``123456'' or nothing is implementation
defined.
Is it? Because of the missing putchar('\n') or fflush(stdout)? Isn't the
latter implicitly done on return from main()?

No, it is implementation defined whether the list line of output requires
a new-line or not (J.3.12)

Appendix J is not normative...

5.1.2.2.3-1 says return from main is equivalent to calling exit()
7.20.4.3-4 states that exit() flushes buffers
7.19.5.2-2 states thet fflush() writes outstanding data

Bye, Jojo

 

[Joachim Schmitz]

Appendix J is not normative...

But each item in J.3.12 refers to a normative section, in this case
7.19.2, which says:

Whether the last line requires a terminating new-line character
is implementation defined.

It doesn't seem to say what happens if the implementation does require
one and you don't provide it: is the result implementation-defined or
undefined behaviour?[/QUOTE]
If it doesn't say, it must be undefined (assuming "not defined" ==
"undefined", which doesn't seem unreasonable, does it?)
But there's still some contradiction to what I wrote before about main(),
exit() and fflush()

Bye, Jojo

 

[Richard Tobin]

But there's still some contradiction to what I wrote before about main(),
exit() and fflush()

I don't think that's a contradiction. Certainly exiting flushes
output, but if an implementation can require that the output end with
a newline and you don't end with one, who knows what will happen?

I think the rule is for systems where files and devices are inherently
organised in lines (e.g. if the output is a card punch), rather than
being about buffering. Unfortunately the Rationale does not seem to
say anything about it.

-- Richard

 

[Flash Gordon]

Joachim Schmitz wrote, On 29/09/07 17:53:

If it doesn't say, it must be undefined (assuming "not defined" ==
"undefined", which doesn't seem unreasonable, does it?)

The standard explicitly states that if it does not define the behaviour
then it is "undefined behaviour". It also states that there is no
difference between behaviour undefined by omission of definition and
behaviour explicitly stated as undefined.

But there's still some contradiction to what I wrote before about main(),
exit() and fflush()

Just because the last line has been flushed does not mean that a newline
is not required. If the implementation says you are required to
terminate the last line with a newline and you don't, then regardless of
whether it is flushed, and even if you explicitly call fflush on it,
then the behaviour is undefined. The most likely result of the undefined
behaviour is a prompt overwriting (part of) the last line output.

 

[Chris Torek]

[regarding what happens if the final output "line" is not
terminated with a newline, e.g.:

#include <stdio.h>
int main(void) { fputs("oops", stdout); return 0; }

]

I don't think that's a contradiction. Certainly exiting flushes
output, but if an implementation can require that the output end with
a newline and you don't end with one, who knows what will happen?

I think the rule is for systems where files and devices are inherently
organised in lines (e.g. if the output is a card punch), rather than
being about buffering. Unfortunately the Rationale does not seem to
say anything about it.

It definitely has nothing to do with buffering, since you can
indeed insert a "manual" fflush(stdout) with no change in effect.

The problem can be seen without resorting to card punches, line
printers, and other mostly-obsolete devices, however. Simply find
an appropriate Unix-like system and set up your command interpreter
(shell) so that its prompt for input starts by printing a
carriage-return (without newline) and "erase to end of line" sequence
(ESC [ K in most modern terminal emulators). (Some shells do this
automatically, as part of their built-in input editing.)

If your program prints, e.g., "hello world", but omits a newline,
the output appears, then is immediately erased by the shell.

If you turn off input editing and/or use a different shell, you
might see:

hostname> ./foo
hello worldhostname>

for instance, but because the shell has overwritten the text, it
seems never to have been printed. If the shell's input editor
omits the clear-to-end-of-line step, you get:

hostname> ./foo
hostname> d

with the cursor sitting on top of the "d", which is the last letter
of "world", which -- in this example anyway -- did not get overwritten.