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.comg-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 Manjoglekar@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.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/31/87)
In article <607@hydra.riacs.edu> joglekar@hydra.riacs.edu.UUCP (Umesh Joglekar) writes: >I think this is the last problem from 'The C Puzzle Book' - By Alan R. Feuler People should be warned that many examples in The C Puzzle Book are nonportable (usually because of dependency on Reiserisms) or just plain wrong.
Leisner.Henr@Xerox.COM (marty) (07/31/87)
I think that's a little unreasonable. I've been programming in C for 5 years. I don't think I ever wrote anything like "*--*++cpp+3". Programmers who write code like this should be shot -- its unmaintainable -- except as examples of what weird things you can do with a C compiler. At least put in a couple of paranthesis to display the binding (I don't have the binding rules memorized!!) As far as a test goes, I'm not sure what the they are testing for. I through it through my Aztec compiler on Ms/Dos, and was surprised it compiled and executed. I just wonder who thought up that question. If a C programmer can explain things like how to access a variable number of arguments off the stack (a la printf) they know enough about pointers and C to make me happy enough to hire themn. marty GV: leisner.henr NS: martin leisner:henr801c:xerox UUCP: martyl@rocksvax.uucp
ptc@hpindda.HP.COM (Paul Congdon) (07/31/87)
/ hpindda:comp.lang.c / mc68020@gilsys.UUCP (Thomas J Keller) / 11:17 pm Jul 28, 1987 /
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
----------cja@umich.UUCP (Charles J. Antonelli) (08/02/87)
In article <1089@gilsys.UUCP> mc68020@gilsys.UUCP writes: >See if you can determine the output of this program >without actually compiling it: > > ["pointer stew" program deleted] Well, if you replace `****cpp' with `***cpp' you should get what the author intended. As far as measuring someone's ability is concerned, passing this "test" demonstrates some elementary knowledge of pointers, the relationship between pointers and arrays, and p. 48 of K&R. There's a lot more to C software development than that, folks. Charles J. Antonelli Phone: 313-936-9362 44 Adv Tech Laboratories Bldg Internet: cja@crim.eecs.umich.edu The University of Michigan Uucp: {umix,mibte}!umich!eecs.umich.edu!cja Ann Arbor, MI 48109-2210
dsill@NSWC-OAS.arpa (Dave Sill) (08/03/87)
Thomas J Keller <gilsys!mc68020> wrote: > 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: > > [code deleted] > > I do question this as a test, however. That is some pretty esoteric >pointer manipulation there! What do you think? Deja vu (dang! no French characters on this keyboard). Unless I'm mistaken, this "test" was taken from "The C Puzzle Book" by Alan Feuer. Yes, I must say that I think makes an unfair test. If I came across a piece of code like that, I wouldn't even attempt to try to figure it out without at least referring to K&R. Most likely, I'd use cdecl to explain the declarations if it was handy. I guess you're lucky they didn't get their hands on the Obfuscated C Contest winners :-) While I'm here, I'd like to move that the following topics be made taboo for the next say, 10 years: 1) definition of NULL, 2) definitions of TRUE and FALSE, and 3) "structured" or "goto-less" programming. Perhaps the introduction to info-c should briefly mention them so beginners won't need to post to the entire list (and instigate a two-month-long debate). -Dave Sill dsill@nswc-oas.arpa
lmiller@venera.isi.edu (Larry Miller) (08/04/87)
In article <3640001@hpindda.HP.COM> ptc@hpindda.HP.COM (Paul Congdon) writes: >/ hpindda:comp.lang.c / mc68020@gilsys.UUCP (Thomas J Keller) / 11:17 pm Jul 28, 1987 / > > 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; /* Note this line is incorrect. It should be: char ***cpp = cp; i.e., one less * */ > >main() >{ > printf("%s", **++cpp); > printf("%s ", *--*++cpp+3); > printf("%s", *cpp[-2]+3); > printf("%s\n", cpp[-1][-1]+1); >} With this correction, the program compiles and runs correctly, indeed producing rather humorous output.
jollyc@hpwale.HP.COM (08/04/87)
/ hpwale:comp.lang.c / mc68020@gilsys.UUCP (Thomas J Keller) / 12:17 am Jul 29, 1987 / > 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; ^^^^ |||| one too many * than intended? >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: Actually I think it does compile > 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 >---------- From Kernighan & Ritchie p. 89, " Pointers have been lumped with the goto statement as a marvelous way to create impossible-to-understand programs. This is certainly true when they are used carelessly, and it is easy to create pointers that point somewhere unexpected. With discipline, however, pointers can also be used to achieve clarity and simplicity. " That is quite a tough test. Not very palatable, indeed. Jolly Chen (hplabs!hpwU> l novalie
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."
pls@sortac.UUCP (Pat Sullivan) (08/07/87)
+/ hpindda:comp.lang.c / mc68020@gilsys.UUCP (Thomas J Keller) / 11:17 pm Jul 28, 1987 /
+ ... and she popped this "C test" on me.
(I'm not going to repeat the program, it's been in too many articles already).
I tried to find humor in the output. On AT&T 3B processors, the output is
"POINTINT POINT"; am I missing the point (groan!) or have I illustrated
another reason to avoid tacky coding techniques?
============================================================
Pat Sullivan - {akgua|ihnp4}!sortac!pls - voice 404-257-7382gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/07/87)
In article <5192@utcsri.UUCP> flaps@utcsri.UUCP (Alan J Rosenthal) writes: >>#include <stdio.h> >Huh? Not used in the program below. Sure it is -- printf() is used. Although it is not REQUIRED that <stdio.h> be included to use printf(), it may very well be beneficial to do so.
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.
-scottkarl@haddock.ISC.COM (Karl Heuer) (08/07/87)
In article <5192@utcsri.UUCP> flaps@utcsri.UUCP (Alan J Rosenthal) writes: >>#include <stdio.h> >Huh? Not used in the program below. The program used printf(), which is a stdio function. Therefore it is appropriate to #include <stdio.h>. Those of us who are familiar with stdio internals know that virtually all pre-ANSI implementations will produce the correct result without this line, but does that justify omitting it? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
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)
alastair@geovision.UUCP (Alastair Mayer) (08/12/87)
In article <8619@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >Deja vu (dang! no French characters on this keyboard). Unless I'm Deja vu indeed! This message showed up at least twice (two copies) in my newsfiles today, and two or three times yesterday. Is somebody's system stuttering, echoing, or what? Or am I the only place this happened to? -- Alastair JW Mayer BIX: al UUCP: ...!utzoo!dciem!nrcaer!cognos!geovision!alastair "He sure looks like plant food to me." -- Audrey II
hamilton@uxc.cso.uiuc.edu.UUCP (08/12/87)
karl@haddock says: > In article <5192@utcsri.UUCP> flaps@utcsri.UUCP (Alan J Rosenthal) writes: > >>#include <stdio.h> > >Huh? Not used in the program below. > > The program used printf(), which is a stdio function. Therefore it is > appropriate to #include <stdio.h>. Those of us who are familiar with stdio > internals know that virtually all pre-ANSI implementations will produce the > correct result without this line, but does that justify omitting it? <quibble mode on> printf predates stdio. true, the semantics have changed a bit since the advent of stdio (previously, we didn't need sprintf and fprintf; printf did it all!), and a discussion of stdio would be incomplete without covering printf, but including stdio.h solely for printf is a bit paranoid. next, you'll want me to #include <time.h> when i use ctime(). wayne hamilton U of Il and US Army Corps of Engineers CERL UUCP: {ihnp4,seismo,pur-ee,convex}!uiucuxc!hamilton ARPA: hamilton@uxc.cso.uiuc.edu USMail: Box 476, Urbana, IL 61801 CSNET: hamilton%uxc@uiuc.csnet Phone: (217)333-8703 CIS: [73047,544] PLink: w hamilton
am@cam-cl.UUCP (08/14/87)
In article <6243@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>>#include <stdio.h> >>Huh? Not used in the program below. > >Sure it is -- printf() is used. Although it is not REQUIRED that ><stdio.h> be included to use printf(), it may very well be beneficial >to do so. The contradicts ANSI draft: printf has a varargs prototype and therefore must be given a prototype with ... not int printf() assumed.
guy%gorodish@Sun.COM (Guy Harris) (08/15/87)
> printf predates stdio. true, the semantics have changed a bit since > the advent of stdio (previously, we didn't need sprintf and fprintf; > printf did it all!), and a discussion of stdio would be incomplete > without covering printf, but including stdio.h solely for printf is > a bit paranoid. next, you'll want me to #include <time.h> when i use > ctime(). Why, yes, as a matter of fact, I do. One hopes that with the advent of ANSI C, system include files will include full prototype declarations of the functions in the package to which that include file belongs. (Unfortunately, in general there isn't a simple match between packages and include files, but in some cases there is.) Function prototypes (assuming the compiler does the Right Thing with conversions such as conversions between pointer and integral types and between different pointer types, namely printing a warning or error) can cause some errors that now are mechanically caught only by running "lint" to be caught when compiling. This is a Good Thing. Even *without* full prototypes, including <time.h> when you use "ctime" will at least fetch the declaration of "ctime", so if you forget to declare it as returning "char *" your code will still be correct (and work on machines where pointers and "int"s are not the same size). Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (08/15/87)
In article <175400004@uxc.cso.uiuc.edu> hamilton@uxc.cso.uiuc.edu writes: >next, you'll want me to #include <time.h> when i use ctime(). Yes, as a matter of fact. Both X3.159-198x and IEEE 1003.1 permit the application code to omit the header that is supposed to declare the type of a library function if and only if the application code itself correctly declares the type; this is not always possible without some definitions from the header. In the case of printf(), IF you can correctly declare its type without <stdio.h>, then having done so you could omit <stdio.h>. However, if there happened to be a spiffy macro implementation of the function defined in <stdio.h>, you would be missing out on it thereby, so it is not generally advisable to circumvent the declarations from the standard headers. The other problem is, printf() is a variable- arguments function, and as such will require a correct function prototype to be in scope in an ANSI C environment. Although one could declare the type "by hand" using #if __STDC__ to accommodate the differences between old C and ANSI C, it is much simpler and more convenient to let <stdio.h> take care of getting the declaration right.