output of C codes

[want_to_code]

1.

#include<stdio.h>
int main()
{
 int function(int);
 int t=function(1);  printf("\tt=%d",t);
 t=function(2);  printf("\tt=%d",t);
 t=function(3);  printf("\tt=%d",t);
 return 0;
}

int function (int a)
{
int t;
t = a<<2 + a;
return t;
}

the output is
t=8 t=32 t=96
i am not able to figure out why this is happening.
can someone explain what is happening in the function() ?

2.

#include<stdio.h>
#include<math.h>
int main(main)
{
 printf("\n%d",main+=pow(++main,++main));
 return 0;
}

what does the above program do with "main"?
why does main take 1, initially?

3.

#include<stdio.h>
struct s
{
int si;
union U         // UNION NOT ASSIGNED SPACE
{
float uf;
char uc;
};
};
main( )
{
struct s un;
printf ("\n\t%d\n", sizeof (struct s));
}

why does the above program print the sizeof(int)
though there is a union inside the struct?

[MosaicFuneral]

1.

#include<stdio.h>
int main()
{
 int function(int);
  ...

Prototypes don't go inside other functions.

[Aia]

#include<stdio.h>
#include<math.h>
int main(main)
{
printf("\n%d",main+=pow(++main,++main));
return 0;
}

>what does the above program do with "main"?

A mockery of the C Standard, and a massive example of undefined behavior.

[John A]

>Prototypes don't go inside other functions.
Wrong. Prototypes don't usually go inside other functions.

[Aia]

>Prototypes don't go inside other functions.
Wrong. Prototypes don't usually go inside other functions.

While placing prototypes at the beginning of the program, and outside any function, is not strictly necessary, it is a measurement of good practice. Therefore I support the statement of MosaicFuneral as
correct, in the spirit of good practice. And your correction as the italicized exception, product of bad practice.

[John A]

>And your correction as the italicized exception, product of bad practice.
While you're entitled to your own opinion, that statement is just BS. There are perfectly acceptable reasons why you would want to shield a function's prototype from the scope of the file, and declaring the prototype within a function is a legal and valid way to accomplish this.

I would agree with you that placing the prototype within main() in this case is silly and doesn't accomplish anything, but I wouldn't go so far as to say it's wrong.

[ArkM]

1. Operator priorities: a<<2 + a treated as a << (2+a).
2. Undefined result; side effect of ++ operators and undefined order of argument list evaluation, cases <2>+=pow(2,2), <3>+=pow(2,3) and others are possible...
3. It's only the union U type (not a member) declaration in struct s definition body.

[Aia]

>And your correction as the italicized exception, product of bad practice.
While you're entitled to your own opinion, that statement is just BS.
[...]

In the interest of not entering a pissing contest I am going to leave it at that.

[nucleon]

I find it useful on occasion to place a prototype in a function. (pssssssssssss)

[John A]

>In the interest of not entering a pissing contest I am going to leave it at that.
Just because you're wrong doesn't mean I hate you. :P

[jephthah]

I find it useful on occasion to place a prototype in a function.

for what reasons, and in what context?

please elaborate.

[Aia]

I find it useful on occasion to place a prototype in a function.

for what reasons, and in what context?

please elaborate.

I would also like to see such a piece of code, were imperative reasons made it necessary to prototype a function inside a function.

When the American National Standard Institute, in 1983, formed the committee that developed the standard for the C language, they were guided by a few basic principles of which to me, the most important are:
"Trust the programmer.
Don't prevent the programmer from doing what needs to be done."

But similarly to a coin that has two sides, that kind of powerful freedom has another side. The ugly side of "bad practice and abuse," of the tools which the language provides
I give you as an example the three snippets that the OP posted. While those are "very obvious", there are others rooted in more accepted way.

Focus has shifted to the proper placement of function prototypes. A tool that was designed to make the compiler your first line of defense against improper passing of parameters, and not as a guarantee of restricting function scope. But there would be always someone that finds reason to stretch the functionality of a tool, and wonder when the practice goes amok.

Prototypes are better declared at the beginning of a program, and best in a header file.