Pointer Ambiguity

[Umesh]

Please read the comments.
Program to multiply the elements of an array with its size.
#define s 5
#include<stdio.h>

void mul(int *p)
{
for(int i=0;i<s;i++)
{
printf("%d ",*p*s);
p++;
}
}

main()
{
int a[s],i;
printf("Enter %d No. ",s);
for(i=0;i<s;i++)
scanf("%d",&a[i]);
mul(a);/* it should be mul(&a) why not?*/
return 0;
}

[Ian Collins]

Umesh wrote:

Please read the comments.

Come back when you learn how to write main correctly.

>
main()

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Umesh wrote:

>Please read the comments.

Come back when you learn how to write main correctly.

>>
main()

What's incorrect about that?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[blufox]

On Jun 17, 12:40 pm, Richard Heathfield <[e-mail]:

Ian Collins said:

Umesh wrote:

Please read the comments.

Come back when you learn how to write main correctly.

main()

What's incorrect about that?

Ideally that should be
int main(void)

thanks

>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Ian Collins said:

>Umesh wrote:

>>Please read the comments.

Come back when you learn how to write main correctly.

>>>
main()

What's incorrect about that?

In C90, it's correct (but poor style). In C99, it's illegal. Since
the code uses a declaration in a for loop:

for(int i=0;i<s;i++)

we can infer that it's intended to be C99, and that main is declared
incorrectly. Or that it's intended to be C90, and the for loop is
written incorrectly. Or, more likely, that the compiler is invoking
his compiler in a mode that conforms to neither standard, and doesn't
know or care whether his code is correct.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Malcolm McLean]

"blufox" <25**********@gmail.comwrote in message
news:11**********************@j4g2000prf.googlegro ups.com...

On Jun 17, 12:40 pm, Richard Heathfield <[e-mail]:

>Ian Collins said:

Umesh wrote:
Please read the comments.

Come back when you learn how to write main correctly.

>main()

What's incorrect about that?

Ideally that should be
int main(void)

thanks

Ideally.
But implicit int is conforming, and arguably a good idea, since it demotes
size_t.
An empty argument list means that the function takes no or more parameters.
So the fact that main(void) is allowed is a quirk.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:
[...]

we can infer that it's intended to be C99, and that main is declared
incorrectly. Or that it's intended to be C90, and the for loop is
written incorrectly. Or, more likely, that the compiler is invoking
his compiler in a mode that conforms to neither standard, and doesn't
know or care whether his code is correct.

Whoop, I meant that the *original poster* is invoking his compiler in
a mode that etc.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Richard Heathfield wrote:

Ian Collins said:

>Umesh wrote:

>>Please read the comments.

Come back when you learn how to write main correctly.

>>main()

What's incorrect about that?

The fact (as Keith beat me to pointing out) that it was associated with
this:

for(int i=0;i<s;i++)

--
Ian Collins.

[Flash Gordon]

Malcolm McLean wrote, On 17/06/07 09:32:

>
"blufox" <25**********@gmail.comwrote in message
news:11**********************@j4g2000prf.googlegro ups.com...

>On Jun 17, 12:40 pm, Richard Heathfield <[e-mail]:

>>Ian Collins said:

Umesh wrote:
Please read the comments.

Come back when you learn how to write main correctly.

main()

What's incorrect about that?

Ideally that should be
int main(void)

thanks

Ideally.
But implicit int is conforming, and arguably a good idea, since it
demotes size_t.

Implicit int has nothing to do with size_t so I really can't see what
you are trying to say.

An empty argument list means that the function takes no or more
parameters. So the fact that main(void) is allowed is a quirk.

It is still a good idea because it is the only way to ensure the
compiler will complain if you then call main recursively passing it
parameters. This is more important for other functions (where it does
not only apply to recursive calls), but it is a good habit.
--
Flash Gordon

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>Ian Collins said:

>>Umesh wrote:
Please read the comments.
Come back when you learn how to write main correctly.
main()

What's incorrect about that?

The fact (as Keith beat me to pointing out) that it was associated
with this:

for(int i=0;i<s;i++)

Since he uses implicit int, I infer that he's writing in C90, in which
case it's the for loop that is incorrect.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[regis]

Umesh wrote:

Please read the comments.
Program to multiply the elements of an array with its size.

#define s 5
#include<stdio.h>

About the order the #define and the #include directives:
what happens if printf() is declared as:

int printf (const char * s, ...);

Won't the declaration be expanded into:

int printf (const char * 5, ...);

--
regis

[Harald van =?UTF-8?B?RMSzaw==?=]

regis wrote:

Umesh wrote:

>Please read the comments.
Program to multiply the elements of an array with its size.

>#define s 5
#include<stdio.h>

About the order the #define and the #include directives:
what happens if printf() is declared as:

int printf (const char * s, ...);

Won't the declaration be expanded into:

int printf (const char * 5, ...);

Yes, and because of that, <stdio.his not allowed to declare printf that
way.

[regis]

Harald van Dijk wrote:

regis wrote:

>Umesh wrote:

>>Please read the comments.
Program to multiply the elements of an array with its size.
#define s 5
#include<stdio.h>

About the order the #define and the #include directives:
what happens if printf() is declared as:

int printf (const char * s, ...);

Won't the declaration be expanded into:

int printf (const char * 5, ...);

Yes, and because of that, <stdio.his not allowed to declare printf that
way.

so, is the use of double underscore prefixes for identifiers
or the use of no identifier at all
mandatory for standard headers ?

[Harald van =?UTF-8?B?RMSzaw==?=]

regis wrote:

Harald van Dijk wrote:

>regis wrote:

>>Umesh wrote:
Please read the comments.
Program to multiply the elements of an array with its size.
#define s 5
#include<stdio.h>
About the order the #define and the #include directives:
what happens if printf() is declared as:

int printf (const char * s, ...);

Won't the declaration be expanded into:

int printf (const char * 5, ...);

Yes, and because of that, <stdio.his not allowed to declare printf that
way.

so, is the use of double underscore prefixes for identifiers
or the use of no identifier at all
mandatory for standard headers ?

There are other reserved identifiers that could be used, but yes, standard
headers can't use identifiers for parameter names that user code is allowed
to use.

[Chris Torek]

[given something like:

>>>#define s 5
#include<stdio.h>

which causes the identifier s to expand to the number 5 if an
unadorned "s" appears inside the contents of <stdio.h>, assuming
that <stdio.his an ordinary file that is expanded in the ordinary
way]

>>regis wrote:

>>>what happens if printf() is declared as:
int printf (const char * s, ...);
Won't the declaration be expanded into:
int printf (const char * 5, ...);

>Harald van Dijk wrote:

>>Yes, and because of that, <stdio.his not allowed to declare printf that
way.

In article <46**********************@news.free.fr>
regis <re**************@free.frwrote:

>so, is the use of double underscore prefixes for identifiers
or the use of no identifier at all
mandatory for standard headers ?

The C standards do not say *how* the implementation has to avoid
the problem, just that it must avoid the problem.

Two obvious and simple methods are, indeed, to use double-underscore
prefixes or omit identifier names, e.g.:

char *strcpy(char *restrict __dst, const char *restrict);

However, an implementor can use *any* reserved-to-the-implementor
name, e.g.:

char *strcpy(char *restrict memset, const char *restrict _E);

(which is admittedly kind of bizarre), or even compiler-specific
extensions such as:

#pragma implementor_namespace_hack
char *strcpy(char *restrict dst, const char *restrict src);
#pragma end_implementor_namespace_hack

or similar. If <stdio.hor -- as in this case -- <string.his
not, in fact, an ordinary file at all -- e.g., if it simply turns
on a flag in the compiler that says that the header has been included
-- there may even be no preprocessing phase involved, hence no
"name collision hazard" in the first place.
--
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.

[regis]

Chris Torek wrote:

[given something like:

>>>>#define s 5
#include<stdio.h>

which causes the identifier s to expand to the number 5 if an
unadorned "s" appears inside the contents of <stdio.h>, assuming
that <stdio.his an ordinary file that is expanded in the ordinary
way]

[...]

If <stdio.hor -- as in this case -- <string.his
not, in fact, an ordinary file at all -- e.g., if it simply turns
on a flag in the compiler that says that the header has been included
-- there may even be no preprocessing phase involved, hence no
"name collision hazard" in the first place.

Ok. So, along these lines, I guess

#define printf foo
#include <stdlib.h>

also gives unpredictable results, that is, one cannot predict if

int foo (const char *, ...);

or

int printf (const char *, ...);

will be declared.

[Army1987]

"regis" <re**************@free.frha scritto nel messaggio
news:46**********************@news.free.fr...

Chris Torek wrote:

>[given something like:

>>>>>#define s 5
>#include<stdio.h>

which causes the identifier s to expand to the number 5 if an
unadorned "s" appears inside the contents of <stdio.h>, assuming
that <stdio.his an ordinary file that is expanded in the ordinary
way]

[...]

>If <stdio.hor -- as in this case -- <string.his
not, in fact, an ordinary file at all -- e.g., if it simply turns
on a flag in the compiler that says that the header has been included
-- there may even be no preprocessing phase involved, hence no
"name collision hazard" in the first place.

Ok. So, along these lines, I guess

#define printf foo
#include <stdlib.h>

also gives unpredictable results, that is, one cannot predict if

int foo (const char *, ...);

or

int printf (const char *, ...);

will be declared.

From the C99 rationale, 6.10.3:
As with any other powerful language feature, keyword redefinition is subject
to abuse. Users

cannot expect any meaningful behavior to come about from source files
starting with

#define int double

#include <stdio.h>

or similar subversions of common sense.