strange behavior with **double

[iesvs]

I got a double ** (double **coef).
And gcc accept the syntax coef[i][j], it works.
I don't understand why. For me coef[i][j] is not correct because it's
a double ** and not type[][].
If someone could explain me that.

[Army1987]

On Thu, 27 Sep 2007 03:50:27 -0700, ie***@free.fr wrote:

I got a double ** (double **coef).
And gcc accept the syntax coef[i][j], it works.
I don't understand why. For me coef[i][j] is not correct because it's
a double ** and not type[][].
If someone could explain me that.

I don't understand, where do you use that syntax? Please copy and
paste the code. (It is well possible that it is correct.)

--
Army1987 (Replace "NOSPAM" with "email")
A hamburger is better than nothing.
Nothing is better than eternal happiness.
Therefore, a hamburger is better than eternal happiness.

[iesvs]

I got this structure:

struct matrix
{
int c, r;
double **coef;
};

and this function to access it:

double matrix_get (MATRIX *m, int i, int j)
{
return m->coef[i][j];
}

It works. But for me it's amazing.

[Richard Tobin]

In article <11**********************@n39g2000hsh.googlegroups .com>,
ie***@free.fr <ie***@free.frwrote:

>I got this structure:

struct matrix
{
int c, r;
double **coef;
};

and this function to access it:

double matrix_get (MATRIX *m, int i, int j)
{
return m->coef[i][j];
}

It works. But for me it's amazing.

I think you really need to learn the basics of C. Array subscripting
in C works by converting the array to a pointer (to its first element)
and then adding the subscript and dereferencing. So subscripting is
really a pointer operation, not an array operation.

I could describe it in more detail, but that's what books are for.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[iesvs]

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.

[Hyuga]

On Sep 27, 9:51 am, "[e-mail]" <[e-mail]:

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.

No offense, but I think you've proven Mr. Tobin's point.

Hyuga

[iesvs]

On Sep 27, 4:35 pm, Hyuga <[e-mail]:

On Sep 27, 9:51 am, "[e-mail]" <[e-mail]:

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.

No offense, but I think you've proven Mr. Tobin's point.

Hyuga

Explain please ? I like to learn things in C.

[Joachim Schmitz]

<ie***@free.frschrieb im Newsbeitrag
news:11**********************@n39g2000hsh.googlegr oups.com...

On Sep 27, 4:35 pm, Hyuga <[e-mail]:

>On Sep 27, 9:51 am, "[e-mail]" <[e-mail]:

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.

No offense, but I think you've proven Mr. Tobin's point.

Hyuga

Explain please ? I like to learn things in C.

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

Bye, Jojo

[iesvs]

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[i]);
}

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

//end of example

They said that "a" is a direct value but I can use it like it was an
indirect value. It's very strange. And nearly inconsistent. So it's
like gcc transform aff (a) by aff (&a). It's ugly. The arithmetic of
pointer is kicked with that. Not the classical arithmetic, the other
arithmetic (void is 0, void * is 1, void ** is 2 etc., there gcc make
-1 == 0, horrible for a mathematician, I know why I don't use array
now).

[CBFalconer]

"ie***@free.fr" wrote:

>
I got a double ** (double **coef). And gcc accept the syntax
coef[i][j], it works. I don't understand why. For me coef[i][j]
is not correct because it's a double ** and not type[][]. If
someone could explain me that.

coef is a pointer to a pointer to double. coef[x] reads the gets
the pointer coef, adds x to it (in units of sizeof *coef) returning
a pointer to double. coef[x][y] does all that, adds y to the
pointer to double, and returns the double to which that points.
All this assumes that the various addresses are in range and
contain what they are reputed to hold.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Joachim Schmitz]

<ie***@free.frschrieb im Newsbeitrag
news:11**********************@50g2000hsm.googlegro ups.com...

>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[i]);
}

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

//end of example

They said that "a" is a direct value but I can use it like it was an
indirect value. It's very strange. And nearly inconsistent. So it's
like gcc transform aff (a) by aff (&a). It's ugly. The arithmetic of
pointer is kicked with that. Not the classical arithmetic, the other
arithmetic (void is 0, void * is 1, void ** is 2 etc., there gcc make
-1 == 0, horrible for a mathematician, I know why I don't use array
now).

I can only repeat myself: read the FAQs. esp. Chapter 6...

Bye, Jojo

[iesvs]

I can only repeat myself: read the FAQs. esp. Chapter 6...

I rode the FAQ and understand it, but it's TERRIBLE, confuse a int *
and int, what a terrible concept. I'm disappointed by the C. I thought
it was mathematical consistent. But no.

[Francine.Neary]

On Sep 27, 5:54 pm, "[e-mail]" <[e-mail]:

I can only repeat myself: read the FAQs. esp. Chapter 6...

I rode the FAQ and understand it, but it's TERRIBLE, confuse a int *
and int, what a terrible concept. I'm disappointed by the C. I thought
it was mathematical consistent. But no.

and in another thread...

On Sep 27, 3:10 pm, "[e-mail]" <[e-mail]:

sizeof(char) is 1 by definition, always. Guess you meant 'if CHAR_BIT == 8'

When I code I don't assume that sizeof (char) == 1 and I'll never
assume it.

and in another thread...

On Sep 27, 10:47 am, "[e-mail]" <[e-mail]:

Which is where a profiler comes in...

No. I know when I programm if * 2 will be used 10 times or 10000....
I know from the beginning where are the important and no important
part. I don't need a software to say me these kind of things, moreover
there are more dumbs than me (a computer beat myself, ha ha ha).

Perhaps it's time to ask the city watch to step up patrols near the
bridge?

[Joachim Schmitz]

<ie***@free.frschrieb im Newsbeitrag
news:11**********************@y42g2000hsy.googlegr oups.com...

>I can only repeat myself: read the FAQs. esp. Chapter 6...

I rode the FAQ and understand it, but it's TERRIBLE, confuse a int *
and int, what a terrible concept. I'm disappointed by the C. I thought
it was mathematical consistent. But no.

I didn't ask you to ride the FAQs bit to read them 8-)
And no, an "int *" is not the same as an "int" and the FAQ doesn't claim
that, I'm fairly certain. Read it again.

Bye, Jojo

[iesvs]

I didn't ask you to ride the FAQs bit to read them 8-)

And no, an "int *" is not the same as an "int" and the FAQ doesn't claim
that, I'm fairly certain. Read it again.

Ok I past the FAQ :

http://c-faq.com/aryptr/aryptrstring.gif

You see the image where it says that
"a" is a "char"
and
"p" is a "char *"
, OK ? Look scrupulously the picture please.
And after that you explain me why when I got a function like that :
void f (char *)
{
...
}

I could write f (p) like f(a) so it confuse char and char *.
It's a proof.

[Joachim Schmitz]

<ie***@free.frschrieb im Newsbeitrag
news:11**********************@y42g2000hsy.googlegr oups.com...

>I didn't ask you to ride the FAQs bit to read them 8-)
And no, an "int *" is not the same as an "int" and the FAQ doesn't claim
that, I'm fairly certain. Read it again.

Ok I past the FAQ :

http://c-faq.com/aryptr/aryptrstring.gif

You see the image where it says that
"a" is a "char"

No it's a char []

and
"p" is a "char *"
, OK ? Look scrupulously the picture please.
And after that you explain me why when I got a function like that :
void f (char *)
{
...
}

I could write f (p) like f(a) so it confuse char and char *.

No it tells you that in this context a char[] is the same as a char *

Bye, Jojo

[iesvs]

No it's a char []

Ok, but it's a direct value, not an indirect value (p is an indirect
value). And I can use it like an indirect value. For me it's the same
thing than saying 0 = 1.

In the past I thought that a char[] was exactly a char * (the same
thing for the computer), so I find it correct to make f (a) where f
is ... f (char *) and a a char[]. But now no I saw that it's not the
same thing, and f (a) is incorrect for a mathematician (confuse a
direct value and an indirect what a silly idea).

[Default User]

ie***@free.fr wrote:

No it's a char []

Ok, but it's a direct value, not an indirect value (p is an indirect
value). And I can use it like an indirect value. For me it's the same
thing than saying 0 = 1.

In the past I thought that a char[] was exactly a char * (the same
thing for the computer), so I find it correct to make f (a) where f
is ... f (char *) and a a char[]. But now no I saw that it's not the
same thing, and f (a) is incorrect for a mathematician (confuse a
direct value and an indirect what a silly idea).

1. Get a decent book on C.

2. Read it.

Brian

[J. J. Farrell]

On Sep 27, 7:30 pm, "[e-mail]" <[e-mail]:

No it's a char []

Ok, but it's a direct value, not an indirect value (p is an indirect
value). And I can use it like an indirect value. For me it's the same
thing than saying 0 = 1.

In the past I thought that a char[] was exactly a char * (the same
thing for the computer), so I find it correct to make f (a) where f
is ... f (char *) and a a char[]. But now no I saw that it's not the
same thing, and f (a) is incorrect for a mathematician (confuse a
direct value and an indirect what a silly idea).

C is a relatively simple, logical, and straightforward language. It is
clear that it doesn't suit your way of thinking. I advise you not to
use it, which would also save you making such a fool of yourself in
public.

[Tor Rustad]

J. J. Farrell wrote:

[...]

C is a relatively simple, logical, and straightforward language.

"C is quirky, flawed and an enormous success"
Dennis Ritchie

It is
clear that it doesn't suit your way of thinking. I advise you not to
use it, which would also save you making such a fool of yourself in
public.

OP might be young, and without prior knowledge of K&R2, C FAQ and "C
Traps and Pitfalls", there are lots of bad habits outside c.l.c to pick
up. :)
--
Tor <torust [at] online [dot] no>

"Premature tuning is the root of all evil"

[Richard Tobin]

In article <VP*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>C is a relatively simple, logical, and straightforward language.

>"C is quirky, flawed and an enormous success"

These are not contradictory due to the "relatively" in the first
statement.

There are a few languages that are simpler and more logical than C,
and a whole lot that are the opposite.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Barry Schwarz]

On Thu, 27 Sep 2007 06:51:50 -0700, "ie***@free.fr" <ie***@free.fr>
wrote:

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

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

Because in a previous post you said that you didn't understand why you
could use the expression coef[i][j] when coef was a double** and not a
2D array of double. In C the expression x[i] is defined to be exactly
the same as *(x+i). This is a very fundamental basic concept in C.

>

>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.

The fact that types are different does not prevent them from sharing
syntax. int and double are two different types yet share the same +
operator.

You really do need to learn the basics.
Remove del for email

[iesvs]

You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C. Yeah I
not use the arrays, but they are useless. So yes you could learn me
many things about them, but I don't care I don't use. Pointer rules,
that's all. Many of my friends will laugh if I say them than some give
me the advice to learn basic C.

[Richard Heathfield]

ie***@free.fr said:

>You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C.

Then you have no need for the assistance of people in this newsgroup with
your questions about C. When you said:

"I got a double ** (double **coef). And gcc accept the syntax coef[i][j],
it works. I don't understand why. For me coef[i][j] is not correct because
it's a double ** and not type[][]. If someone could explain me that."

you were just winding us up. You already knew the answer, because you have
"nothing to learn in C".

Many of my friends will laugh if I say them than some give me the advice
to learn basic C.

There is much to laugh at.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Bos]

"ie***@free.fr" <ie***@free.frwrote:

You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C.

This is wrong, but you are ineducable.

Goodbye.

Richard

[William Hughes]

On Sep 28, 2:05 am, "[e-mail]" <[e-mail]:

You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C.

Piffle. You do not understand arrays for one.

Yeah I
not use the arrays, but they are useless.
So yes you could learn me
many things about them, but I don't care I don't use.

In which case you are entirely incompetent to maintain
code written by someone else. E.g. you do not understand
the very common idiom

func(int a[])

I do not use the shift operators, but I would not claim
that this means I can know C without knowing the shift
operators. In practice you have to know not only what they
are and how they should be used, but also how they
are used. I know that using a shift to multiply by a power
of two is a misplaced stab at efficiency (if your compiler
can't do this optimization, you have bigger problems than
a slower multiplication) but it is very common, and there
would be a lot of code I could not understand if I did not
recognize this.

You have a long way to go before you are a C expert.
Being able to write good C code is a necessary, but
not sufficient requirement.

- William Hughes

[iesvs]

You're just geeks guys. You think like geeks, talk like geeks and
understand nothing like geeks.

[Barry Schwarz]

On Thu, 27 Sep 2007 11:30:37 -0700, "ie***@free.fr" <ie***@free.fr>
wrote:

>No it's a char []

Ok, but it's a direct value, not an indirect value (p is an indirect
value). And I can use it like an indirect value. For me it's the same
thing than saying 0 = 1.

C doesn't use the terms direct value and indirect value. If you want
to use them, you must explain what they mean.

>
In the past I thought that a char[] was exactly a char * (the same
thing for the computer), so I find it correct to make f (a) where f
is ... f (char *) and a a char[]. But now no I saw that it's not the
same thing, and f (a) is incorrect for a mathematician (confuse a
direct value and an indirect what a silly idea).

Learn THE RULE: "Except when it is the operand of the sizeof operator
or the unary & operator, or is a string literal used to initialize an
array, an expression that has type ‘‘array of type’’ is converted to
an expression with type ‘‘pointer to type’’ that points to the initial
element of the array object and is not an lvalue."

What this tells you is that in most expressions, particularly as the
argument of a function, the array is converted to (evaluated as) a
pointer. Independent of whether the argument in the calling statement
is an array (f(a);) or pointer (f(p);), when f begins execution the
parameter is a pointer.

You seem convinced that C is full of silly ideas. Maybe you should
try another language that does things the way you want.
Remove del for email

[iesvs]

C doesn't use the terms direct value and indirect value. If you want

to use them, you must explain what they mean.

I know no language which hasn't direct and indirect value (it's not
Turing powerful without the indirect value).

An indirect value is something that you access by address.
A direct value is something that you access directly.

type * is indirect.
int, char, double, float etc are direct values.

C doesn't mention it but it use it, like any other language (Java has
indirect values, basic has indirect values, C++ also, OCaml also, Perl
also, JavaScrip also, Turing machine also, Lisp also etc.).

[iesvs]

Learn THE RULE: "Except when it is the operand of the sizeof operator

or the unary & operator, or is a string literal used to initialize an
array, an expression that has type ''array of type'' is converted to
an expression with type ''pointer to type'' that points to the initial
element of the array object and is not an lvalue."

What a ugly hack.

[Ben Bacarisse]

"ie***@free.fr" <ie***@free.frwrites:

>Learn THE RULE: "Except when it is the operand of the sizeof operator
or the unary & operator, or is a string literal used to initialize an
array, an expression that has type ''array of type'' is converted to
an expression with type ''pointer to type'' that points to the initial
element of the array object and is not an lvalue."

What a ugly hack.

There is always Haskell. Your programs might be a bit slower and I
would not try programming a wrist watch with it, but your programs
will be mathematically beautiful.

C is getting on a bit now, and the young do not always understand the
old. It serves its purpose well. If you don't understand its
purpose, it will seem peculiar -- like an old agricultural implement
you might find in a barn.

--
Ben.

[iesvs]

I just express that I would find it better if a char[] was a char *,
for the developer, not for the computer.

And I don't use haskell I rather like OCaml (more efficient).

[William Hughes]

On Sep 28, 2:05 am, "[e-mail]" <[e-mail]:

You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C.

Piffle. You know nothing about arrays.

Yeah I
not use the arrays, but they are useless. So yes you could learn me
many things about them, but I don't care I don't use.

So you are completely incompetent to maintain code that
you did not write. You would be stumped by the common idiom

func(int a[])
I do not use shift operators, but I do not consider that
it is possible to be an expert in C without understanding them.
Indeed, one
must know no only what they do, but how and why they are
commonly used. True, the use of a shift to multiply by a power
of two is usually a misplaced stab at efficiency (if your compiler
cannot
do this optimization you have bigger problems than a slow
multiplication) but if I did not know this was commonly done there
would be a lot of code that I could not understand
(e.g. Numerical Recipes).

Pointer rules,
that's all. Many of my friends will laugh if I say them than some give
me the advice to learn basic C.

Being able to generate good code is a necessary but not
sufficient condition for being an expert in C.

- William Hughes

PS: IMHO I am not an expert in C.

[Default User]

ie***@free.fr wrote:

You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C. Yeah I
not use the arrays, but they are useless. So yes you could learn me
many things about them, but I don't care I don't use. Pointer rules,
that's all. Many of my friends will laugh if I say them than some give
me the advice to learn basic C.

You're either trolling, or incurably stupid. Either way, a waste of my
time.

*plonk*


Brian

[Flash Gordon]

ie***@free.fr wrote, On 28/09/07 08:52:

You're just geeks guys.

You say hat like it is an insult.

You think like geeks, talk like geeks

<shrugWhat else do you expect from Geeks? Mind you, I suspect that not
everyone who posts here is a Geek.

and
understand nothing like geeks.

Here you show your ignorance of people, programming, and C in particular.
--
Flash Gordon

[CBFalconer]

Default User wrote:

ie***@free.fr wrote:

>Stop to say that, it's stupid. I have nothing to learn in C.
Yeah I not use the arrays, but they are useless. So yes you could
learn me many things about them, but I don't care I don't use.
Pointer rules, that's all. Many of my friends will laugh if I say
them than some give me the advice to learn basic C.

You're either trolling, or incurably stupid. Either way, a waste
of my time.

*plonk*

Second the motion.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Tor Rustad]

Richard Tobin wrote:

In article <VP*********************@telenor.com>,
Tor Rustad <to********@hotmail.comwrote:

>>C is a relatively simple, logical, and straightforward language.

>"C is quirky, flawed and an enormous success"

These are not contradictory due to the "relatively" in the first
statement.

When talking about "relativity", I rather prefer the language of tensors
and statements put in covariant form.

;)

There are a few languages that are simpler and more logical than C,
and a whole lot that are the opposite.

Of the programming languages I know, C was the most difficult language
to master.

C may appear logical to a CS student, they never do much numerical
computations anyway, but for a FORTRAN programmer.. learning C was a pain.

Heck.. it took me years, to start counting at 0, avoid memory leaks,
wild pointers and other C pitfalls. I still remember my first Monte
Carlo simulation in C, what a disaster that was.
--
Tor <torust [at] online [dot] no>
"I have stopped reading Stephen King novels. Now I just read C code instead"

[Charlie Gordon]

<ie***@free.fra écrit dans le message de news:
11**********************@22g2000hsm.googlegroups.c om...

You're just geeks guys. You think like geeks, talk like geeks and
understand nothing like geeks.

Music to my ears from the ultimate n00b

[Charlie Gordon]

<ie***@free.fra écrit dans le message de news:
11*********************@n39g2000hsh.googlegroups.c om...

>You really do need to learn the basics.

Stop to say that, it's stupid. I have nothing to learn in C. Yeah I
not use the arrays, but they are useless. So yes you could learn me
many things about them, but I don't care I don't use. Pointer rules,
that's all. Many of my friends will laugh if I say them than some give
me the advice to learn basic C.

Are you Beavis or Butthead ?

[Charlie Gordon]

<ie***@free.fra écrit dans le message de news:
11**********************@50g2000hsm.googlegroups.c om...

>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[i]);
}

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.

They said that "a" is a direct value but I can use it like it was an
indirect value. It's very strange. And nearly inconsistent. So it's
like gcc transform aff (a) by aff (&a). It's ugly. The arithmetic of
pointer is kicked with that. Not the classical arithmetic, the other
arithmetic (void is 0, void * is 1, void ** is 2 etc., there gcc make
-1 == 0, horrible for a mathematician, I know why I don't use array
now).

More likely because you know so little about C!
Your misconceptions are unfathomable, beyond repair.

--
Chqrlie.

[Charlie Gordon]

<ie***@free.fra écrit dans le message de news:
11**********************@r29g2000hsg.googlegroups. com...

>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]

"Charlie Gordon" <ne**@chqrlie.orgschrieb im Newsbeitrag
news:46**********************@news.free.fr...

<ie***@free.fra écrit dans le message de news:
11**********************@50g2000hsm.googlegroups.c om...

>>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[i]);
}

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]

"Joachim Schmitz" <no*********@schmitz-digital.dea écrit dans le message
de news: fd**********@online.de...

"Charlie Gordon" <ne**@chqrlie.orgschrieb im Newsbeitrag
news:46**********************@news.free.fr...

><ie***@free.fra écrit dans le message de news:
11**********************@50g2000hsm.googlegroups.c om...

>>>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[i]);
}

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)

--
Chqrlie.

[Joachim Schmitz]

"Charlie Gordon" <ne**@chqrlie.orgschrieb im Newsbeitrag
news:46**********************@news.free.fr...

"Joachim Schmitz" <no*********@schmitz-digital.dea écrit dans le message
de news: fd**********@online.de...

>"Charlie Gordon" <ne**@chqrlie.orgschrieb im Newsbeitrag
news:46**********************@news.free.fr...

>><ie***@free.fra écrit dans le message de news:
11**********************@50g2000hsm.googlegroups.c om...
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[i]);
}

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]

"Joachim Schmitz" <no*********@schmitz-digital.deschrieb im Newsbeitrag
news:fd**********@online.de...

"Charlie Gordon" <ne**@chqrlie.orgschrieb im Newsbeitrag
news:46**********************@news.free.fr...

>"Joachim Schmitz" <no*********@schmitz-digital.dea écrit dans le
message de news: fd**********@online.de...

>>"Charlie Gordon" <ne**@chqrlie.orgschrieb im Newsbeitrag
news:46**********************@news.free.fr...
<ie***@free.fra écrit dans le message de news:
11**********************@50g2000hsm.googlegroups.c om...
>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[i]);
}
>
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

[Richard Tobin]

In article <fd**********@online.de>,
Joachim Schmitz <jo**@schmitz-digital.dewrote:

>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...

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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Joachim Schmitz]

"Richard Tobin" <ri*****@cogsci.ed.ac.ukschrieb im Newsbeitrag
news:fd***********@pc-news.cogsci.ed.ac.uk...

In article <fd**********@online.de>,
Joachim Schmitz <jo**@schmitz-digital.dewrote:

>>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...

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?

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]

In article <fd**********@online.de>,
Joachim Schmitz <jo**@schmitz-digital.dewrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Flash Gordon]

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

"Richard Tobin" <ri*****@cogsci.ed.ac.ukschrieb im Newsbeitrag
news:fd***********@pc-news.cogsci.ed.ac.uk...

>In article <fd**********@online.de>,
Joachim Schmitz <jo**@schmitz-digital.dewrote:

>>>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...

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?

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.
--
Flash Gordon

[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; }

]

In article <fd***********@pc-news.cogsci.ed.ac.uk>
Richard Tobin <ri*****@cogsci.ed.ac.ukwrote (regarding fflush
and so on with relation to this problem):

>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
hostnamed

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.
--
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.