extern int *a , int a[10]

[sinbad]

hi, check out the following program ...

a.c
-----
extern void fun();

int a[10];

int main ()
{
fun ();
}

b.c
-----
extern int *a;

void fun()
{
a++;
printf ("%d",a);
}
If i compile the above two files together ...
what should be the behavior of variable a in fun() , it should be
pointing to the array right ? More specifically this should give a
compile error , as i expected because in file a.c , a is an array that
means the memory location pointed to by 'a' is a constant ( a is a
constant pointer , although not completely correct , we can think like
that) and in file b.c , we are declaring 'a' as a non const pointer to
integer ... There is a type mismatch here ... Can somone explain
this ...

thanks
sinbad

[anon.asdf]

On Aug 10, 12:24 pm, sinbad <sinbad.sin...@ gmail.comwrote:

hi, check out the following program ...

a.c
-----
extern void fun();

int a[10];

int main ()
{
fun ();

}

b.c
-----
extern int *a;

void fun()
{
a++;
printf ("%d",a);}

If i compile the above two files together ...
what should be the behavior of variable a in fun() , it should be
pointing to the array right ?

But it does not!

Try these test programs:

/** a.c **/
#include <stdio.h>

extern void fun();

int a[10] = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9};

int main ()
{
printf("&a = %p\n", a);
fun ();

}
/** b.c **/
#include <stdio.h>

extern int *a;

void fun()
{
a++;
printf("a++; &a = %p\n", a);
// printf ("%d\n",*a);
}

On gcc (linux) I get:
&a = 0x8049600
a++; &a = 0x4
You can get your desired behaviour (but that was not what your
question is about, right?) with
/** b2.c **/
#include <stdio.h>

extern int a[10];
int *a2 = a;

void fun()
{
a2++;
printf("a++; &a = %p\n", a2);
// printf ("%d\n",*a2) ;
}
-anon.asdf

[Chris Dollin]

sinbad wrote:

hi, check out the following program ...

a.c
-----
extern void fun();

int a[10];

int main ()
{
fun ();
}

b.c
-----
extern int *a;

void fun()
{
a++;
printf ("%d",a);
}
If i compile the above two files together ...

What do you mean by "together"? Catenate the files and supply them
as one unit to the compiler, or compile each separately and link
the object files [1]?

If the latter, you have a type mismatch that the implementation
isn't required to detect. Undefined behaviour. If you're lucky,
BOOM. If you're unlucky, BOOM tomorrow, for some value of "tomorrow".

what should be the behavior of variable a in fun() , it should be
pointing to the array right ? More specifically this should give a
compile error , as i expected because in file a.c , a is an array that
means the memory location pointed to by 'a' is a constant ( a is a
constant pointer , although not completely correct , we can think like
that)

We can, but we should not. Just think of it as "`a` is [the name of] an
array of [[10]] ints". Arrays are not pointers; pointers are not arrays.
(Books are not newspapers; newspapers are not books; but they have
shared operations, such as providing entertainment and kindling, as
well as unshared ones -- wrapping one's fish'n'chips in a book is
a tad tricky.)

and in file b.c , we are declaring 'a' as a non const pointer to
integer ... There is a type mismatch here ... Can somone explain
this ...

You're right. There's a type mismatch. Given that the implementation
isn't required to detect it, what should we do?

Answer: don't mess around putting declarations for `a` in the .c
file. Put them in a .h file. My advice would be to put such a
declaration in a .h file with the same name as the .c file that
/defines/ `a`, here `a.c`. So in `a.h` put

extern int a[10];

Then have `a.c` and `b.c` both #include `a.h`. Now `b.c` sees the correct
declaration for `a`, and compiling `a.c` will expose incompatabiliti es
between the shared declaration of `a` and its definition.

[1] Skipping over that "link" and "object files" aren't part of the standard ...

--
Chris "where's Ivanova when you need her?" Dollin

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Richard Bos]

sinbad <si***********@ gmail.comwrote:

a.c
-----

int a[10];

b.c
-----
extern int *a;

If i compile the above two files together ...
what should be the behavior of variable a in fun() ,

*Sigh* The _first_ question in the relevant section of the FAQ:
<http://c-faq.com/aryptr/aryptr1.html>. And the following ones.

Richard

[Ben Bacarisse]

sinbad <si***********@ gmail.comwrites :

hi, check out the following program ...

a.c
-----
extern void fun();

int a[10];

int main ()
{
fun ();
}

b.c
-----
extern int *a;

void fun()
{
a++;
printf ("%d",a);
}
If i compile the above two files together ...
what should be the behavior of variable a in fun() , it should be
pointing to the array right ? More specifically this should give a
compile error , as i expected because in file a.c , a is an array that
means the memory location pointed to by 'a' is a constant ( a is a
constant pointer , although not completely correct , we can think like
that) and in file b.c , we are declaring 'a' as a non const pointer to
integer ... There is a type mismatch here ... Can somone explain
this ...

What is the real question here? Most C linkers can't type check, so
it is up to you not to lie. If you lie, your get a program with
undefined behaviour. Your example is really no different to declaring
a function int foo(void) and defining it (in another source file) as
double foo(void). The program might or might not break, but it is not
a valid C program.

--
Ben.

[Army1987]

On Fri, 10 Aug 2007 11:56:09 +0100, Chris Dollin wrote:

[1] Skipping over that "link" and "object files" aren't part of the standard ...

But translation units are.
--
Army1987 (Replace "NOSPAM" with "email")
No-one ever won a game by resigning. -- S. Tartakower

[Keith Thompson]

Army1987 <ar******@NOSPA M.itwrites:

On Fri, 10 Aug 2007 11:56:09 +0100, Chris Dollin wrote:

>[1] Skipping over that "link" and "object files" aren't part of the
standard ...

But translation units are.

And translation phase 8 (C99 5.1.1.2) is:

All external object and function references are resolved. Library
components are linked to satisfy external references to functions
and objects not defined in the current translation. All such
translator output is collected into a program image which contains
information needed for execution in its execution environment

--
Keith Thompson (The_Other_Keit h) 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"