Interview question !!!

[Alan Balmer]

Some variables are stored on the stack, with "auto" storage.

And some are not (even assuming there is a stack and you can find
it.). In the OP's code, the compiler may well eliminate the variable
altogether.

In any case, the OP asked if there is a "legal" solution, by which I
assume he meant standards conforming. The answer is no.

 

[Dave Vandervies]

[What to put in fn() to make the printf in this code output something
other than 20]

printf("2");

Now it will print 220 instead of 20.

Butbutbut... the printf in main is still printing 20; the output of the
whole program is now 220, which makes this a good workaround (or cheat,
depending on how you look at it) to get a legal almost-solution to the
problem, but it doesn't quite match the spec given by the OP.


dave

 

[Scott Fluhrer]

I'm going to ignore this. Go to the other thread to talk about this.


Some variables are stored on the stack, with "auto" storage. This is in
contrast to those that are statically or dynamically allocated. If you
can't understand this, then I doubt you actually code in the real world and
work successfully with others.

That's possible that Jack doesn't live in the real world. On the other
hand, it's also possible that Jack has worked with dozens of compilers for
various different architectures, and realizes that different compilers
accomplish the behaviors mandated by the Standard in dramatically different
ways.

How many different compilers have you worked with?

I'll grant you that. But I don't care, because I care about getting things
done, and answering questions. Not trivial technicalities. Show me a
compiler and platform with a stack where this technique does not work. Then
we'll talk.

I just tried it with gcc (on Intel), and it doesn't work (at least if
compiled with -O3). The variable i doesn't appear anywhere on the stack.

And why don't you be constructive, and show me another way to answer the
original poster's question.

I thought he did answer the OP's question -- "you can't"

 

[Noah Roberts]

Would you guys just killfile this bitch already?

And some are not (even assuming there is a stack and you can find
it.). In the OP's code, the compiler may well eliminate the variable
altogether.

In any case, the OP asked if there is a "legal" solution, by which I
assume he meant standards conforming. The answer is no.

Actually I thought he meant would all possible solutions result in you
be procecuted. Unfortunately all 'solutions' are legal, though anyone
that actually does it should be flogged.

 

[Noah Roberts]

Butbutbut... the printf in main is still printing 20; the output of the
whole program is now 220, which makes this a good workaround (or cheat,
depending on how you look at it) to get a legal almost-solution to the
problem, but it doesn't quite match the spec given by the OP.

Actually the OP said "...so that *i* in main prints other than 20." To
which the only correct response might be "Variables don't print, you
fucktard!"

 

[Michael Str.]

void fn (void);

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

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

void fn (void)
{
// add ur code only here so that i in main should print OTHER THAN 20
}
Is there any Legal solution for this?
Thanks,
Ashwath

Really fine interview question !

I see one way to do it.

Function "fn()" should read debug information file of this programm.
It allows retrieve information where variable "i" of function "main"
located.
The debug information file keeps such information. For example if
variable "i"
located on Stack, you can know what is his stack offset. So
backtracking to stack frame of function "main", you can read current
value of "i" in function
"fn()".

But, practically it may be some problems.

First, "i" can be register variable. So I am not sure that you will
read his
right value because you out of scope ( not in "main" ).

Second, it can be optimized out.
If you turn on optimization, compiler may say that "i", once
initialized,
was not modified any time. So, it may produce code like this:


main ()
{
fn ();

printf ("%d\n",20);
}

As you see variable "i" doesn't exist at all!
Howerever, in this case you may get from debug information file
information that variable "i" "optimized out".

And from where came such interview question ?
I guess that such aproach might be used when building some
debugging/monitoring
tools. So such task may be real.

Michael

 

[Joona I Palaste]

Really fine interview question !

I see one way to do it.

Function "fn()" should read debug information file of this programm.
It allows retrieve information where variable "i" of function "main"
located.
The debug information file keeps such information. For example if
variable "i"
located on Stack, you can know what is his stack offset. So
backtracking to stack frame of function "main", you can read current
value of "i" in function
"fn()".

But, practically it may be some problems.

First, "i" can be register variable. So I am not sure that you will
read his
right value because you out of scope ( not in "main" ).

Second, it can be optimized out.
If you turn on optimization, compiler may say that "i", once
initialized,
was not modified any time. So, it may produce code like this:

main ()
{
fn ();

printf ("%d\n",20);
}

As you see variable "i" doesn't exist at all!
Howerever, in this case you may get from debug information file
information that variable "i" "optimized out".

And from where came such interview question ?
I guess that such aproach might be used when building some
debugging/monitoring
tools. So such task may be real.

Aw, geez. You're reading too much into it. We're all trying to find
loopholes in the problem description that allow for trivial standard-
compliant solutions and you have to find a real-world, non-standard-
compliant solution. That's no fun.

 

[Mark Gordon]

On Fri, 31 Oct 2003 06:20:27 GMT

Don't delete the attributions for parts of the message you are replying
to. It makes it harder to follow the thread.

I'm going to ignore this. Go to the other thread to talk about this.

In which case you will not get any help with C from a lot of the more
knowledgeable people on this group should you want any.

Some variables are stored on the stack, with "auto" storage. This is
in contrast to those that are statically or dynamically allocated. If
you can't understand this, then I doubt you actually code in the real
world and work successfully with others.

Ever heard of registers? A
*lot* of good compilers will store automatic variables in registers
where possible rather than on the stack.

Let me guess. You also boil with rage over HTML e-mail, Microsoft
software,

I have a strong dislike of HTML for many reasons. I also dislike a lot
of MS software for usability reasons.

and people who don't format code like yourself.

I only object to people not following project or company formatting
standards since it can make reading the code harder.

I wonder
how any of you get things done -- oh wait, you don't. You're probably
underemployed -- sadly with some decent skills/knowledge -- and sit at
home fiddling with your operating system all day, while people without
such brittle personalities build interesting things that people use.

Now you are just insulting someone simply because they disagree with
you. I suspect that Jack Klein does have a job.

BTW, I'm only replying to ensure that anyone else reading this thread
will see that you are spouting rubbish.

I'll grant you that. But I don't care, because I care about getting
things done, and answering questions. Not trivial technicalities.
Show me a compiler and platform with a stack where this technique does
not work. Then we'll talk.

To give you a specific and common example, gcc version 3.3.2 when used
with the -O3 option. I did this and the compiler produced assembler code
that did not use a local variable in main at all, instead it called fn
then pushed 20 on to the stack. Therefor your suggestion would not have
worked.

My experience with compilers is that many of them will do this type of
optimisation. My experience with various operating systems and hardware
is that in at least some instances an attempt to smash the stack to
modify the actual code (the only way you could do it if decent
optimisation is performed by the compiler) is that it is not always
possible to modify the code since it may be in memory that the running
executable does not have write access to. Given such a common
optimisation and write protected code it is not possible for the code to
change what the printf in main will print on some systems, only to
prevent it from reaching the printf.

And why don't you be constructive, and show me another way to answer
the original poster's question.

Possibly he felt that it had been answered correctly. Certainly his
pointing out how wrong you are could be considered as helping the OP.

 

[Jack Klein]

I'm going to ignore this. Go to the other thread to talk about this.


Some variables are stored on the stack, with "auto" storage.

Some variables have automatic storage duration. On some platforms
they are placed on some sort of stack, on others they are not.

This is in
contrast to those that are statically or dynamically allocated. If you
can't understand this, then I doubt you actually code in the real world and
work successfully with others.

I have almost certainly written far more code in the real world than
you, for some of the largest companies in the world. And I have
worked successfully with many programmers from all over the world.

Let me guess. You also boil with rage over HTML e-mail, Microsoft software,
and people who don't format code like yourself. I wonder how any of you get
things done -- oh wait, you don't. You're probably underemployed -- sadly
with some decent skills/knowledge -- and sit at home fiddling with your
operating system all day, while people without such brittle personalities
build interesting things that people use.

I am gainfully employed at the moment, thank you, and working on quite
an interesting development project. We are building a complex system
using three different processor architectures, all new to our
organization and everyone in it. I picked two of those processors
myself, and had a fair amount of input into the selection of the
third, although I deferred to colleagues with more DSP specific
experience.

I'll grant you that. But I don't care, because I care about getting things
done, and answering questions. Not trivial technicalities. Show me a
compiler and platform with a stack where this technique does not work. Then
we'll talk.

OK, Keil C for the 8051, regarded by many as the best compiler for one
of the most widely used embedded platforms in the world. I guarantee
you that your code won't work there.

And why don't you be constructive, and show me another way to answer the
original poster's question.

In the concept of this newsgroup, which is the platform independent C
standard language, there is no way to do what the poster wants.

If he cares to ask in a group that supports his specific compiler and
platform combination, he might find out about some trick that he can
get his compiler to perform to achieve the effect he asked about. But
it doesn't matter, because it is no longer C.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Jack Klein]

Would you guys just killfile this bitch already?


Actually I thought he meant would all possible solutions result in you
be procecuted. Unfortunately all 'solutions' are legal, though anyone
that actually does it should be flogged.

I didn't actually address the rather loosely used term "legal", since
it is not one defined by C.

No one will arrest you for writing this code. You might well be
arrested afterward, if the code is part of a worm or virus that you
distribute. Or perhaps is Enron accounting software.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[nobody]

"Arthur J. O'Dwyer" <[email protected]> wrote in message

[interview question with no answer]

Here's a *slightly* more interesting variation, which
(even though it admits of stupid preprocessor tricks)
*still* doesn't have any solution AFAICS. Pedant points
to anyone who *can* find a solution.

-Arthur


void fn(void)
{
/* add your code here so that main should print something
* other than 20
*/
}

int main(void)
{
int i = 20;
fn();
printf("%d\n", i);
return 0;
}

printf("2");

Now it will print 220 instead of 20.

Very clever. Just to be closer to OP's requirement (add ur code only here so
that i in main should print OTHER THAN 20), it should rather be

printf("OTHER THAN ");

 

[Roose]

Some variables are stored on the stack, with "auto" storage.

Some variables have automatic storage duration. On some platforms
they are placed on some sort of stack, on others they are not.

Thanks, I'm aware of that, see my earlier posts. Which is why my
stipulation was "compiler and platform with a stack".

I have almost certainly written far more code in the real world than
you, for some of the largest companies in the world. And I have
worked successfully with many programmers from all over the world.

As I said, no more pissing contests. I won't doubt you. But don't doubt
me -- my code could be in your home. I misunderstood your intention at
first -- you were asking what a stack variable is to be purposefully obtuse.
You could have said, "You can't create a stack variable on all platforms".
And I would agree.

OK, Keil C for the 8051, regarded by many as the best compiler for one
of the most widely used embedded platforms in the world. I guarantee
you that your code won't work there.

I'll take your word for it. My point stands. I freely admit that I didn't
make clear in my first post that it could be rejected by a compiler and such
like you mention. That is true, but not terribly interesting to me. The
point is that my post was *useful* to the OP and part of a complete answer,
which would so far from the posts would be:

1) No standard way to do it (from you and others)
2) Mention that on VERY MANY platforms, it is possible to modify the stack,
but of course it is a terrible idea
3) Mention platforms that are exceptions, ones with no stack, ones like
Pyramid that someone brought up
4) Mention that this won't always work because it can be optimized out,
depending on ... (from others in this thread)

Agreed? Of course, you can nitpick if you like.

In the concept of this newsgroup, which is the platform independent C
standard language, there is no way to do what the poster wants.

So the idea behind this newsgroup is to stick to a rigid standard, at the
expense of helping someone with their questions. Just making sure.

Roose

 

[August Derleth]

Don't get in a pissing contest with me. Without knowing anything about you,
I can say with reasonable certainty that my code has been used by more
people than yours, and it could very well be in your house now, if you own a
game console.

So, which corporation do you claim to work for, and can you give us
any proof you work there? And maybe some contact information for your
superiors?

After all, we aren't in a pissing contest, so you shouldn't have any
problems with revealing what you've /really/ accomplished.

 

[Richard Heathfield]

So the idea behind this newsgroup is to stick to a rigid standard, at the
expense of helping someone with their questions. Just making sure.

The idea behind this newsgroup is to stick to a rigid standard, with the
intent of helping people to understand C better. It certainly worked for
me. I have a much wider knowledge of C now than I did when I first started
reading this newsgroup. I had already been programming in C for eight years
or so, and believed myself to be an expert. If this newsgroup had been full
of people spouting whatever junk happened to work on their platform, I'd
probably have enjoyed it much more, but I'd have learned a heck of a lot
less that is actually relevant to my daily experience.

Of course, the newsgroup is less useful than it could be because of the time
spent dealing with the ignorant and the arrogant, but its focus helps it to
overcome even that obstacle, so that it remains a dynamic and powerful
resource, one of the most useful on Usenet.

The subscribers are not about to throw that winning formula away because of
a silly little campaign from a self-confessedly non-existent poster.

 

[Roose]

The idea behind this newsgroup is to stick to a rigid standard, with the
intent of helping people to understand C better. It certainly worked for
me. I have a much wider knowledge of C now than I did when I first started
reading this newsgroup. I had already been programming in C for eight years
or so, and believed myself to be an expert. If this newsgroup had been full
of people spouting whatever junk happened to work on their platform, I'd
probably have enjoyed it much more, but I'd have learned a heck of a lot
less that is actually relevant to my daily experience.

I completely agree that there should be a place for discussion of standard C
only. My response is: comp.lang.c.moderated.

However, when posting there, you'll have to make sure not to post anything
off-topic, which you have had an extreme problem with lately.

Of course, the newsgroup is less useful than it could be because of the time
spent dealing with the ignorant and the arrogant, but its focus helps it to
overcome even that obstacle, so that it remains a dynamic and powerful
resource, one of the most useful on Usenet.

Funny, how with a simple mechanism such as moderation, so much headache can
be avoided. I wonder if they enforce bottom-posting there too? I would be
so happy if they did.

 

[Mark McIntyre]

I completely agree that there should be a place for discussion of standard C
only. My response is: comp.lang.c.moderated.

You seem to have little understanding of how groups are defined. But
if you insist, please feel free to create CLC.moderated, moderate it
yourself, and see how it does. Meanwhile the CLC regulars will almost
certainly continue to post here, keeping to the established topic,
and correcting, ignoring or flaming the arrogant twits who think they
can disregard the established conventions and standards in CLC.

However, when posting there, you'll have to make sure not to post anything
off-topic, which you have had an extreme problem with lately.

FYI discussions of topicality are topical.

 

[Richard Heathfield]

You seem to have little understanding of how groups are defined. But
if you insist, please feel free to create CLC.moderated, moderate it
yourself, and see how it does.

I think Seebs might have a problem with that.

 

[Richard Heathfield]

I completely agree that there should be a place for discussion of
standard C only.

Good. You're looking at it.

My response is: comp.lang.c.moderated.

That's /another/ place for discussion of standard C.

<snip>

 

[CBFalconer]

You seem to have little understanding of how groups are defined.
But if you insist, please feel free to create CLC.moderated,
moderate it yourself, and see how it does. Meanwhile the CLC
regulars will almost certainly continue to post here, keeping
to the established topic, and correcting, ignoring or flaming
the arrogant twits who think they can disregard the established
conventions and standards in CLC.

Uh, Mark, c.l.c.moderated exists, has a (tolerant) moderator, and
is generally available. Any intimation to the contrary is greatly
exagerrated, according to Seebs.

 

[CBFalconer]

So, which corporation do you claim to work for, and can you give
us any proof you work there? And maybe some contact information
for your superiors?

After all, we aren't in a pissing contest, so you shouldn't have
any problems with revealing what you've /really/ accomplished.

This is pointless. We have a troll here, who makes some of the
foulest C coding recommendations ever imagined, and who claims to
work for JPL. I simply do not believe that JPL code could
possibly be Trollsdale infested and still leave any live
Astronauts in the lower 48 states.