void main()
{
int i = 20;
void fn();
fn();

printf ("%d",i);
}

void fn()
{
// add ur code only here so that i in main should print OTHER THAN 20
}

Is there any Leagal solution for this?
Thanks,

Padmat wrote:
> void main()
^^^^
main() returns an int.
If this is an interview question, walk out.
You do not want to work as a C programmer in anyplace that countenances
baby mistakes.

> {
> int i = 20;
> void fn();
> fn();
> printf ("%d",i);
^^^^^^
No declaration in scope for this variadic question.
If this is an interview question, walk out.
You do not want to work as a C programmer in anyplace that countenances
baby mistakes.

> }
>
> void fn()
> {
> // add ur code only here so that i in main should print OTHER THAN 20
^^
Stupid adolescent spelling.
If this is an interview question, walk out.

> }
>
> Is there any Leagal solution for this?

Of course not. The identifier 'i' in main is local to main(). If your
interviewer wants you to play games with non-portable (even to the next
revision of your compiler) assumptions about how variables are stored,
walk out.

In article <slrnfq6vq0.686.nospam@nospam.invalid>, Padmat <no@spam.com> wrote:
>void main()
>{
> int i = 20;
> void fn();
> fn();
>
> printf ("%d",i);
>}
>
>void fn()
>{
> // add ur code only here so that i in main should print OTHER THAN 20
>}
>
>Is there any Leagal solution for this?
>Thanks,
>

I've re-arranged your code a bit, to make it a bit more clc-compliant
(though no claim of full compliance is made - I'm sure the regs will
come up with something to nitpick). Note the missing include that would
have made your program UB.

% cat x.c
void fn()
{
// add ur code only here so that i in main should print OTHER THAN 20
}

#include "stdio.h"

int main()
{
int i = 20;
fn();

printf ("i = %d\n",i);
return 0;
}

% gcc -Wall -Werror x.c
% ./a.out
i = 13
%

HTH

On 1 Feb 2008 at 20:21, Padmat wrote:
> void main()
> {
> int i = 20;
> void fn();
> fn();
>
> printf ("%d",i);
> }
>
> void fn()
> {
> // add ur code only here so that i in main should print OTHER THAN 20
> }
>
> Is there any Leagal solution for this?
> Thanks,

Here is a solution for Linux/gcc-i386. I had to make i volatile to stop
gcc optimizing it away.


#include <stdio.h>

#define OFFSET 8 /* may need to change this depending on your compiler */

main()
{
volatile int i = 20;
void fn();
fn();

return printf ("%d\n",i);
}

void fn()
{
volatile int b;
*(&b + OFFSET)=42;
}

Happy hacking!

Padmat wrote:
>
> void main()
> {
> int i = 20;
> void fn();
> fn();
>
> printf ("%d",i);
> }
>
> void fn()
> {
>// add ur code only here so that i in main should print OTHER THAN 20
> }
>
> Is there any Leagal solution for this?
> Thanks,

/* BEGIN new.c */

#include <stdio.h>

void fn(void);

int main(void)
{
int i = 20;

fn();
printf("%d\n", i);
return 0;
}

void fn(void)
{
printf("OTHER THAN ");
}

/* END new.c */

--
pete

Kenny McCormack:


> I've re-arranged your code a bit, to make it a bit more clc-compliant
> (though no claim of full compliance is made - I'm sure the regs will
> come up with something to nitpick). Note the missing include that
> would have made your program UB.

<snip code>

Good stuff.

As I'm sure you're already aware tho, you need angle brackets instead of
inverted commas:

#include <stdio.h>

--
Tomás Ó hÉilidhe

Padmat:

> void main()
> {
> int i = 20;
> void fn();
> fn();
>
> printf ("%d",i);
> }
>
> void fn()
> {
> // add ur code only here so that i in main should print OTHER THAN 20
> }
>
> Is there any Leagal solution for this?


Nope, because other functions can't access the local automatic variables of
other functions (unless of course you supply them with a pointer to the
variable in question).

--
Tomás Ó hÉilidhe

pete ha scritto:
> Padmat wrote:
>> void fn()
>> {
>> // add ur code only here so that i in main should print OTHER THAN 20
>> }
>>
>> Is there any Leagal solution for this?

> void fn(void)
> {
> printf("OTHER THAN ");
> }

This wins hands down. Good catch!

R.D.

In article <Xns9A37DAC73F0D8toelavabitcom@194.125.133.14>,
Tomás Ó hÉilidhe <toe@lavabit.com> wrote:
>Kenny McCormack:
>
>
>> I've re-arranged your code a bit, to make it a bit more clc-compliant
>> (though no claim of full compliance is made - I'm sure the regs will
>> come up with something to nitpick). Note the missing include that
>> would have made your program UB.
>
><snip code>
>
>Good stuff.
>
>As I'm sure you're already aware tho, you need angle brackets

Ya think so?
(I don't)

>instead of inverted commas:

What is an inverted comma???

>#include <stdio.h>
>
>--
>Tomás Ó hÉilidhe

In article <47a39153$0$36451$4fafbaef@reader5.news.tin.it>,
Remo D. <rdentato> wrote:
>pete ha scritto:
>> Padmat wrote:
>>> void fn()
>>> {
>>> // add ur code only here so that i in main should print OTHER THAN 20
>>> }
>>>
>>> Is there any Leagal solution for this?
>
>> void fn(void)
>> {
>> printf("OTHER THAN ");
>> }
>
>This wins hands down. Good catch!
>
>R.D.

Yes. Very cool.

Of course, it leaves open the question as to exactly what the phrase
"i in main" means.

Kenny McCormack ha scritto:
> In article <47a39153$0$36451$4fafbaef@reader5.news.tin.it>,
> Remo D. <rdentato> wrote:
>> pete ha scritto:
>>> Padmat wrote:
>>>> void fn()
>>>> {
>>>> // add ur code only here so that i in main should print OTHER THAN 20
>>>> }
>>>>
>>>> Is there any Leagal solution for this?
>>> void fn(void)
>>> {
>>> printf("OTHER THAN ");
>>> }
>> This wins hands down. Good catch!
>>
>> R.D.
>
> Yes. Very cool.
>
> Of course, it leaves open the question as to exactly what the phrase
> "i in main" means.
>

I guess the guy who wrote that line had some problem with the keyboard.
First "ur", then "i in"

R.D.

BTW, I think the question was intended to start the conversation with
the candidate. Probably they were only interested in the candidate's
thinking process. Pete thought out of the box, Antoninus showed he would
do literally *anything* to solve the problem, others could have said
that there's no "legal" way since i is not visible in main, etc..

No "right" answer, just a teaser to see your reaction.

Remo D. wrote:

>>>> Padmat wrote:
>>>>> void fn()
>>>>> {
>>>>> // add ur code only here so that i in main should print OTHER THAN 20
>>>>> }
>>>>>

>
> BTW, I think the question was intended to start the conversation with
> the candidate. Probably they were only interested in the candidate's
> thinking process. Pete thought out of the box, Antoninus showed he would
> do literally *anything* to solve the problem, others could have said
> that there's no "legal" way since i is not visible in main, etc..
>
> No "right" answer, just a teaser to see your reaction.

While some of us would have questioned the interviewer's ability to
write comprehensible English!

--
Ian Collins.

Remo D. wrote:
>
> Kenny McCormack ha scritto:
> > In article <47a39153$0$36451$4fafbaef@reader5.news.tin.it>,
> > Remo D. <rdentato> wrote:
> >> pete ha scritto:
> >>> Padmat wrote:
> >>>> void fn()
> >>>> {
> >>>> // add ur code only here so that i in main should print OTHER THAN 20
> >>>> }
> >>>>
> >>>> Is there any Leagal solution for this?
> >>> void fn(void)
> >>> {
> >>> printf("OTHER THAN ");
> >>> }
> >> This wins hands down. Good catch!
> >>
> >> R.D.
> >
> > Yes. Very cool.
> >
> > Of course, it leaves open the question as to exactly what the phrase
> > "i in main" means.
> >
>
> I guess the guy who wrote that
> line had some problem with the keyboard.
> First "ur", then "i in"

I interpreted "i in main"
as an Iyaric "I word" expression.

--
pete

Antoninus Twink wrote, On 01/02/08 21:20:
> On 1 Feb 2008 at 20:21, Padmat wrote:
>> void main()
>> {
>> int i = 20;
>> void fn();
>> fn();
>>
>> printf ("%d",i);
>> }
>>
>> void fn()
>> {
>> // add ur code only here so that i in main should print OTHER THAN 20
>> }
>>
>> Is there any Leagal solution for this?
>> Thanks,
>
> Here is a solution for Linux/gcc-i386. I had to make i volatile to stop
> gcc optimizing it away.

Doesn't work one all systems meeting that spec. For example, it does not
work on this one.

> #include <stdio.h>
>
> #define OFFSET 8 /* may need to change this depending on your compiler */
>
> main()
> {
> volatile int i = 20;
> void fn();
> fn();
>
> return printf ("%d\n",i);
> }
>
> void fn()
> {
> volatile int b;
> *(&b + OFFSET)=42;
> }


markg@brenda:~$ cat t.c
#include <stdio.h>

#define OFFSET 8 /* may need to change this depending on your compiler */

main()
{
volatile int i = 20;
void fn();
fn();

return printf ("%d\n",i);
}

void fn()
{
volatile int b;
*(&b + OFFSET)=42;
}
markg@brenda:~$ gcc t.c
markg@brenda:~$ ./a.out
20
markg@brenda:~$ uname -a
Linux brenda 2.6.22-14-generic #1 SMP Tue Dec 18 08:02:57 UTC 2007 i686
GNU/Linux
markg@brenda:~$
--
Flash Gordon

On 2 Feb 2008 at 0:28, Flash Gordon wrote:
> Antoninus Twink wrote, On 01/02/08 21:20:
>> Here is a solution for Linux/gcc-i386. I had to make i volatile to stop
>> gcc optimizing it away.
>
> Doesn't work one all systems meeting that spec. For example, it does not
> work on this one.
>
>> #include <stdio.h>
>>
>> #define OFFSET 8 /* may need to change this depending on your compiler */

Did you change OFFSET appropriately for the version and optimization
level of your compiler, as specified in this comment?

Kenny McCormack:

>>As I'm sure you're already aware tho, you need angle brackets
>
> Ya think so?
> (I don't)


For includes files within your own project:

#include "data.h"

For include files which are part of the implementation or that are shared:

#include <stdio.h>
#include <some_library\gui.h>


>>instead of inverted commas:
>
> What is an inverted comma???


You might know them better as quotes: " "

--
Tomás Ó hÉilidhe

Padmat wrote:

> void main()
> {
> int i = 20;
> void fn();
> fn();
>
> printf ("%d",i);
> }
>
> void fn()
> {
> // add ur code only here so that i in main should print OTHER THAN 20
extern void exit(int);
extern int putchar(int);
putchar('2');
putchar('1');
exit(0);
> }
--
Army1987 (Replace "NOSPAM" with "email")

Tomás Ó hÉilidhe wrote:

> Kenny McCormack:
>
>
>> I've re-arranged your code a bit, to make it a bit more clc-compliant
>> (though no claim of full compliance is made - I'm sure the regs will
>> come up with something to nitpick). Note the missing include that
>> would have made your program UB.
>
> <snip code>
>
> Good stuff.
>
> As I'm sure you're already aware tho, you need angle brackets instead of
> inverted commas:
>
> #include <stdio.h>

With #include "stdio.h", if ./stdio.h cannot be found, it is treated as if
it were #include <stdio.h>, therefore including /usr/include/stdio.h (or
wherever the standard header is, and regardless of whether it's actually a
file).


--
Army1987 (Replace "NOSPAM" with "email")

In article <Xns9A3876279E2E3toelavabitcom@194.125.133.14>,
Tomás Ó hÉilidhe <toe@lavabit.com> wrote:
>Kenny McCormack:
>
>>>As I'm sure you're already aware tho, you need angle brackets
>>
>> Ya think so?
>> (I don't)
>
>
>For includes files within your own project:
>
> #include "data.h"

Really? Gee, I'd never have known if you hadn't been so kind as to
point it out.

By the way, how do you suppose I did get 13 as the output of my program?

>For include files which are part of the implementation or that are shared:
>
> #include <stdio.h>
> #include <some_library\gui.h>

Really? Gee, I'd never have known if you hadn't been so kind as to
point it out.

>
>>>instead of inverted commas:
>>
>> What is an inverted comma???
>
>
>You might know them better as quotes: " "

In much the same way as if I referred to a cat as an elephantoid, you
might ask me what an elephantoid is, and I would almost certainly reply
that you probably know it as a cat.

Kenny McCormack wrote:

> In article <47a39153$0$36451$4fafbaef@reader5.news.tin.it>,
> Remo D. <rdentato> wrote:
>>pete ha scritto:
>>> Padmat wrote:
>>>> void fn()
>>>> {
>>>> // add ur code only here so that i in main should print OTHER THAN 20
>>>> }
>>>>
>>>> Is there any Leagal solution for this?
>>
>>> void fn(void)
>>> {
>>> printf("OTHER THAN ");
>>> }
>>
>>This wins hands down. Good catch!
> Of course, it leaves open the question as to exactly what the phrase
> "i in main" means.

Of course, i in main is an int, so it cannot print anything at all. But it
is possible that the OP is not a native speaker of English and not very
fluent in it, so he didn't literally mean what he wrote. But, using the
most reasonable interpretation for that, well, in pete's program, "OTHER
THAN 20" *is* printed by the printf which prints the value of i in main
(provided that stdout is either line- or fully buffered), as fn just
writes into a stdio library buffer (it contains no newline character, so
it is not printed until a '\n' is putchar()red or stdout is fflush()ed).

--
Army1987 (Replace "NOSPAM" with "email")

Army1987 <army1987@NOSPAM.it> writes:
[...]
> With #include "stdio.h", if ./stdio.h cannot be found, it is treated as if
> it were #include <stdio.h>, therefore including /usr/include/stdio.h (or
> wherever the standard header is, and regardless of whether it's actually a
> file).

Not quite. The standard says nothing about "./" or "/usr/include"
(you acknowledged the latter, but not the former). It's not even
clear that "./stdio.h" refers to "stdio.h" in the current directory;
there might not be such a thing as a "current directory", and if there
is, it might not be called ".", and "/" might not be a valid directory
delimiter.

``#include "stdio.h"'' causes the file identified by ``stdio.h''
(which may or may not be a file *named* "stdio.h") in a sequence of
implementation-defined places. If that search fails, the directive is
then reprocessed as if it said ``#include <stdio.h>''.

So ``#include "stdio.h"'' is very likely to work, but it can fail if
there happens to be a file named stdio.h, or rather identified by the
character sequence ``stdio.h'', in the implementation-defined search
path.

--
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson wrote:

> ``#include "stdio.h"'' causes the file identified by ``stdio.h''
> (which may or may not be a file *named* "stdio.h") in a sequence of
> implementation-defined places. If that search fails, the directive is
> then reprocessed as if it said ``#include <stdio.h>''.
>
> So ``#include "stdio.h"'' is very likely to work, but it can fail if
> there happens to be a file named stdio.h, or rather identified by the
> character sequence ``stdio.h'', in the implementation-defined search
> path.
>
If we want to be *really* pedantic, 7.1.2 says "If a file with the same name as one of the above < and > delimited sequences, not
provided as part of the implementation, is placed in any of the standard places that are
searched for included source files, the behavior is undefined.", so
having a "file" with that "name" in that "place" is Bad even if
`#include <stdio.h>` is used.



--
Army1987 (Replace "NOSPAM" with "email")