mouse@mcgill-vision.UUCP (der Mouse) (05/11/87)
I have two comments/questions. One is about the man pages in section 3, the other is about software distribution in general. Why do so many of the man pages (eg inet(3N), the one which directly prompted this posting) list the necessary include files to use the routines in question, *except* that (almost?) NONE of them mention <sys/types.h>, which is required by maybe half of them? The only sure way I've found to tell whether types.h is required is to try it! For that matter, why are the include files organized as they are? It seems to me that it would be much more intelligent for each .h file to look like #ifndef <identifier-unique-to-this-.h-file> #define <identifier-unique-to-this-.h-file> ...body of the .h... #endif and then instead of requiring the user to remember which files have to be included and (most especially) what order they have to be included in, simply make every .h file include every other .h file necessary? The slight extra cost (cpp skipping an entire file in a false #if) would be more than balanced by the saved programmer time and saved extra runs (oh yes %^^%#$%@ that's right I need <sys/time.h> for <sys/proc.h> to work!) of cc? Even worse, sometimes they *do* include the needed include file, but it can't stand being included multiple times! Eg, if I include <sys/resource.h> and things are fine, then I add <sys/user.h> it breaks because user.h includes resource.h explicitly! The other question is: WHY is all the source under /usr/src distributed mode 444?? Whenever I make a local copy of it (to fix a bug, for example) the first thing I have to do is change it all to 644! der Mouse (mouse@mcgill-vision.uucp)
chris@mimsy.UUCP (05/15/87)
In article <766@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >Why do so many of the man pages ... list the necessary include files >to use the routines in question, *except* that (almost?) NONE of them >mention <sys/types.h>, ...? Would you believe, `someone forgot'? (No? How about `we wanted to annoy you'? :-) ) >The other question is: WHY is all the source under /usr/src >distributed mode 444?? SCCS. If the source is not writable, you cannot forget to check out a copy before changing it. If you set strict locking in RCS, it will do the same thing for (or to) you. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
thomas@spline.UUCP (05/16/87)
In article <766@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >The other question is: WHY is all the source under /usr/src >distributed mode 444?? Because it's all maintained under RCS, and when you 'ci' (check in) a file, it makes it unwritable until you 'co' (check out) it. =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@cs.utah.edu)
dhb@rayssd.UUCP (05/16/87)
In article <766@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: > >For that matter, why are the include files organized as they are? It >seems to me that it would be much more intelligent for each .h file to >look like > >#ifndef <identifier-unique-to-this-.h-file> >#define <identifier-unique-to-this-.h-file> >...body of the .h... >#endif > >and then instead of requiring the user to remember which files have to >be included and (most especially) what order they have to be included >in, simply make every .h file include every other .h file necessary? I have used this method several times myself but have finally found what I think is the ultimate solution. I just finished installing fourth generation make (from the ATT toolchest) and included in the distribution was a new release of cpp. One of the features of this new release is that it detects when a file has already been included and doesn't bother reading it again. Using this scheme it becomes very simple to have an include file include all the other files that it needs with no worry about including duplicate files. It makes life so much easier and it's a lot cleaner than the strange looking ifdefs. I know that not everyone has access to this version of cpp but it's probably in the latest sysV release and maybe it can be picked up by Berkeley for their next release. -- David H. Brierley Raytheon Submarine Signal Division 1847 West Main Road Portsmouth, RI 02871 Phone: (401)-847-8000 x4073 Internet: dhb@rayssd.ray.com Uucp: {cbosgd, gatech, linus, mirror, necntc, uiucdcs} !rayssd!dhb
guy@gorodish.UUCP (05/16/87)
> I just finished installing fourth generation make (from the ATT toolchest) > and included in the distribution was a new release of cpp. ... > I know that not everyone has access to this version of cpp but it's > probably in the latest sysV release... Why do you assume that? As a matter of fact, neither it or the Fourth Generation "make" are in the latest System V release. The "cpp" in S5R3 is the one in S5R2 with the addition of support for "#elif", some miscellaneous bug fixes, and support for a few new command-line options. It might be nice if the 4GM "cpp" - perhaps modified to be an ANSI C preprocessor (according to another posting I've seen, it supports a "gluing" operator that is, unfortunately, different from the ANSI C one) - ended up in a release at some point; however, things seem to trickle into S5 *very* slowly, so it may be a while.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (05/17/87)
In article <1032@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David Brierley) writes:
-... I just finished installing
-fourth generation make (from the ATT toolchest) and included in the
-distribution was a new release of cpp. One of the features of this
-new release is that it detects when a file has already been included
-and doesn't bother reading it again.
-...
-I know that not everyone has access to this version of cpp but it's
-probably in the latest sysV release and maybe it can be picked up by
-Berkeley for their next release.
I hope not! This is yet another example of people ASSUMING a certain
model for usage of a utility, then FORCING the model on you. When I
want something #included at a spot, I want it #included at that spot.
I do not want some smart-ass CPP assuming it knows what I want better
than I do. And yes, at times it does make a difference which method
is used.
Note that such a smart-ass CPP is in violation of the dpANS mp mp rwl@uvacs.CS.VIRGINIA.EDU (Ray Lubinsky) (05/21/87)
> The other question is: WHY is all the source under /usr/src > distributed mode 444?? Whenever I make a local copy of it (to fix a > bug, for example) the first thing I have to do is change it all to 644! Mode 444 seems like a reasonable precaution to keep junior roots from wiping all their man pages. I used to be annoyed by this to until I discover the ``noro'' option to vi(1). Now I keep stuff that isn't changed often (like the man pages) as mode 444 and set ``noro'' when editing one of them. -- | Ray Lubinsky Department of Computer Science, University of Virginia | | UUCP: ...!seismo|virginia!uvacs!rwl | | CSNET: rwl@cs.virginia.edu | | BITNET: rwl8y@virginia |
ken@rochester.ARPA (Ken Yap) (05/21/87)
|Mode 444 seems like a reasonable precaution to keep junior roots from wiping all |their man pages. I used to be annoyed by this to until I discover the ``noro'' |option to vi(1). Now I keep stuff that isn't changed often (like the man pages) |as mode 444 and set ``noro'' when editing one of them. This doesn't help if root says "rm -f foo.1". It's probably co'ed from a RCS'ed file, that's all. Ken
cuccia@ucbarpa.Berkeley.EDU (Nick Cuccia) (05/23/87)
In article <27955@rochester.ARPA> ken@rochester.UUCP (Ken Yap) writes: >|Mode 444 seems like a reasonable precaution to keep junior roots from wiping all >|their man pages. I used to be annoyed by this to until I discover the ``noro'' >|option to vi(1). Now I keep stuff that isn't changed often (like the man pages) >|as mode 444 and set ``noro'' when editing one of them. > >This doesn't help if root says "rm -f foo.1". It's probably co'ed from >a RCS'ed file, that's all. > Ken All man pages and documents that are part of 4.3BSD were placed under SCCS, something that wasn't done for much of the documentation in previous 4BSD releases. I was the one who did the work for some of them (/usr/doc/ps2). --Nick
peter@utah-gr.UUCP (05/28/87)
> The other question is: WHY is all the source under /usr/src > distributed mode 444?? Whenever I make a local copy of it (to fix a > bug, for example) the first thing I have to do is change it all to 644! You should use either SCCS, RCS or some other software maintenance system when you are modifying sources. Proper use of these tools will make this complaint disappear, AND make things much simpler to maintain. It sure beats going back to those backup tapes!
mouse@mcgill-vision.UUCP (06/05/87)
>> WHY is all the source under /usr/src distributed mode 444?? >> Whenever I make a local copy of it (to fix a bug, for example) the >> first thing I have to do is change it all to 644! > You should use either SCCS, RCS or some other software maintenance > system when you are modifying sources. The distributions don't come as SCCS or RCS files (or the analogue for any other such system)! If they did, I could understand this. > ...use of these tools will...make things much simpler to maintain. > It sure beats going back to those backup tapes! Back to the backups for what? Buggy source? If I want the original it's right there under /usr/src; my copy is under /local/src. der Mouse (mouse@mcgill-vision.uucp)