mc68020@gilsys.UUCP (Thomas J Keller) (07/29/87)
I just had a strange experience today. I went to see a head hunter about
an opening she wanted me to consider, and she popped this "C test" on me.
Most of it was pretty straight forward, but the last question on the test
was a **BITCH**. See if you can determine the output of this program
without actually compiling it:
#include <stdio.h>
char *c[] = { "ENTER", "NEW", "POINT", "FIRST" };
char **cp[] = { c+3, c+2, c+1, c };
char ****cpp = cp;
main()
{
printf("%s", **++cpp);
printf("%s ", *--*++cpp+3);
printf("%s", *cpp[-2]+3);
printf("%s\n", cpp[-1][-1]+1);
}
(actually, the program AS PRESENTED probably wouldn't have compiled, as
the *c declaration was as follows:
char *c[] = { "ENTER", "NEW", "POINT", "FRIST", };
)
NOTE: as I entered it here, it *DOES* compile, and the output is fairly
humorous.
I do question this as a test, however. That is some pretty esoteric
pointer manipulation there! What do you think?
--
Tom : The conservatives always grouse about "Law & Order" when the liberals
Keller : break the law...when the Reagan Admin. does it, it's PATRIOTISM!
UUCP : {ihnp4,ames,qantel,sun,amdahl,lll-crg,pyramid}!ptsfa!gilsys!mc68020
BITNET : ptsfa!gilsys!mc68020@ames.com
g-rh@cca.CCA.COM (Richard Harter) (07/30/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes:
- I just had a strange experience today. I went to see a head hunter about
- an opening she wanted me to consider, and she popped this "C test" on me.
- Most of it was pretty straight forward, but the last question on the test
- was a **BITCH**. See if you can determine the output of this program
- without actually compiling it:
[... weird code deleted ...]
Speaking as a programmer, my reaction would be very simple -- I do
not write code like this, and I have no desire to deal with code like this,
and no intention of considering the test. Speaking as an employer [I run
a small software company -- CCA is the machine I am running on] I would not
deal with any employment agency that used this test.
Now I have no objection to clever and subtle code, in its place --
I've written a fair bit of it myself upon occasion. And I'm moderately
fond of ingenious puzzles. But ingenuity and complexity should only be
exercised when needed. This test represents a conception of programming
that I feel is fundamentally unsound. How's that for dogmatism?
--
In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
Richard Harter, SMDS Inc.
chris@mimsy.UUCP (Chris Torek) (07/30/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: >... See if you can determine the output of this program without actually >compiling it: > >#include <stdio.h> > >char *c[] = { "ENTER", "NEW", "POINT", "FIRST" }; >char **cp[] = { c+3, c+2, c+1, c }; >char ****cpp = cp; Error: Illegal type combination: attempt to assign pointer to pointer to pointer to char (char ***) to object of type pointer to pointer to pointer to pointer to char (char ****). Remember, the type of `cp' is `array 4 of pointer to pointer to char'; when the name `cp' is used in a context other than `sizeof', this is altered by changing `array N of' to `pointer to', which gives `pointer to pointer to pointer to char'. That PCC compiles this without complaint simply means there is a bug in PCC. Guy Harris posted a fix not long ago. Assuming this was a typographic error fixes up the example (which happens to work on any machine where the sizes of (char ****), (char ***), (char **), and (char *) are equal). > (actually, the program AS PRESENTED probably wouldn't have compiled, as > the *c declaration was as follows: > > char *c[] = { "ENTER", "NEW", "POINT", "FRIST", }; > > ) There is nothing wrong with this. `c' is `array 4 of pointer to char', as before. (I assume "FRIST" is a typographic error, though in fact it does not affect the output.) Back to the code, changing the last declaration to `char ***cpp': printf("%s", **++cpp); ++cpp changes the value of cpp from &cp[0] to &cp[1]; *&cp[1] == cp[1]; cp[1] == &c[2]; *&c[2] is "POINT". printf("%s ", *--*++cpp+3); ++cpp changes its value from &cp[1] to &cp[2]; *&cp[2] == cp[2]. --cp[2] changes its value from &c[1] to &c[0]; *&c[0] == c[0], which points to the first character of "ENTER"; adding three points to the second E, so we print "ER ". printf("%s", *cpp[-2]+3); Cpp now points to &cp[2]; two back from this is &cp[0]. One dereference gives *&cp[0] == &c[3], another gives just c[3] which points to the F in "FIRST"; adding three we print "ST". printf("%s\n", cpp[-1][-1]+1); Cpp still points to &cp[2]. cpp[-1] is cp[1] or &c[2]; (&c[2])[-1] is the same as (c+2)[-1] or *((c+2)+(-1)) or *(c+1), which points at the N in "NEW". Adding 1, we get "EW". And now I have finished my bread and will go make some mixed vegetables to fill out breakfast. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
mkhaw@teknowledge-vaxc.ARPA (Michael Khaw) (07/30/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes:
->
-> I just had a strange experience today. I went to see a head hunter about
->an opening she wanted me to consider, and she popped this "C test" on me.
...
->#include <stdio.h>
->
->char *c[] = { "ENTER", "NEW", "POINT", "FIRST" };
->char **cp[] = { c+3, c+2, c+1, c };
->char ****cpp = cp;
->
->main()
->{
-> printf("%s", **++cpp);
-> printf("%s ", *--*++cpp+3);
-> printf("%s", *cpp[-2]+3);
-> printf("%s\n", cpp[-1][-1]+1);
->}
...
-> I do question this as a test, however. That is some pretty esoteric
->pointer manipulation there! What do you think?
1) Apparently, you haven't read _The C Puzzle Book_. This example is straight
out of the book, from a puzzle titled "Pointers and Arrays 4: Pointer Stew",
except for an error (see point 3).
2) I would have said, "this is unmaintainable code and whoever wrote this
should be drawn, quartered, boiled in oil, skewered and burned at the stake".
Or, "Are you using this example with Alan Feuer's permission?"
3) "cpp" should be declared as: char ***cpp = cp;
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {hplabs|sun|ucbvax|decwrl|sri-unix}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA
ch Man
joglekar@riacs.edu (Umesh Joglekar) (07/30/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: > I just had a strange experience today. .... I think this is the last problem from 'The C Puzzle Book' - By Alan R. Feuler I would agree with Alan Feuler That this is quite a stew of pointers. - Umesh D. Joglekar _________________________________________________________________________________ { anything sensible like ...ames!} riacs!joglekar ARPANET: joglekar@ricas.edu
snoopy@doghouse.gwd.tek.com (Snoopy) (07/31/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: | See if you can determine the output of this program | without actually compiling it: | | #include <stdio.h> | | char *c[] = { "ENTER", "NEW", "POINT", "FIRST" }; | char **cp[] = { c+3, c+2, c+1, c }; | char ****cpp = cp; | | main() | { | printf("%s", **++cpp); | printf("%s ", *--*++cpp+3); | printf("%s", *cpp[-2]+3); | printf("%s\n", cpp[-1][-1]+1); | } It works much better if you use char ***cpp = cp; instead of char ****cpp = cp; Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com "And it's a middle-endian machine with trinary logic." "They would do that."
fnf@mcdsun.UUCP (Fred Fish) (07/31/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: > I just had a strange experience today. I went to see a head hunter about >an opening she wanted me to consider, and she popped this "C test" on me. >Most of it was pretty straight forward, but the last question on the test >was a **BITCH**. See if you can determine the output of this program >without actually compiling it: > [program deleted] Yes, if you could have answered this you would have definitely been a 100% certified C wizard, probably also a certified psychic as well. I finally gave up and cheated by compiling and running it on my Sun and this is what it printed: POINTINT printf.c 1.1 86/07/07 SMIPOINT Of course, after I made a rather minor change to the code it printed something a little less cryptic... :-) :-) -Fred -- = Drug tests; just say *NO*! = Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA = seismo!noao!mcdsun!fnf (602) 438-3614
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/31/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: >char ****cpp = cp; The above has one too many *s. > printf("%s ", *--*++cpp+3); The operand of -- is not a modifiable lvalue of scalar type, so this expression is illegal. >} This program returns a random value to the invoking environment. > (actually, the program AS PRESENTED probably wouldn't have compiled, as > the *c declaration was as follows: > char *c[] = { "ENTER", "NEW", "POINT", "FRIST", }; > ) Shouldn't that be "FIRST"? No, that's one thing they did correctly. C has always allowed the extra comma after the last initializer in an initializer list. The main reason for that is uniformity, which can be important when automatically generating C source code or when manually editing such a list. > I do question this as a test, however. That is some pretty esoteric >pointer manipulation there! What do you think? It's clear that that style is not acceptable for production code, but presumably the test was intended only to determine how well you knew the rules for C pointers. It's quite possible that they were also trying to see if you could spot the errors in the code. It's hard to say what's "fair" in a test; it mostly depends on what the test is attempting to determine. My previous employer used an applicant screening test for EEs and I helped draw up an analogous one for software engineers. One of our test questions was basically asking for a solution to the problem of clipping a line segment to a rectangular window, and the specification was left fairly loose on purpose. We were not looking for a solution (we already had one), but rather for evidence of how the applicant went about approaching such a problem. In the test you quoted, I would give points for itemizing the actual storage cells for the variables, writing their initial values, and then updating their contents as they were modified during the run sequence. I would also give points for rewriting cp as &cp[0], and so forth. Identifying the bugs would score points, too.
flaps@utcsri.UUCP (08/05/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP (Thomas J Keller) writes: > I just had a strange experience today. I went to see a head hunter about >an opening she wanted me to consider, and she popped this "C test" on me. >... >#include <stdio.h> Huh? Not used in the program below. >char *c[] = { "ENTER", "NEW", "POINT", "FIRST" }; [etc] >main() >{ [unbelievable garbage with pointers, prints "POINTER STEW\n"] >} Well, I made a mistake working it out near the end, but I wasn't being very careful. I _did_ get all the precedence right without looking it up, though. But, really this program should be written as: main() { printf("POINTER STEW\n"); } or even better without a program as simply alias <whatever> echo POINTER STEW Since you mention it, I had an interesting test at a job I applied for just this very morning. They asked what the output from the following program would be: main() { printf("%s\n",0x637F3A0); } You see, at that address in their machines the string "POINTER STEW\n" was invariably stored. Fortunately I had just been reading comp.lang.c so I got it right. Actually, the main problem with this program was that they missed the cast, it should have been "(char *)0x637F3A0". -- // Alan J Rosenthal // \\ // flaps@csri.toronto.edu, {seismo!utai or utzoo}!utcsri!flaps, \// flaps@toronto on csnet, flaps at utorgpu on bitnet. "To be whole is to be part; true voyage is return."
scott@applix.UUCP (Scott Evernden) (08/07/87)
Maybe y'all saw this a few months back in comp.lang.c in the "1987 International Obfuscated C Code Contest". For those who didn't, I liked this one: main() { printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);} Best One Liner David Korn ...!ihnp4!ulysses!dgk AT&T Bell Labs MH 3C-526B, AT&T Bell Labs Murray Hill, NJ 07974 USA System(s): UN*X Passes BSD and UTS lint. -scott
mouse@mcgill-vision.UUCP (08/08/87)
In article <1089@gilsys.UUCP>, mc68020@gilsys.UUCP (Thomas J Keller) writes: [ headhunter who popped a C test, last question of which asks what the output of this program is: ] > #include <stdio.h> > char *c[] = { "ENTER", "NEW", "POINT", "FIRST", }; > char **cp[] = { c+3, c+2, c+1, c }; > char ***cpp = cp; [in mc68020's posting, this was "char ****cpp"; presumably *** is right] > main() > { printf("%s", **++cpp); > printf("%s ", *--*++cpp+3); > printf("%s", *cpp[-2]+3); > printf("%s\n", cpp[-1][-1]+1); > } > I do question this as a test, however. That is some pretty esoteric > pointer manipulation there! What do you think? What do I think? I think the headhunter has read the C Puzzle Book and decided it'd be a good test for aspiring C programmers to lift a few questions. (I can't be certain, because I read the book a long time ago, but the strings of the c array sound familiar, and the output matches.) I think it is not a particularly relevant question. All it tests is your ability to follow instructions by rote, since I doubt anyone would do this except by keeping track of all the pointers the way the machine would. If I were hiring a C programmer, I doubt I would want this sort of robot. Nor, were I job-hunting, would I want to work to work for someone who wanted such a robot. der Mouse (mouse@mcgill-vision.uucp)