* [9fans] const @ 2005-12-07 10:34 Steve Simon 2005-12-07 12:17 ` Russ Cox ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Steve Simon @ 2005-12-07 10:34 UTC (permalink / raw) To: 9fans I'm trying to find a reference to a tirade against the C const type qualifier. I think it was writtent during the ANSI-isation of C by dmr or perhaps bwk, (or was it was rob). Anyone got a link to this or did I imagine it? -Steve ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 10:34 [9fans] const Steve Simon @ 2005-12-07 12:17 ` Russ Cox 2005-12-07 13:01 ` erik quanstrom [not found] ` <000401c5fb32$64502e00$14aaa8c0@utelsystems.local> 2005-12-07 16:23 ` jmk 2005-12-08 7:39 ` geoff 2 siblings, 2 replies; 47+ messages in thread From: Russ Cox @ 2005-12-07 12:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I'm trying to find a reference to a tirade against > the C const type qualifier. I think it was writtent > during the ANSI-isation of C by dmr or perhaps bwk, > (or was it was rob). http://www.lysator.liu.se/c/dmr-on-noalias.html http://tinyurl.com/8435y The second (actually a Google Groups url) explains the first. Russ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 12:17 ` Russ Cox @ 2005-12-07 13:01 ` erik quanstrom [not found] ` <000401c5fb32$64502e00$14aaa8c0@utelsystems.local> 1 sibling, 0 replies; 47+ messages in thread From: erik quanstrom @ 2005-12-07 13:01 UTC (permalink / raw) To: 9fans, Russ Cox i've found const pretty useful, dispite the fact it does create some inconsistencies. it's chief virtue is that you can tell without looking any further than the prototype that a function that takes a const char* makes it's own copy, if it needs one. if you're careful with const, i think it can be a help in preventing some silly mistakes that will cause a benign looking program to get up and fandango on core. unfortunately, glibc, for example, is not very consistant. dispite the fact that it returns a pointer into envp, glibc getenv is declared as "char* getenv(const char*);". - erik Russ Cox <rsc@swtch.com> writes | | > I'm trying to find a reference to a tirade against | > the C const type qualifier. I think it was writtent | > during the ANSI-isation of C by dmr or perhaps bwk, | > (or was it was rob). | | http://www.lysator.liu.se/c/dmr-on-noalias.html | http://tinyurl.com/8435y | | The second (actually a Google Groups url) explains the first. | | Russ ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <000401c5fb32$64502e00$14aaa8c0@utelsystems.local>]
* Re: [9fans] const [not found] ` <000401c5fb32$64502e00$14aaa8c0@utelsystems.local> @ 2005-12-07 14:10 ` "Nils O. Selåsdal" 2005-12-07 15:05 ` Steve Simon 0 siblings, 1 reply; 47+ messages in thread From: "Nils O. Selåsdal" @ 2005-12-07 14:10 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs erik quanstrom wrote: > i've found const pretty useful, dispite the fact it does create some inconsistencies. > it's chief virtue is that you can tell without looking any further than the prototype > that a function that takes a const char* makes it's own copy, if it needs one. > > if you're careful with const, i think it can be a help in preventing some silly mistakes > that will cause a benign looking program to get up and fandango on core. Helps various unixes with (micro?)optimizations as well, which places const data in read only sections which then are normally shared between multiple instances. > unfortunately, glibc, for example, is not very consistant. dispite the fact that it returns > a pointer into envp, glibc getenv is declared as "char* getenv(const char*);". That's exactly how ISO C(99) and posix[1] declares it, I suppose you could blame them. (envp is modifiable on my BSD atleast though. C99 marks it as undefined behavior if you modify it) [1] http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 14:10 ` "Nils O. Selåsdal" @ 2005-12-07 15:05 ` Steve Simon 2005-12-07 15:30 ` Lucio De Re [not found] ` <1E68F99F-78D7-4321-BE56-7D0319212596@telus.net> 0 siblings, 2 replies; 47+ messages in thread From: Steve Simon @ 2005-12-07 15:05 UTC (permalink / raw) To: 9fans My understanding is that const was depricated for the same reason that register is - the compiler is in a much better position to judge what data is constant than the programmer. The one place where it would have been very useful (to me) was writing ROMable embedded code, but these days with 32bit embedded CPUs I don't have physicially readonly data. To cap this the last time I did use a 16bit cpu and tried to do this, examination of the assembly proved the (name deleted) compiler was too dumb to take advantage. -Steve ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 15:05 ` Steve Simon @ 2005-12-07 15:30 ` Lucio De Re 2005-12-07 15:53 ` C H Forsyth [not found] ` <1E68F99F-78D7-4321-BE56-7D0319212596@telus.net> 1 sibling, 1 reply; 47+ messages in thread From: Lucio De Re @ 2005-12-07 15:30 UTC (permalink / raw) To: 9fans > To cap this the last time I did use a 16bit cpu and tried to do this, > examination of the assembly proved the (name deleted) compiler was too > dumb to take advantage. Now, irrespective of which compiler Steve is referring to... In the delusion that I may have to migrate to embedded systems when my luck with system and network administration runs out, I follow the traffic on the avr-gcc mailing list. Even though criticism on _this_ list of GCC is often borne out there, one has to grant that avr-gcc is a dramatically superior product to any other offering for the target CPU. GCC is a monstrosity, but nothing else addresses all the issues that it resolves. The cost is extremely high, but in my opinion it is worth paying. I think GCC is closer to an organism than to a formal translator and that may well be its strongest suit. ++L ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 15:30 ` Lucio De Re @ 2005-12-07 15:53 ` C H Forsyth 0 siblings, 0 replies; 47+ messages in thread From: C H Forsyth @ 2005-12-07 15:53 UTC (permalink / raw) To: lucio, 9fans [-- Attachment #1: Type: text/plain, Size: 947 bytes --] >>list of GCC is often borne out there, one has to grant that avr-gcc is >>a dramatically superior product to any other offering for the target >>CPU. that's funny. before i read it, i was just about to observe that our Atmel compiler based on Plan 9's puts tables in program flash without any hints. const alone wouldn't help anyway because the memory is accessed using special instructions so the compiler and linker need to do more analysis. otherwise the compiler does reasonable well given that the chip is really an 8-bit micro. i think the loader zl helps zc in some cases, and also monitors stack sizes. it was important that the FFT and CC1000 tables go in program memory to save limited RAM, although that feature was added fairly late. we needed the atmel compiler for some work on motes. i looked at gcc for it a bit initially whilst waiting for ours but started to throw things or throw up; i can't remember which. [-- Attachment #2: Type: message/rfc822, Size: 3105 bytes --] From: Lucio De Re <lucio@proxima.alt.za> To: 9fans@cse.psu.edu Subject: Re: [9fans] const Date: Wed, 7 Dec 2005 17:30:42 +0200 Message-ID: <16513104bf876d67dcbb094b8f545d54@proxima.alt.za> > To cap this the last time I did use a 16bit cpu and tried to do this, > examination of the assembly proved the (name deleted) compiler was too > dumb to take advantage. Now, irrespective of which compiler Steve is referring to... In the delusion that I may have to migrate to embedded systems when my luck with system and network administration runs out, I follow the traffic on the avr-gcc mailing list. Even though criticism on _this_ list of GCC is often borne out there, one has to grant that avr-gcc is a dramatically superior product to any other offering for the target CPU. GCC is a monstrosity, but nothing else addresses all the issues that it resolves. The cost is extremely high, but in my opinion it is worth paying. I think GCC is closer to an organism than to a formal translator and that may well be its strongest suit. ++L ^ permalink raw reply [flat|nested] 47+ messages in thread
[parent not found: <1E68F99F-78D7-4321-BE56-7D0319212596@telus.net>]
* Re: [9fans] const [not found] ` <1E68F99F-78D7-4321-BE56-7D0319212596@telus.net> @ 2005-12-07 16:11 ` "Nils O. Selåsdal" 2005-12-07 17:27 ` Paul Lalonde 0 siblings, 1 reply; 47+ messages in thread From: "Nils O. Selåsdal" @ 2005-12-07 16:11 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Paul Lalonde wrote: > Here's a related question: There are read-only (const) variables, and > read-write variables. Is there any way to notate a write-only variable > in C? I'd like to be able to denote that something is a stream /* Don't read from this */ Should suffice. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 16:11 ` "Nils O. Selåsdal" @ 2005-12-07 17:27 ` Paul Lalonde 0 siblings, 0 replies; 47+ messages in thread From: Paul Lalonde @ 2005-12-07 17:27 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs If only! Most of my life has been writing libraries for game programmers to use. If you think Linux is a strange and scary place, you ain't seen nothing yet. If the compiler can't enforce the convention, you can't rely on it. Paul On 7-Dec-05, at 8:11 AM, Nils O. Selåsdal wrote: > Paul Lalonde wrote: >> Here's a related question: There are read-only (const) variables, >> and read-write variables. Is there any way to notate a write-only >> variable in C? I'd like to be able to denote that something is a >> stream > > /* Don't read from this */ > Should suffice. > > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 10:34 [9fans] const Steve Simon 2005-12-07 12:17 ` Russ Cox @ 2005-12-07 16:23 ` jmk 2005-12-07 17:28 ` Skip Tavakkolian 2005-12-07 18:51 ` Joel Salomon 2005-12-08 7:39 ` geoff 2 siblings, 2 replies; 47+ messages in thread From: jmk @ 2005-12-07 16:23 UTC (permalink / raw) To: 9fans /sys/games/lib/fortunes:2176: I'd rather have :rofix than const. -DM Ritchie ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 16:23 ` jmk @ 2005-12-07 17:28 ` Skip Tavakkolian 2005-12-07 18:51 ` Joel Salomon 1 sibling, 0 replies; 47+ messages in thread From: Skip Tavakkolian @ 2005-12-07 17:28 UTC (permalink / raw) To: 9fans > /sys/games/lib/fortunes:2176: I'd rather have :rofix than const. -DM Ritchie nice! ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 16:23 ` jmk 2005-12-07 17:28 ` Skip Tavakkolian @ 2005-12-07 18:51 ` Joel Salomon 2005-12-07 18:58 ` Charles Forsyth 2005-12-07 20:33 ` Skip Tavakkolian 1 sibling, 2 replies; 47+ messages in thread From: Joel Salomon @ 2005-12-07 18:51 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 12/7/05, jmk@plan9.bell-labs.com <jmk@plan9.bell-labs.com> wrote: > /sys/games/lib/fortunes:2176: I'd rather have :rofix than const. -DM Ritchie :rofix ? ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 18:51 ` Joel Salomon @ 2005-12-07 18:58 ` Charles Forsyth 2005-12-07 19:30 ` Joel Salomon 2005-12-07 20:33 ` Skip Tavakkolian 1 sibling, 1 reply; 47+ messages in thread From: Charles Forsyth @ 2005-12-07 18:58 UTC (permalink / raw) To: 9fans >:rofix ? (on unix) cc -S something.c ./:rofix something.s as -o something.o something.s where :rofix is a sh/ed/sed script that changes certain .data to .text ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 18:58 ` Charles Forsyth @ 2005-12-07 19:30 ` Joel Salomon 2005-12-07 19:36 ` Brantley Coile ` (2 more replies) 0 siblings, 3 replies; 47+ messages in thread From: Joel Salomon @ 2005-12-07 19:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 12/7/05, Charles Forsyth <forsyth@terzarima.net> wrote: > (on unix) cc -S something.c > ./:rofix something.s > as -o something.o something.s > > where :rofix is a sh/ed/sed script that changes certain .data to .text So it does the optimization possible with const. Not the "interface" part, though. If you don't like type decorations, I guess this way's better. --Joel ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 19:30 ` Joel Salomon @ 2005-12-07 19:36 ` Brantley Coile 2005-12-07 19:51 ` rog 2005-12-07 21:07 ` Charles Forsyth 2 siblings, 0 replies; 47+ messages in thread From: Brantley Coile @ 2005-12-07 19:36 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 285 bytes --] It was a way to move the string from the data segment to the text segment. I never found it useful and making strings const char * broke lots of programs that wrote directly into strings. No big deal, but a useless pain. I tire of paying for things I don't use. :( 1011 1100 [-- Attachment #2: Type: message/rfc822, Size: 3493 bytes --] From: Joel Salomon <joelcsalomon@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] const Date: Wed, 7 Dec 2005 14:30:17 -0500 Message-ID: <7871fcf50512071130m475c7240i3c65da1b4c900c15@mail.gmail.com> On 12/7/05, Charles Forsyth <forsyth@terzarima.net> wrote: > (on unix) cc -S something.c > ./:rofix something.s > as -o something.o something.s > > where :rofix is a sh/ed/sed script that changes certain .data to .text So it does the optimization possible with const. Not the "interface" part, though. If you don't like type decorations, I guess this way's better. --Joel ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 19:30 ` Joel Salomon 2005-12-07 19:36 ` Brantley Coile @ 2005-12-07 19:51 ` rog 2005-12-07 21:07 ` Charles Forsyth 2 siblings, 0 replies; 47+ messages in thread From: rog @ 2005-12-07 19:51 UTC (permalink / raw) To: 9fans > So it does the optimization possible with const. Not the "interface" > part, though. If you don't like type decorations, I guess this way's > better. from my point of view, const pretends to be something it isn't. it does not guarantee you anything at all (it is routinely necessary to cast from const to non-const), and most ironically of all, in the only place where const would actually mean something, literal strings, which are often held in read-only memory, the type is not const qualified. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 19:30 ` Joel Salomon 2005-12-07 19:36 ` Brantley Coile 2005-12-07 19:51 ` rog @ 2005-12-07 21:07 ` Charles Forsyth 2005-12-07 21:18 ` Bruce Ellis ` (2 more replies) 2 siblings, 3 replies; 47+ messages in thread From: Charles Forsyth @ 2005-12-07 21:07 UTC (permalink / raw) To: 9fans > So it does the optimization possible with const. Not the "interface" > part, though. If you don't like type decorations, I guess this way's > better. it's not so much type decorations, as those that are not terribly useful or to some extent misleading. (mind you, java programs look like christmas trees--holiday trees to those of you in the US-- with all their type and status decorations.) if you followed the earlier links you'll see one of the classic examples of it being fairly odd as an interface constraint: char* strchr(const char* x, int y) but the resulting pointer points into the const string and ok, it doesn't write to it itself, but it hands you back a pointer into the same string so you can do it yourself! that's wierd, especially since it must effectively have cast x to plain char* internally so it's not much of a constraint either way. i find it's really a device for forcing the adding and removing of const until a compiler shuts up. this is unusual, because most type clash diagnostics do mean something; perhaps not all that much, but something. perhaps i'm lucky, but i have found bugs through type clashes (often when checking extern linkages) but i can't remember a single thing detected by const. it's one of those things where ``now it's there we might as well try to use it'' but i'm afraid i'm unconvinced. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 21:07 ` Charles Forsyth @ 2005-12-07 21:18 ` Bruce Ellis 2005-12-07 21:22 ` Paul Lalonde 2005-12-07 22:44 ` Micah Stetson 2 siblings, 0 replies; 47+ messages in thread From: Bruce Ellis @ 2005-12-07 21:18 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs ken had total disregard for const and that is good enough for me. i rememeber :rofix and other such hacks, but that was when memory was an issue. brucee On 12/8/05, Charles Forsyth <forsyth@terzarima.net> wrote: > > So it does the optimization possible with const. Not the "interface" > > part, though. If you don't like type decorations, I guess this way's > > better. > > it's not so much type decorations, as those that are not terribly useful or to some extent misleading. > (mind you, java programs look like christmas trees--holiday trees to those of you in the US-- > with all their type and status decorations.) > > if you followed the earlier links you'll see one of the classic examples > of it being fairly odd as an interface constraint: > > char* strchr(const char* x, int y) > > but the resulting pointer points into the const string and ok, it doesn't write to it itself, but it > hands you back a pointer into the same string so you can do it yourself! > that's wierd, especially since it must effectively have cast x to plain char* internally > so it's not much of a constraint either way. > > i find it's really a device for forcing the adding and removing of const > until a compiler shuts up. this is unusual, because most type clash diagnostics do mean something; > perhaps not all that much, but something. perhaps i'm lucky, but i have found bugs through > type clashes (often when checking extern linkages) but i can't remember a single thing detected by const. > it's one of those things where ``now it's there we might as well try to use it'' but i'm afraid i'm unconvinced. > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 21:07 ` Charles Forsyth 2005-12-07 21:18 ` Bruce Ellis @ 2005-12-07 21:22 ` Paul Lalonde 2005-12-07 22:04 ` Rob Pike 2005-12-07 22:44 ` Micah Stetson 2 siblings, 1 reply; 47+ messages in thread From: Paul Lalonde @ 2005-12-07 21:22 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 7-Dec-05, at 1:07 PM, Charles Forsyth wrote: > if you followed the earlier links you'll see one of the classic > examples > of it being fairly odd as an interface constraint: > > char* strchr(const char* x, int y) I call this an interface bug: really, it should return a const char *, not a char *. For the case where the input string was not const the user can obviously strip the constness from the return value. It is a clear example of trying to make a piece of notation do two things. One is to say that the function does not modify its paramter, which is of clear benefit to the optimizer when calling the function. The second is to say that the data pointed to should not be changed, which is a semantic constraint for the programmer. Ugly. Paul ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 21:22 ` Paul Lalonde @ 2005-12-07 22:04 ` Rob Pike 0 siblings, 0 replies; 47+ messages in thread From: Rob Pike @ 2005-12-07 22:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It's the property of strchr that's truly const, not its arguments. Expressing this in the arguments leads to this sort of silliness. I've always thought constancy should be a property of where something is stored, not its type. (Hence :rofix for instance.) Reiterating what someone said, 'const' is too simple a notion to encode optimization opportunities and too invasive a notion to sit well in any practical code. -rob On 12/7/05, Paul Lalonde <plalonde@telus.net> wrote: > > On 7-Dec-05, at 1:07 PM, Charles Forsyth wrote: > > if you followed the earlier links you'll see one of the classic > > examples > > of it being fairly odd as an interface constraint: > > > > char* strchr(const char* x, int y) > > I call this an interface bug: really, it should return a const char > *, not a char *. For the case where the input string was not const > the user can obviously strip the constness from the return value. > > It is a clear example of trying to make a piece of notation do two > things. One is to say that the function does not modify its > paramter, which is of clear benefit to the optimizer when calling the > function. The second is to say that the data pointed to should not > be changed, which is a semantic constraint for the programmer. > Ugly. > > Paul > > > ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 21:07 ` Charles Forsyth 2005-12-07 21:18 ` Bruce Ellis 2005-12-07 21:22 ` Paul Lalonde @ 2005-12-07 22:44 ` Micah Stetson 2005-12-07 22:44 ` Micah Stetson 2 siblings, 1 reply; 47+ messages in thread From: Micah Stetson @ 2005-12-07 22:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > (mind you, java programs look like christmas trees--holiday trees to those of you in the US-- I think Channukwanzaamastice is the best name for the collective of politically correct celebrations that may or may not occur in your home at this time of year. It contains part of the name of each of the major celebrations, symbolizing both our diversity and solidarity. It does not mention Christ, because he wasn't open-minded enough to accept that each person's diverse beliefs are equally valid, however contradictory. And it sounds like a disease, which is not innaccurate. Micah ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 22:44 ` Micah Stetson @ 2005-12-07 22:44 ` Micah Stetson 2005-12-07 22:46 ` Brantley Coile 0 siblings, 1 reply; 47+ messages in thread From: Micah Stetson @ 2005-12-07 22:44 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > I think Channukwanzaamastice is the best name for the collective of Oops, I didn't mean to send that to the list. Sorry for the sarcastic noise. Micah ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 22:44 ` Micah Stetson @ 2005-12-07 22:46 ` Brantley Coile 0 siblings, 0 replies; 47+ messages in thread From: Brantley Coile @ 2005-12-07 22:46 UTC (permalink / raw) To: 9fans [-- Attachment #1: Type: text/plain, Size: 80 bytes --] No problem. Merry Chirstmas everybody! Brantley (in the US and Baptist.) [-- Attachment #2: Type: message/rfc822, Size: 3218 bytes --] From: Micah Stetson <micah@stetsonnet.org> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] const Date: Wed, 7 Dec 2005 14:44:59 -0800 Message-ID: <b3b4f6f30512071444k11628698i390861695427ab53@mail.gmail.com> > I think Channukwanzaamastice is the best name for the collective of Oops, I didn't mean to send that to the list. Sorry for the sarcastic noise. Micah ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 18:51 ` Joel Salomon 2005-12-07 18:58 ` Charles Forsyth @ 2005-12-07 20:33 ` Skip Tavakkolian 1 sibling, 0 replies; 47+ messages in thread From: Skip Tavakkolian @ 2005-12-07 20:33 UTC (permalink / raw) To: 9fans >> /sys/games/lib/fortunes:2176: I'd rather have :rofix than const. -DM Ritchie > > :rofix ? http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/vi/port/rofix ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-07 10:34 [9fans] const Steve Simon 2005-12-07 12:17 ` Russ Cox 2005-12-07 16:23 ` jmk @ 2005-12-08 7:39 ` geoff 2005-12-08 7:53 ` Lucio De Re ` (2 more replies) 2 siblings, 3 replies; 47+ messages in thread From: geoff @ 2005-12-08 7:39 UTC (permalink / raw) To: 9fans I like Ken's comment in A New C Compiler: Volatile seems to have no meaning, so it is hard to tell if ignoring it is a departure from the standard. Const only confuses library interfaces with the hope of catching some rare errors. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-08 7:39 ` geoff @ 2005-12-08 7:53 ` Lucio De Re 2005-12-08 7:54 ` geoff 2005-12-08 15:58 ` Brantley Coile 2005-12-09 16:25 ` David Leimbach 2 siblings, 1 reply; 47+ messages in thread From: Lucio De Re @ 2005-12-08 7:53 UTC (permalink / raw) To: geoff, 9fans > I like Ken's comment in A New C Compiler: This is a document I've long missed, where is it? ++L ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-08 7:53 ` Lucio De Re @ 2005-12-08 7:54 ` geoff 2005-12-08 10:23 ` Bruce Ellis 0 siblings, 1 reply; 47+ messages in thread From: geoff @ 2005-12-08 7:54 UTC (permalink / raw) To: lucio, 9fans `A New C Compiler' was in the Summer 1990 UKUUG proceedings, but Google finds it also at http://www.ibiblio.org/pub/academic/computer-science/operating-systems/plan9/8-c-compiler.ps.Z ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-08 7:54 ` geoff @ 2005-12-08 10:23 ` Bruce Ellis 0 siblings, 0 replies; 47+ messages in thread From: Bruce Ellis @ 2005-12-08 10:23 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs indeed - it was a long time ago (gnot days). brucee On 12/8/05, geoff@collyer.net <geoff@collyer.net> wrote: > `A New C Compiler' was in the Summer 1990 UKUUG proceedings, but > Google finds it also at > > http://www.ibiblio.org/pub/academic/computer-science/operating-systems/plan9/8-c-compiler.ps.Z ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-08 7:39 ` geoff 2005-12-08 7:53 ` Lucio De Re @ 2005-12-08 15:58 ` Brantley Coile 2005-12-09 1:44 ` geoff 2005-12-09 16:25 ` David Leimbach 2 siblings, 1 reply; 47+ messages in thread From: Brantley Coile @ 2005-12-08 15:58 UTC (permalink / raw) To: 9fans > I like Ken's comment in A New C Compiler: > > Volatile seems to have no meaning, so it is hard to tell if ignoring > it is a departure from the standard. Const only confuses library > interfaces with the hope of catching some rare errors. Indeed. But does the keyword do anything in the current compilers? It doesn't seem like the keyword gets ignored. Several [.]VOLATILE constants and a command in 8c/sgen.c:370. bc ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-08 15:58 ` Brantley Coile @ 2005-12-09 1:44 ` geoff 2005-12-09 2:04 ` Russ Cox 0 siblings, 1 reply; 47+ messages in thread From: geoff @ 2005-12-09 1:44 UTC (permalink / raw) To: 9fans At a quick read, it appears that `const' and `volatile' are treated as `garbage type qualifiers' and ignored. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 1:44 ` geoff @ 2005-12-09 2:04 ` Russ Cox 2005-12-09 2:19 ` geoff 2005-12-09 9:54 ` Charles Forsyth 0 siblings, 2 replies; 47+ messages in thread From: Russ Cox @ 2005-12-09 2:04 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > At a quick read, it appears that `const' and `volatile' are treated as > `garbage type qualifiers' and ignored. Const is ignored. Volatile is not ignored anymore. /sys/src/cmd/cc/dcl.c:768 or so inserts USED(&x) if you declare volatile int x;, presumably so that the compiler will not registerize x. This is occasionally necessary in the kernel because of waserror(). For example: x = 0; if(waserror()){ print("x=%d\n", x); nexterror(); } x = 1; x = f(x); If f errors, then the waserror might print 0 if the compiler has chosen not to store the 1 (it's not used after the call to f -- it will be overwritten once f returns). This happens in namec in /sys/src/9/port/chan.c. Rob defined an empty function saveregisters() and called it to force the compiler to write the new value of x to memory before calling f (in this case, devtab[c->type]->open). It could be replaced by making c volatile now, though I'd rather not. Russ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 2:04 ` Russ Cox @ 2005-12-09 2:19 ` geoff 2005-12-09 9:54 ` Charles Forsyth 1 sibling, 0 replies; 47+ messages in thread From: geoff @ 2005-12-09 2:19 UTC (permalink / raw) To: 9fans On closer inspection, `const' isn't completely ignored either. It can generate warnings at /sys/src/cmd/cc/sub.c:510 and :524. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 2:04 ` Russ Cox 2005-12-09 2:19 ` geoff @ 2005-12-09 9:54 ` Charles Forsyth 1 sibling, 0 replies; 47+ messages in thread From: Charles Forsyth @ 2005-12-09 9:54 UTC (permalink / raw) To: 9fans > the compiler will not registerize x. This is occasionally > necessary in the kernel because of waserror(). > For example: > > x = 0; > if(waserror()){ > print("x=%d\n", x); > nexterror(); > } > x = 1; > x = f(x); i think i'ts usually better to (re)write these to avoid confusing the compiler, for instance by doing a new waserror/nexterror following x=1, although if x changes value frequently, that's difficult. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-08 7:39 ` geoff 2005-12-08 7:53 ` Lucio De Re 2005-12-08 15:58 ` Brantley Coile @ 2005-12-09 16:25 ` David Leimbach 2005-12-09 16:59 ` Richard Bilson 2005-12-09 17:01 ` Ronald G Minnich 2 siblings, 2 replies; 47+ messages in thread From: David Leimbach @ 2005-12-09 16:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1098 bytes --] On 12/7/05, geoff@collyer.net <geoff@collyer.net> wrote: > > I like Ken's comment in A New C Compiler: > > Volatile seems to have no meaning, so it is hard to tell if ignoring > it is a departure from the standard. Const only confuses library > interfaces with the hope of catching some rare errors. Volatile is useful for telling compilers not to stick data in registers, which is helpful for multi-threaded situations with shared memory ... sometimes :) If I were to write a semaphore or another synchronization method using shared memory on unix I'd probably type volatile and then pray :). It often feels more of a faith issue than a knowledge issue though :) Const is ok, sometimes, in some languages [C++]. It's notoriously difficult to add const interfaacs to C++ classes as an afterthought. You have to go in "full const" or none at all. Adding it afterwards causes a great deal of pain tracking down all the places you needed const when you didn't put it there. It's like playing pick up sticks with your buttcheeks. - [I think] the late John Candy. [-- Attachment #2: Type: text/html, Size: 1496 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 16:25 ` David Leimbach @ 2005-12-09 16:59 ` Richard Bilson 2005-12-09 17:42 ` David Leimbach 2005-12-09 17:01 ` Ronald G Minnich 1 sibling, 1 reply; 47+ messages in thread From: Richard Bilson @ 2005-12-09 16:59 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1020 bytes --] On 12/9/05, David Leimbach <leimy2k@gmail.com> wrote: > > Volatile is useful for telling compilers not to stick data in registers, > which is helpful for multi-threaded situations with shared memory ... > sometimes :) > > If I were to write a semaphore or another synchronization method using > shared memory on unix I'd probably type volatile and then pray :). > > It often feels more of a faith issue than a knowledge issue though :) > It is a matter of faith, and usually misplaced at that, since volatile isn't usually defined to place any constraints on the order in which operations become visible to other processors. Certainly not in the C, C++, or POSIX standards, although some platform ABIs do specify this to some degree. Both POSIX and C++ are trying to deal with this, but it's an uphill battle since processors differ widely on the sorts of constraints that they can support efficiently. In the meantime, people sprinkle volatile around and pray. All the world's an x86, right? [-- Attachment #2: Type: text/html, Size: 1334 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 16:59 ` Richard Bilson @ 2005-12-09 17:42 ` David Leimbach 2005-12-09 19:17 ` Richard Bilson 0 siblings, 1 reply; 47+ messages in thread From: David Leimbach @ 2005-12-09 17:42 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 993 bytes --] > It is a matter of faith, and usually misplaced at that, since volatile > isn't usually defined to place any constraints on the order in which > operations become visible to other processors. Certainly not in the C, C++, > or POSIX standards, although some platform ABIs do specify this to some > degree. > > Both POSIX and C++ are trying to deal with this, but it's an uphill battle > since processors differ widely on the sorts of constraints that they can > support efficiently. > > In the meantime, people sprinkle volatile around and pray. All the world's > an x86, right? > I think I'd be happier with new compiler pragmas in this case than a keyword. Then at least I KNOW that it can be ignored and will be optionally supported by compilers on a per-case basis. But then again, that's also true for "inline" in C++. It's just a suggestion, one that can be ignored. The compiler can also inline stuff I didn't ask it to. [C99 has inline now too doesn't it?] [-- Attachment #2: Type: text/html, Size: 1230 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 17:42 ` David Leimbach @ 2005-12-09 19:17 ` Richard Bilson 0 siblings, 0 replies; 47+ messages in thread From: Richard Bilson @ 2005-12-09 19:17 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1419 bytes --] On 12/9/05, David Leimbach <leimy2k@gmail.com> wrote: > > > I think I'd be happier with new compiler pragmas in this case than a > keyword. Then at least I KNOW that it can be ignored and will be optionally > supported by compilers on a per-case basis. > > But then again, that's also true for "inline" in C++. It's just a > suggestion, one that can be ignored. The compiler can also inline stuff I > didn't ask it to. [C99 has inline now too doesn't it?] The difference is that with memory barriers it's often the case that the correctness of the algorithm depends on the placement of the barriers. Consider writing a portable spin-lock: it's crucial that other processors not be able to observe the lock open unless they also observe previous memory writes in the critical section. But, in the absence of memory barriers, many CPUs don't guarantee this. The simple answer, of course, is to put the barriers in non-portable lock code and use the locks to protect shared state. But the general experience seems to be that programmers will try anything to avoid locks, for performance reasons. Double-checked locking is the classic example -- it's such a popular idiom that Java redefined the meaning of "volatile" to make it work. C++ will probably do something similar. And yes, C99 has inline, but to make things interesting they gave it a slightly different meaning than in C++. [-- Attachment #2: Type: text/html, Size: 1772 bytes --] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 16:25 ` David Leimbach 2005-12-09 16:59 ` Richard Bilson @ 2005-12-09 17:01 ` Ronald G Minnich 2005-12-09 17:39 ` Russ Cox ` (2 more replies) 1 sibling, 3 replies; 47+ messages in thread From: Ronald G Minnich @ 2005-12-09 17:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs David Leimbach wrote: > Volatile is useful for telling compilers not to stick data in > registers, which is helpful for multi-threaded situations with shared > memory ... sometimes :) and, stuff that tickles hardware. Refer to the old crazy stuff bsd did in the early 80s to get around those issues and still optimize drivers. Now, wonder if that script could even be found at this point. I think I missed the part of the discussion that explains how to do mmap'ed I/O without volatile, and a good idea of how to tweak the compiler, such that: while (x->statux & BUSY) ; works. If the answer is "don't optimize that functions, you idiot!" I'm actually ok with that. ron ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] const 2005-12-09 17:01 ` Ronald G Minnich @ 2005-12-09 17:39 ` Russ Cox 2005-12-09 17:40 ` [9fans] PCICIA Modem TamTam 2005-12-09 19:37 ` [9fans] Re: const Nikita Danilov 2 siblings, 0 replies; 47+ messages in thread From: Russ Cox @ 2005-12-09 17:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > and, stuff that tickles hardware. Refer to the old crazy stuff bsd did > in the early 80s to get around those issues and still optimize drivers. > Now, wonder if that script could even be found at this point. > > I think I missed the part of the discussion that explains how to do > mmap'ed I/O without volatile, and a good idea of how to tweak the > compiler, such that: > > while (x->statux & BUSY) > ; > > works. If the answer is "don't optimize that functions, you idiot!" I'm > actually ok with that. On Plan 9, the compiler does not cache the results of explicit memory reads like x->status. So this is not a problem. Russ ^ permalink raw reply [flat|nested] 47+ messages in thread
* [9fans] PCICIA Modem 2005-12-09 17:01 ` Ronald G Minnich 2005-12-09 17:39 ` Russ Cox @ 2005-12-09 17:40 ` TamTam 2005-12-09 18:59 ` Sascha Retzki 2005-12-12 15:07 ` Paweł Lasek 2005-12-09 19:37 ` [9fans] Re: const Nikita Danilov 2 siblings, 2 replies; 47+ messages in thread From: TamTam @ 2005-12-09 17:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Hi all! I have Plan 9 on an very old Vaio 266 Mhz Notebook without any ethernet. Fortunately I have a PCICIA Modem, but as I was searching for a program to connect, there was no... or I'm simply too stupid. ;) My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I know... but even better than nothing! ;) Is there any possibility to connect with my PCICIA Card Modem? And if yes, how? I recongnized, that plan 9 without Internet is nothing and on my 500 Mhz Computer it won't install at all.... Thanks for helping, TamTam -- ------------------------------ http://javacoffee.de -- "Die Community mit Aroma!" http://benny-thegame.de.vu -- "Die Offizielle Seite von Benny The Game!" ------------------------------ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] PCICIA Modem 2005-12-09 17:40 ` [9fans] PCICIA Modem TamTam @ 2005-12-09 18:59 ` Sascha Retzki 2005-12-12 15:07 ` Paweł Lasek 1 sibling, 0 replies; 47+ messages in thread From: Sascha Retzki @ 2005-12-09 18:59 UTC (permalink / raw) To: 9fans On Fri, Dec 09, 2005 at 06:40:31PM +0100, TamTam wrote: > Is there any possibility to connect with my PCICIA Card Modem? And if yes, > how? > I don't know how cardbus is handled on Plan9, but I can tell you what happened when I was plugging such a thing into a NetBSD box - the device was registered as a 56k-modem connected to the serial port. Maybe something similar can be done, no idea. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] PCICIA Modem 2005-12-09 17:40 ` [9fans] PCICIA Modem TamTam 2005-12-09 18:59 ` Sascha Retzki @ 2005-12-12 15:07 ` Paweł Lasek 2005-12-26 9:00 ` Martin C. Atkins 1 sibling, 1 reply; 47+ messages in thread From: Paweł Lasek @ 2005-12-12 15:07 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 12/9/05, TamTam <javacoffee@gmx.de> wrote: > My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I > know... but even better than nothing! ;) > > Is there any possibility to connect with my PCICIA Card Modem? And if yes, > how? Check all possible seiral ports - It should register itself as a standard PCMCIA UART, after all onboard ones. After that you can use it as any other modem connected to serial port. > Thanks for helping, > TamTam > -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish] ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] PCICIA Modem 2005-12-12 15:07 ` Paweł Lasek @ 2005-12-26 9:00 ` Martin C. Atkins 2005-12-26 14:19 ` Paweł Lasek 0 siblings, 1 reply; 47+ messages in thread From: Martin C. Atkins @ 2005-12-26 9:00 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs, TamTam On Mon, 12 Dec 2005 16:07:42 +0100 Paweł Lasek <pawel.lasek@gmail.com> wrote: > On 12/9/05, TamTam <javacoffee@gmx.de> wrote: > > > My PCICIA Card is a ComOne MC220 56k Modem Card... Its really not the best, I > > know... but even better than nothing! ;) > > > > Is there any possibility to connect with my PCICIA Card Modem? And if yes, > > how? I've got something with (I believe) the same number (and from the same source - a VAIO). (I don't have it handy to double check the model number, however) My modem is a softmodem, and so no, it won't "just" show up as a serial port! (And I had a good deal of trouble getting it to work under Linux - in fact, I eventually gave up - the modem worked - eventually, just - but suspend/resume broke it) Martin ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] PCICIA Modem 2005-12-26 9:00 ` Martin C. Atkins @ 2005-12-26 14:19 ` Paweł Lasek 0 siblings, 0 replies; 47+ messages in thread From: Paweł Lasek @ 2005-12-26 14:19 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 12/26/05, Martin C. Atkins <martin_ml@parvat.com> wrote: > I've got something with (I believe) the same number (and from the same source - a VAIO). > (I don't have it handy to double check the model number, however) > My modem is a softmodem, and so no, it won't "just" show up as a serial port! > (And I had a good deal of trouble getting it to work under Linux - in fact, > I eventually gave up - the modem worked - eventually, just - but suspend/resume broke it) Then it's screwed, I say... If it's soft-modem, the only available solution is to write a driver for it. However isn't it rather rare for PCMCIA modems to be soft-modems? At least the one I have is just a "PCMCIA Serial Port", the same goes for the one mounted on Compaq Insight/LightsOut PCI which is in my school's Proliant 1850R. > Martin Good Luck with making it work on Plan9 (At least none of you seem to have the problem of Plan9 not booting at all ;-) ( Solution for me: Run Xen/Linux w/ Plan9 in domain 1 )) -- Paweł Lasek "Once a hitokiri, always a hitokiri. This will never change" - Jine-Ei http://plasek.jogger.pl [in polish] http://plasek.wordpress.com [in polish] ^ permalink raw reply [flat|nested] 47+ messages in thread
* [9fans] Re: const 2005-12-09 17:01 ` Ronald G Minnich 2005-12-09 17:39 ` Russ Cox 2005-12-09 17:40 ` [9fans] PCICIA Modem TamTam @ 2005-12-09 19:37 ` Nikita Danilov 2005-12-09 20:30 ` Russ Cox 2005-12-09 20:37 ` Ronald G Minnich 2 siblings, 2 replies; 47+ messages in thread From: Nikita Danilov @ 2005-12-09 19:37 UTC (permalink / raw) To: 9fans Ronald G Minnich <rminnich@lanl.gov> writes: [...] > > I think I missed the part of the discussion that explains how to do > mmap'ed I/O without volatile, and a good idea of how to tweak the By writing leaf functions in assembly? Nikita. ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] Re: const 2005-12-09 19:37 ` [9fans] Re: const Nikita Danilov @ 2005-12-09 20:30 ` Russ Cox 2005-12-09 20:37 ` Ronald G Minnich 1 sibling, 0 replies; 47+ messages in thread From: Russ Cox @ 2005-12-09 20:30 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > I think I missed the part of the discussion that explains how to do > > mmap'ed I/O without volatile, and a good idea of how to tweak the > > By writing leaf functions in assembly? This is an awful approach. We have many drivers that compile unchanged on multiple architectures. Having to write them in assembly just because the C compiler is too clever is just broken. As I pointed out, we don't have this problem in the Plan 9 C compilers anyway. And the people using smarter-than-thou C compilers like gcc can sprinkle their code with volatiles. Russ ^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: [9fans] Re: const 2005-12-09 19:37 ` [9fans] Re: const Nikita Danilov 2005-12-09 20:30 ` Russ Cox @ 2005-12-09 20:37 ` Ronald G Minnich 1 sibling, 0 replies; 47+ messages in thread From: Ronald G Minnich @ 2005-12-09 20:37 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Nikita Danilov wrote: > Ronald G Minnich <rminnich@lanl.gov> writes: > > [...] > > >>I think I missed the part of the discussion that explains how to do >>mmap'ed I/O without volatile, and a good idea of how to tweak the > > > By writing leaf functions in assembly? yuck. I think that's a bad, bad idea. ron ^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2005-12-26 14:19 UTC | newest] Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-12-07 10:34 [9fans] const Steve Simon 2005-12-07 12:17 ` Russ Cox 2005-12-07 13:01 ` erik quanstrom [not found] ` <000401c5fb32$64502e00$14aaa8c0@utelsystems.local> 2005-12-07 14:10 ` "Nils O. Selåsdal" 2005-12-07 15:05 ` Steve Simon 2005-12-07 15:30 ` Lucio De Re 2005-12-07 15:53 ` C H Forsyth [not found] ` <1E68F99F-78D7-4321-BE56-7D0319212596@telus.net> 2005-12-07 16:11 ` "Nils O. Selåsdal" 2005-12-07 17:27 ` Paul Lalonde 2005-12-07 16:23 ` jmk 2005-12-07 17:28 ` Skip Tavakkolian 2005-12-07 18:51 ` Joel Salomon 2005-12-07 18:58 ` Charles Forsyth 2005-12-07 19:30 ` Joel Salomon 2005-12-07 19:36 ` Brantley Coile 2005-12-07 19:51 ` rog 2005-12-07 21:07 ` Charles Forsyth 2005-12-07 21:18 ` Bruce Ellis 2005-12-07 21:22 ` Paul Lalonde 2005-12-07 22:04 ` Rob Pike 2005-12-07 22:44 ` Micah Stetson 2005-12-07 22:44 ` Micah Stetson 2005-12-07 22:46 ` Brantley Coile 2005-12-07 20:33 ` Skip Tavakkolian 2005-12-08 7:39 ` geoff 2005-12-08 7:53 ` Lucio De Re 2005-12-08 7:54 ` geoff 2005-12-08 10:23 ` Bruce Ellis 2005-12-08 15:58 ` Brantley Coile 2005-12-09 1:44 ` geoff 2005-12-09 2:04 ` Russ Cox 2005-12-09 2:19 ` geoff 2005-12-09 9:54 ` Charles Forsyth 2005-12-09 16:25 ` David Leimbach 2005-12-09 16:59 ` Richard Bilson 2005-12-09 17:42 ` David Leimbach 2005-12-09 19:17 ` Richard Bilson 2005-12-09 17:01 ` Ronald G Minnich 2005-12-09 17:39 ` Russ Cox 2005-12-09 17:40 ` [9fans] PCICIA Modem TamTam 2005-12-09 18:59 ` Sascha Retzki 2005-12-12 15:07 ` Paweł Lasek 2005-12-26 9:00 ` Martin C. Atkins 2005-12-26 14:19 ` Paweł Lasek 2005-12-09 19:37 ` [9fans] Re: const Nikita Danilov 2005-12-09 20:30 ` Russ Cox 2005-12-09 20:37 ` Ronald G Minnich
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).