krupczak@secola.Columbia.NCR.COM (Bobby Krupczak) (03/21/91)
Hi! I should have been more specific about my previous posting regarding nice'ing processes. I do not want to nice() my own process (I want to nice to nice others), hence the confusion. After investigating the priocntl() series of functions, I determined that this was not the way to go. In V.4, there is a /proc file system. If you look in this directory on any V.4 box, there will be files named by numbers. These files correspond to running processes. By opening these files and doing double-secret ioctl()'s, you can get & set process information, look into a process's memory, and probably screw it up pretty bad if you wanted to. I found a ioctl() option that will allow one to set the nice value of a process. Unforntunately, the header files do not tell what the arguments are. More on this exciting story as late breaking news develops. Bobby
wescott@Columbia.NCR.COM (Mike Wescott) (03/22/91)
In article <318@secola.Columbia.NCR.COM> krupczak@secola.Columbia.NCR.COM (Bobby Krupczak) writes: > In V.4, there is a /proc file system. [...] > I found > a ioctl() option that will allow one to set the nice value of a process. > Unforntunately, the header files do not tell what the arguments are. See proc(4) in the FM: Information and control operations are provided through ioctl. These have the form: #include <sys/types.h> #include <sys/signal.h> #include <sys/fault.h> #include <sys/syscall.h> #include <sys/procfs.h> void *p; retval = ioctl(fildes, code, p); The argument p is a generic pointer whose type depends on the specific ioctl code. Where not specifically mentioned below, its value should be zero. <sys/procfs.h> contains [...] PIOCNICE* The traced process's nice priority is incremented by the amount contained in the int addressed by p. Only the super-user may better a process's priority in this way, but any user may make the priority worse. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
torek@elf.ee.lbl.gov (Chris Torek) (03/24/91)
In article <1991Mar21.141753.28726@nncrcae.Columbia.NCR.COM> wescott@Columbia.NCR.COM (Mike Wescott) writes: [quoting proc(4) from some SVR4 system] > The argument p is a generic pointer whose type depends on > the specific ioctl code. Where not specifically mentioned > below, its value should be zero. Whoop! Whoop! Confusion alert! Does this mean `the argument p should be a null-pointer-to-char', or does it mean `the argument p should be a pointer-to-char holding the address of an int whose value is zero', or does it mean something else? It is impossible for p to have the `value ... zero' because p is a pointer---Pointers Are Not Integers---but this means we must guess at what was really meant. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
bhoughto@nevin.intel.com (Blair P. Houghton) (03/24/91)
In article <11393@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: Or was this someone poking around in Chris' office while his xrn happened to be displaying comp.lang.c... >In article <1991Mar21.141753.28726@nncrcae.Columbia.NCR.COM> >wescott@Columbia.NCR.COM (Mike Wescott) writes: >[quoting proc(4) from some SVR4 system] >> The argument p is a generic pointer whose type depends on >> the specific ioctl code. Where not specifically mentioned >> below, its value should be zero. > >Whoop! Whoop! Confusion alert! Pooh, pooh; pedantry alert... >Does this mean `the argument p should be a null-pointer-to-char', or >does it mean `the argument p should be a pointer-to-char holding the >address of an int whose value is zero', or does it mean something else? > >It is impossible for p to have the `value ... zero' because p is a >pointer---Pointers Are Not Integers---but this means we must guess at >what was really meant. Braap. The "integer constant expression" 0 is a "null pointer constant" and becomes the type of the pointer to which it is assigned or with which it is compared. A pointer may very well have the value 0 [1], and when it does it is a "null pointer." This is all in the standard, ANSI X3.159-1989, at sec. 3.2.2.3, p. 38, ll. 1-4. It's clear what is meant by what he said. [2] --Blair "Plplplplpl... :-P' " [1] Or any other value an implementor wants it to; check out p. 37, l. 38 to see the word "value" used to refer to the value of a pointer. 0, however, is the only one with a specified integral representation. [2] If in fact he meant "the value of the object to which it points should be 0", then he's most definitely NOT said it.
caf@omen.UUCP (Chuck Forsberg WA7KGX) (03/25/91)
In article <1991Mar21.141753.28726@nncrcae.Columbia.NCR.COM> wescott@Columbia.NCR.COM (Mike Wescott) writes:
- PIOCNICE*
- The traced process's nice priority is incremented by the
- amount contained in the int addressed by p. Only the
- super-user may better a process's priority in this way, but
- any user may make the priority worse.
^^^^^^^^
I can see it now. Nice wars.
--
"Compared to tanks, journalists are cheap - and you get more for your money."
- Saddam Husseingoehring@gnu.ai.mit.edu (Not Marc Spencer) (03/26/91)
In article <11393@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes:
Whoop! Whoop! Confusion alert!
Does this mean `the argument p should be a null-pointer-to-char', or
does it mean `the argument p should be a pointer-to-char holding the
address of an int whose value is zero', or does it mean something else?
It is impossible for p to have the `value ... zero' because p is a
pointer---Pointers Are Not Integers---but this means we must guess at
what was really meant.
0, cast to any pointer type, is a valid pointer, by definition.
--
Help stamp out vi in our lifetime!
Scott Goehring goehring@gnu.ai.mit.edu
On exile in Indianapolis, INtorek@elf.ee.lbl.gov (Chris Torek) (03/27/91)
>In article <11393@dog.ee.lbl.gov> I wrote: >>It is impossible for p to have the `value ... zero' because p is a >>pointer---Pointers Are Not Integers---but this means we must guess at >>what was really meant. (Incidentally, I forgot to add that P.A.N.I. is an anagram for `pain', which is appropriate.) In article <GOEHRING.91Mar25143457@gnu.ai.mit.edu> goehring@gnu.ai.mit.edu writes: >0, cast to any pointer type, is a valid pointer, by definition. Aye ... but once cast to a pointer type, it is no longer 0. This is kind of like saying `pi, cast to any integer type, is a valid integer'. It is, but you can no longer call it `pi'. It is important to note that nowhere is it stated that the bit pattern for any given `kind' of null pointer is all zeroes. In fact, there are machines on which: union { long l; int *ip; char *cp; } u1, u2; u1.ip = 0; u2.cp = 0; (void) printf(u1.l == u2.l ? "same\n" : "different\n"); prints `different'. A few of them have even run Unix derivatives (after fixing hundreds of incorrect pointer usages). The C language definition guarantees only that: * the integer constant 0, cast to any pointer type, produces a valid pointer value that compare unequal to the address of any valid of that type (including objects created via a successful call to malloc()); * when compared to the integer constant 0, a pointer of any type compares as equal if and only if that pointer was previously assigned the integer constant 0, or the integer constant 0 cast to the appropriate pointer type; * any two null pointers of any type, when cast to a common type, compare equal; and a few other minor points. It specifically does NOT say that any particular null pointer has the same bit pattern as any other particular null pointer, nor that any particular null pointer has the integer value 0. If you do not believe that the phrase `a zero pointer' is misleading, read comp.lang.c for a few weeks, or comp.unix.* for a few months or years, and watch for Frequently Asked Questions about null pointers or about the arguments to select(). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
torek@elf.ee.lbl.gov (Chris Torek) (03/27/91)
In article <3424@inews.intel.com> bhoughto@nevin.intel.com (Blair P. Houghton) writes: >It's clear what is meant by what [the quoted part of the manual] said. It is clear from the confusion over the following wording from `select' that it is not at all clear what a `zero pointer' is: Any of .IR readfds , .IR writefds , and .I exceptfds may be given as zero pointers if no descriptors are of interest. In this case `zero pointer' means *both* `a pointer to an int-0' and `a null pointer to int'! Both work; the latter is what the author of the manual page intended, because the pointer-to-zero method is more expensive (in terms of system call time) and also fails when the number of file descriptors exceeds 32 (or more precisely, sizeof(int)*CHAR_BIT). -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
jim@segue.segue.com (Jim Balter) (03/28/91)
In article <11478@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: >The C language definition guarantees only that: > > * the integer constant 0, cast to any pointer type, produces a > valid pointer value that compare unequal to the address of any > valid of that type (including objects created via a successful > call to malloc()); Note, though, that ANSI does (unfortunately) allow malloc(0) to return NULL. But then that's not an object, since objects can't have 0 size (another unfortunate ANSI position, IMO), so your statement is technically correct. >and a few other minor points. It specifically does NOT say that any >particular null pointer has the same bit pattern as any other >particular null pointer, nor that any particular null pointer has the >integer value 0. What you say is true, but note that many many programs use memset or calloc to clear arrays or structures that contain pointers. Too bad you can't say aggregate = 0; C implementations that use something other than a zero bit pattern for NULL pointers, aside from indicating bad judgement, are likely also to be non-conforming, if they use BSS or the equivalent for void *foo[100000]; since ANSI requires that it be the same as void *foo[100000] = {0, ... repeated 100000 times}; >If you do not believe that the phrase `a zero pointer' is misleading, >read comp.lang.c for a few weeks, or comp.unix.* for a few months or >years, and watch for Frequently Asked Questions about null pointers >or about the arguments to select(). I really wouldn't recommend comp.lang.c as a high quality source. I recall hearing of an extensive heated discussion about the need for an alignof keyword in C, despite the fairly obvious macro #define alignof(type) offsetof(struct {char x; type y;}, y) There are really better ways to waste time. Like reading the Standard. --- Just because I was the first to vote approval of the C Standard doesn't mean it's all my fault!