On Tue, Sep 10, 2002 at 07:53:10PM +0100, Nicholas Clark wrote: > On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote: > > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since > > the prototypes are hidden in the C file, not in a shared header file, the > > compiler doesn't warn about them.) Upon reflection, however, since the > > extern prototypes in a C file not in a header === bad. > > Reward of 1 coffee to each person who can give any reason when it is not bad. > > Can we make it a coding standard that we never define prototypes for external > functions in source files. If we need to share prototypes between more than > one source file for parrot private functions then we should use a private > header file. If we need prototypes for other people's missing prototypes then > we should do that in some sort of common header file.
My bad. I was mindlessly propagating a workaround for a probably long-dead problem that was hinted at in a comment. However, I'm unsure of what the "correct" solution is. I can certainly emit the prototypes in parrot/include/core_pmcs.h, but I long ago made pmc2c.pl emit a CLASSNAME.h file in the classes/ subdirectory. I would really rather use those files, but the directory structure isn't right. All parrot ..h files are now included with #include "parrot/...", and the best we could do with the classes/ subdir is #include "classes/...". I could have them autogenerated in include/parrot/classes/, but I don't know if people want PMC stuff mixed in with the rest of Parrot code. I could autogenerate them in classes/parrot/classes/ or just classes/parrot/. Or I could take the path of least resistance and write the prototypes in include/parrot/core_pmcs.h, but that just makes it easier to make the same int/INTVAL mistake again, or others similar to that. Votes? Btw, can anyone advise me on getting an actual account on a natively 64-bit machine somewhere? I don't really like the model of checking in broken code, waiting for the tinderbox to get around to testing it, blindly fixing things, and repeating. Especially when the tinderbox machines frequently die for random reasons unrelated to the code.
