> -all functions prototyped, starting with kernel. this patch > provides an > opporunity to explore what if any kernel compilers suck. > -all functions in kernel not being used outside local file actually > changed to "static" > -all prototypes for use outside file actually in header and > correct, not > just ()
Sounds great to me! Standard prototypes or using _P()? Worst case scenario can hardwire _P() to blank when doing kernel compiles on affected systems. > and then the rest of the code: > -more or less same deal, but obviously not changing bits of the API to > "static" even if nothing is obviously "using" them > -new header for prototypes, or "abuse" the existing main > header for each > system? (leaning toward the latter) Well, having them in the main header for each system (I presume you mean vos/pts/etc. for the system) seems like a reasonable approach to me, however, I'd like to see them organized in the headers consistently. I.e. always in a block at the end of the header, or something like that. Right now, they are pretty badly scattered. Similarly in some of the source files, there are scattered places where a .c file will include a prototype for a function outside that file, I'd like to see that go away. I personally like to autogenerate prototypes (cfunc) but I think that'd be a bit messy here, although it would make using separate .h files for prototypes really easy. I might add to that list - get the data type usage of the routines (including APIs) consistent. I started to do some of this way back, and got that committed, but there's a ton left to do. Also use of 'const' where appropriate. What about ANSI v. K&R on the routines themselves? I'll definately dig in on this when you're ready to move on it, cause it's the type of cleanup/rework stuff I usually enjoy working on. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
