* C++ Envy @ 1995-01-12 9:39 R.A.L Williams [not found] ` <3f9bha$r16@gnat.cs.nyu.edu> 0 siblings, 1 reply; 19+ messages in thread From: R.A.L Williams @ 1995-01-12 9:39 UTC (permalink / raw) Look chaps, this is getting a bit silly. Assume that I want to change the functionality of a piece of code that I've picked up from somewhere. Why should I bother with sma****se tricks like the ones that have been suggested? Why not dive in and hack the code! This technique also works in Ada83 and Ada95! The point about 'private' in C++ or Ada is that it is an indication to the user that part of the interface is NOT meant to be mucked about with. You, the user, still have to have sufficient self-discipline not to muck around with it. As an added bonus, the compiler will tell you if you do it by accident. That's what it's for -- to pick up mistakes! Bill Williams ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <3f9bha$r16@gnat.cs.nyu.edu>]
[parent not found: <3fcjp5$b0v@cronkite.seas.gwu.edu>]
* Re: C++ Envy [not found] ` <3fcjp5$b0v@cronkite.seas.gwu.edu> @ 1995-01-16 18:48 ` Robert Dewar [not found] ` <3fe433$evq@nonews.col.hp.com> 1 sibling, 0 replies; 19+ messages in thread From: Robert Dewar @ 1995-01-16 18:48 UTC (permalink / raw) Yes, I typed CFM for CM, sorry, configuration management. If you don't precompile headers, then I don't see how a CM system easily stops you using macros to subvert headers that are simply included (that's what starting this particular thread as I remember). ^ permalink raw reply [flat|nested] 19+ messages in thread
[parent not found: <3fe433$evq@nonews.col.hp.com>]
[parent not found: <3fj4oa$9a8@cronkite.seas.gwu.edu>]
* Re: C++ Envy [not found] ` <3fj4oa$9a8@cronkite.seas.gwu.edu> @ 1995-01-20 5:30 ` Jay M Martin 1995-01-21 21:13 ` David O'Brien 0 siblings, 1 reply; 19+ messages in thread From: Jay M Martin @ 1995-01-20 5:30 UTC (permalink / raw) I am confused : "Change the makefile?". Suppose a programmer is maintaining a piece of code (file) which includes "blah.h". Now the programmer needs to make a change to the code and being a typical macho C type he thinks that "protection is for wimps" and is sure that he could save a few pico seconds per hour if he could massage the insides of the objects of the classes in blah.h directly. So he does the define trick in the file he is modifying and configures it. Note that no changes need to be made to blah.h or the makefile. Of course, a year later after the C stud has gone to greener pastures the classes in blah.h are changed causing all his code to break. Jay ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-20 5:30 ` Jay M Martin @ 1995-01-21 21:13 ` David O'Brien 1995-01-22 6:39 ` Jay M Martin 1995-01-22 21:18 ` Robert Dewar 0 siblings, 2 replies; 19+ messages in thread From: David O'Brien @ 1995-01-21 21:13 UTC (permalink / raw) Jay M Martin (jmartin@kaiwan009.kaiwan.com) wrote: : I am confused : "Change the makefile?". Suppose a programmer : Note that no changes need to be made to blah.h or the makefile. : Of course, a year later after the C stud has gone to greener pastures : the classes in blah.h are changed causing all his code to break. I believe you are referring to my statement, so I'll respond. You have *missed* the point. The point that was brought up originally is that Ada would have better protection over this than C because of CM (configuration management). I stated that C has the same "protection" because large C projects also use CM. In Ada the macho programmer could also change the file they were editing. BUT, the point (for either language) is CM would provide a traciblity that something was changed and who did it. Personally I find this example quite stupid. Like someone else said, "I'd just go change the class definition if is was pissing me off that much.". This is quite a contrived example. Granted it is quite interesting in that fact that someone would think of this, and that it is so simple. But that is it, period. From the way you wrote, I'd say you have some hostility toward C++ programmers. -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-21 21:13 ` David O'Brien @ 1995-01-22 6:39 ` Jay M Martin 1995-01-23 14:37 ` Jules 1995-01-22 21:18 ` Robert Dewar 1 sibling, 1 reply; 19+ messages in thread From: Jay M Martin @ 1995-01-22 6:39 UTC (permalink / raw) >Personally I find this example quite stupid. Like someone else said, >"I'd just go change the class definition if is was pissing me off that >much.". This is quite a contrived example. Granted it is quite >interesting in that fact that someone would think of this, and that it >is so simple. But that is it, period. Do you understand configuration management? You can't just go and change the header file, it is protected. Changing it would require a special form signed by the President, Bozo the Clown,the Pope and their Moms. >From the way you wrote, I'd say you have some hostility toward C++ >programmers. Only incompetent ones (most C programmers). ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-22 6:39 ` Jay M Martin @ 1995-01-23 14:37 ` Jules 1995-01-24 18:56 ` Robert A Duff 0 siblings, 1 reply; 19+ messages in thread From: Jules @ 1995-01-23 14:37 UTC (permalink / raw) In article <jmartin.790756127@kaiwan009>, jmartin@kaiwan009.kaiwan.com (Jay M Martin) writes: > >Do you understand configuration management? You can't just go and >change the header file, it is protected. Changing it would require >a special form signed by the President, Bozo the Clown,the Pope and their >Moms. The original point of this thread was that you don't actually have to change the header file itself to change its meaning in C/C++. If you want to have access to some private members of a class in C++, you merely have to write: #define class struct #define private public #include <another.h> and all the private members suddenly become public. No changes to the header file. C++'s protection just ain't good enough. -- /* Julian R Hall csusb@csv.warwick.ac.uk Flames should be redirected to /dev/null - I don't know what I'm saying myself so don't expect it to make sense all the time! */ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-23 14:37 ` Jules @ 1995-01-24 18:56 ` Robert A Duff 1995-01-25 15:19 ` Robert I. Eachus 0 siblings, 1 reply; 19+ messages in thread From: Robert A Duff @ 1995-01-24 18:56 UTC (permalink / raw) In article <3g0evo$1h2@borage.csv.warwick.ac.uk>, Jules <csusb@csv.warwick.ac.uk> wrote: >The original point of this thread was that you don't actually have to change >the header file itself to change its meaning in C/C++. True, but this seems like a minor point to me. No language can protect against blatantly irresponsible coding tricks. Languages should instead try to prevent problems that happen by accident, as most bugs do. How could you accidentally use the trick being discussed? Anyway, the same is true of Ada: you don't have to change an Ada library package in order to access its private data, and thereby change its meaning. You can, for example, use Unchecked_Conversion for that purpose. Or, you can simply write a child unit. But neither of those can be done by accident. - Bob ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-24 18:56 ` Robert A Duff @ 1995-01-25 15:19 ` Robert I. Eachus 0 siblings, 0 replies; 19+ messages in thread From: Robert I. Eachus @ 1995-01-25 15:19 UTC (permalink / raw) In article <D2xBAz.9pG@world.std.com> bobduff@world.std.com (Robert A Duff) writes: > True, but this seems like a minor point to me. No language can protect > against blatantly irresponsible coding tricks. Languages should instead > try to prevent problems that happen by accident, as most bugs do. How > could you accidentally use the trick being discussed? Because it was in a .h file that was in a #include in some .h file you included? The problem of conflicts between defines in a C or C++ library is a serious one, and the convention of all defined names being all upper case is a help, but in no way solves the problem. -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-21 21:13 ` David O'Brien 1995-01-22 6:39 ` Jay M Martin @ 1995-01-22 21:18 ` Robert Dewar 1995-01-23 22:03 ` Charles H. Sampson 1995-01-25 6:38 ` David O'Brien 1 sibling, 2 replies; 19+ messages in thread From: Robert Dewar @ 1995-01-22 21:18 UTC (permalink / raw) David O'Brien says "I'd just go change the class definition if is was pissing me off that much." Two comments. First this kind of attitude is of course anathema in a well run environment. Second, it makes me think David doesn't understand what a CM system does -- I guess a CM system which made it impossible to mess around because he felt pissed off would really get him mad! It's fascinating how people argue a point, and their style of argument and the points they make provide the best possible argument for the opposite point of view :-) "From the way you wrote, I'd say you have some hostility toward C++ programmers" No, just hostility to programmers who feel they can break the rules whenever they get pissed off :-) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-22 21:18 ` Robert Dewar @ 1995-01-23 22:03 ` Charles H. Sampson 1995-01-25 6:38 ` David O'Brien 1 sibling, 0 replies; 19+ messages in thread From: Charles H. Sampson @ 1995-01-23 22:03 UTC (permalink / raw) In article <3fui32$q6g@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote: >David O'Brien says > > "I'd just go change the class definition if is was pissing me off that much." > >Two comments. First this kind of attitude is of course anathema in a well >run environment. Second, it makes me think David doesn't understand what >a CM system does -- I guess a CM system which made it impossible to mess >around because he felt pissed off would really get him mad! > >It's fascinating how people argue a point, and their style of argument and >the points they make provide the best possible argument for the opposite >point of view :-) > > "From the way you wrote, I'd say you have some hostility toward C++ > programmers" > >No, just hostility to programmers who feel they can break the rules whenever >they get pissed off :-) > Rules? What rules? Real programmers don't need no rules. They just write code to get the job done. Rules are for wimps who don't understand their job well enough to do it by themselves. :-) Charlie ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-22 21:18 ` Robert Dewar 1995-01-23 22:03 ` Charles H. Sampson @ 1995-01-25 6:38 ` David O'Brien 1995-01-25 15:49 ` Jay Martin 1995-01-28 18:52 ` Chris Warack <sys mgr> 1 sibling, 2 replies; 19+ messages in thread From: David O'Brien @ 1995-01-25 6:38 UTC (permalink / raw) In article <3fui32$q6g@gnat.cs.nyu.edu> you wrote: : David O'Brien says :: "I'd just go change the class definition if is was pissing me off that much." : Two comments. First this kind of attitude is of course anathema in a well : run environment. Second, it makes me think David doesn't understand what : a CM system does -- I guess a CM system which made it impossible to mess : around because he felt pissed off would really get him mad! Ok, I have been mis-understood. Let me set this up. A team of us are working on a project. We have a CM tool. Assume the usual C/C++ tools like make. Ok, since the Makefile is so important to producing our program, it is under CM just like all the rest of our source code and headers. Like any project that is concerned with CM, there are "official" builds built by a tech lead, QA, CM, who ever. The Makefile and source code used for these builds come from the CM tool. (Correct me if this isn't setup correctly...) Now, Jim-Bob has written a class and private/protected some member function or attribute I want to access directly. So I decide to use the wrapper header suggested, to get around the type protection. How am I going to compile the beast now? I have to edit the Makefile so that my wrapper header can be added as a dependency to *my* module. (Or, I use scandeps/etc. to automaticly look at the includes and do this for me.) After all this, I am happy with my module. Time to check it back into CM. This must include my wrapper header, or else the program won't be compilable by anyone else (especially the "official" person). BINGO, what do you have??? Traceability! You know who the fool was, and when the change occurred. The next CM report will tell all. Someone earlier said that you could remove the protections from Ada by just editing the source file. You said that CM protected this from happening. How is that different for C ??? : "From the way you wrote, I'd say you have some hostility toward C++ : programmers" : No, just hostility to programmers who feel they can break the rules whenever : they get pissed off :-) btw, I didn't say *I* wanted to mess around. I said that rather than play all these _games_ to get around the protection, I'd just head straight to the source and do it in a [slightly] more legitimized way. My being "pissed off" applies to how ridiculous this thread has become with "oh, this is _terrible_". -- David O'Brien (dobrien@seas.gwu.edu) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-25 6:38 ` David O'Brien @ 1995-01-25 15:49 ` Jay Martin 1995-01-25 23:47 ` Jay Martin 1995-01-28 18:52 ` Chris Warack <sys mgr> 1 sibling, 1 reply; 19+ messages in thread From: Jay Martin @ 1995-01-25 15:49 UTC (permalink / raw) C Hackers response: "We don't need no stinking "wrapper headers"! Jay ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-25 15:49 ` Jay Martin @ 1995-01-25 23:47 ` Jay Martin 0 siblings, 0 replies; 19+ messages in thread From: Jay Martin @ 1995-01-25 23:47 UTC (permalink / raw) The "infinite" powers of C/C++ allows us to guard against the evil private->public redefinition, by placing the following in every include file. #ifdef private Warning! Warning! Idiot Alert! (@)][$#@##$#$@^^^%$#%##!@) #endif (Hopefully won't compile or be defined into something that does, you never know with C) Surely the C preprocessor must be the most powerful invention ever created by mankind! Snicker Jay. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-25 6:38 ` David O'Brien 1995-01-25 15:49 ` Jay Martin @ 1995-01-28 18:52 ` Chris Warack <sys mgr> 1995-01-30 16:44 ` Robert I. Eachus 1 sibling, 1 reply; 19+ messages in thread From: Chris Warack <sys mgr> @ 1995-01-28 18:52 UTC (permalink / raw) In article <3g4rkd$g07@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes: >In article <3fui32$q6g@gnat.cs.nyu.edu> you wrote: >: David O'Brien says > >Ok, I have been mis-understood. Let me set this up. > >A team of us are working on a project. We have a CM tool. Assume the >usual C/C++ tools like make. Ok, since the Makefile is so important to >producing our program, it is under CM just like all the rest of our >source code and headers. Like any project that is concerned with CM, >there are "official" builds built by a tech lead, QA, CM, who ever. The >Makefile and source code used for these builds come from the CM tool. >(Correct me if this isn't setup correctly...) > >Now, Jim-Bob has written a class and private/protected some member >function or attribute I want to access directly. So I decide to use the >wrapper header suggested, to get around the type protection. > >How am I going to compile the beast now? I have to edit the Makefile so >that my wrapper header can be added as a dependency to *my* module. (Or, >I use scandeps/etc. to automaticly look at the includes and do this >for me.) > >After all this, I am happy with my module. Time to check it back into >CM. This must include my wrapper header, or else the program won't be >compilable by anyone else (especially the "official" person). BINGO, >what do you have??? Traceability! You know who the fool was, and when >the change occurred. The next CM report will tell all. But, traceability doesn't do anything for you three years later when the problem would occur -- maintenance changes the rep in the basic abstraction and your code blows up. As you point out, where >>your<< code is concerned the CM system only provides traceability and version control. >Someone earlier said that you could remove the protections from Ada by >just editing the source file. You said that CM protected this from >happening. How is that different for C ??? If you aren't supposed to be working on that module, you cannot check it out. When its >>Not<< your code, the CM system should require "clearance" for you to check it out. In Ada the only way to break the abstraction is through changing the abstraction's code (or using unchecked conversion*). In C, that is not true. *Checking for use of unchecked conversion is extremely easy to automate. Any module with a dependency on unchecked conversion (a with context clause) are an inclusive set of the modules using it. These can be routinely checked to determine legitimate uses of unchecked conversion (like network comm.) with illegitimate uses (like the thread discusses). >: "From the way you wrote, I'd say you have some hostility toward C++ >: programmers" > >: No, just hostility to programmers who feel they can break the rules whenever >: they get pissed off :-) > >btw, I didn't say *I* wanted to mess around. I said that rather than >play all these _games_ to get around the protection, I'd just head >straight to the source and do it in a [slightly] more legitimized way. >My being "pissed off" applies to how ridiculous this thread has become >with "oh, this is _terrible_". Well, if it never happened, it would be ridiculous... :-/ The bottom line: In an Ada system with the checks outlined above, if a programmer wants to change the behavior of an abstraction, they >>have<< to get the idea through the CM system. In many other languages, this is not the case. If the CM system says no (or the programmer never asks), they can hack a work-around that would not be noticed until a maintenance problem occurred. Caveat: If the project uses code inspections, then these hacks might be noticed. Inspections are a lot more expensive than automation, however. I'd bet in most critical systems, you'd probably be doing inspections. Finally, I don't believe cases like this are driven from mischief either. If people don't think something (like CM and speed limits) is important, they tend to ignore it. It seems that programmers (as a whole) are more prone to this than other disciplines. -- Christopher A. Warack, Capt, USAF Computer Science Department, US Air Force Academy cwarack@kirk.usafa.af.mil (719) 472-2401 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-28 18:52 ` Chris Warack <sys mgr> @ 1995-01-30 16:44 ` Robert I. Eachus 0 siblings, 0 replies; 19+ messages in thread From: Robert I. Eachus @ 1995-01-30 16:44 UTC (permalink / raw) In article <3ge3ou$t0a@usafa2.usafa.af.mil> cwarack@picard.usafa.af.mil (Chris Warack <sys mgr>) writes: > Finally, I don't believe cases like this are driven from mischief > either. If people don't think something (like CM and speed limits) > is important, they tend to ignore it. It seems that programmers > (as a whole) are more prone to this than other disciplines. I agree with most of what Chris said, but I have to disagree with this, at least on government contracts. There are rogue programmers who only look good because all the other programmers are suffering from fixing their wild actions, but in general it is the managers who cause the CM system to get bypassed. In my experience, if a manager has a choice between meeting schedule and keeping the configuration under control, he will "do anything" to aviod the schedule slip. The poor programmers feel squeezed--they are the ones who have to deal with the consequences--but that they have no choice. It is my firm belief that on many contracts, the best thing the SPO can do is to from time to time put a gun to the project managers head and tell him to take three weeks NOW and get the CM system back in place. I have worked projects where there were three or more different versions of each build, and the software being used by the programmers had little or no relation to the version the testers were using. (But each version had its own check in/check out protocol enforced...) All in the name of "meeting schedule." -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... ^ permalink raw reply [flat|nested] 19+ messages in thread
* C++ Envy @ 1995-01-05 17:12 SBS Engineering 1995-01-06 17:21 ` Huayong YANG 0 siblings, 1 reply; 19+ messages in thread From: SBS Engineering @ 1995-01-05 17:12 UTC (permalink / raw) Tired of hearing about all those things that C++ can do that Ada87 can't? Then here's a cute trick in C++ that you'll like: #define private public #include compromised_class.h #define private private Confused? The above says that when compiling the class header for compromised_class, all the private stuff will be public, and thus available to the world. A friend showed me the above, and quoted the source as saying that eternal damnation was insufficient punishment... Hard to argue with. -- Pat Rogers progers@acm.org PS: Yes, yes, yes, I know all languages allow one to say silly and questionable things. If you're upset by this post, then get a life! ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-05 17:12 SBS Engineering @ 1995-01-06 17:21 ` Huayong YANG 1995-01-09 16:13 ` Cyrille Comar 1995-01-10 4:07 ` Jay Martin 0 siblings, 2 replies; 19+ messages in thread From: Huayong YANG @ 1995-01-06 17:21 UTC (permalink / raw) SBS Engineering (progers@Starbase.NeoSoft.COM) wrote: > Tired of hearing about all those things that C++ can do that Ada87 can't? > Then here's a cute trick in C++ that you'll like: > #define private public > #include compromised_class.h > #define private private > Confused? The above says that when compiling the class header for > compromised_class, all the private stuff will be public, and thus > available to the world. A friend showed me the above, and quoted the > source as saying that eternal damnation was insufficient punishment... > Hard to argue with. Tell me how the above trick compromises the following class: class T { int an_item; public: int another; }; The data member an_item stays private, it seems to me. -- Huayong ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-06 17:21 ` Huayong YANG @ 1995-01-09 16:13 ` Cyrille Comar 1995-01-10 4:07 ` Jay Martin 1 sibling, 0 replies; 19+ messages in thread From: Cyrille Comar @ 1995-01-09 16:13 UTC (permalink / raw) yang@twain.ucs.umass.edu (Huayong YANG) writes: : : Tell me how the above trick compromises the following class: : : class T : { : int an_item; : public: : int another; : }; : : The data member an_item stays private, it seems to me. : what about using the proposed trick to redefine 'class' to be 'struct'. In which case, 'an_item' will become public, no? -- ------------------------------------------------------------------------ Cyrille Comar, E-mail: comar@cs.nyu.edu Gnat Project US phone: (212) 998-3489 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: C++ Envy 1995-01-06 17:21 ` Huayong YANG 1995-01-09 16:13 ` Cyrille Comar @ 1995-01-10 4:07 ` Jay Martin 1 sibling, 0 replies; 19+ messages in thread From: Jay Martin @ 1995-01-10 4:07 UTC (permalink / raw) yang@twain.ucs.umass.edu (Huayong YANG) writes: :SBS Engineering (progers@Starbase.NeoSoft.COM) wrote :: Tired of hearing about all those things that C++ can do that Ada87 can't? :: Then here's a cute trick in C++ that you'll like: :: #define private public :: #include compromised_class.h :: #define private private :: Confused? The above says that when compiling the class header for :: compromised_class, all the private stuff will be public, and thus :: available to the world. A friend showed me the above, and quoted the :: source as saying that eternal damnation was insufficient punishment... :: Hard to argue with. :Tell me how the above trick compromises the following class: :class T :{ : int an_item; :public: : int another; :}; :The data member an_item stays private, it seems to me. :-- :Huayong Yeah it won't but for large classes I expect most C++-ers will use: class T { public: ... private: ... }//T// style ala Coplien (Advanced C++:Prog Style and Idioms). This is due to that fact that users of the class do not want to have to skip over the top secret implementations details to get to the class interface (public methods) when reading the class. Of course the typical C programmers who get orgasms looking at super efficient implementation details may disagree. Thus, I suspect that this trick will work with most large classes. Jay ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~1995-01-30 16:44 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1995-01-12 9:39 C++ Envy R.A.L Williams [not found] ` <3f9bha$r16@gnat.cs.nyu.edu> [not found] ` <3fcjp5$b0v@cronkite.seas.gwu.edu> 1995-01-16 18:48 ` Robert Dewar [not found] ` <3fe433$evq@nonews.col.hp.com> [not found] ` <3fj4oa$9a8@cronkite.seas.gwu.edu> 1995-01-20 5:30 ` Jay M Martin 1995-01-21 21:13 ` David O'Brien 1995-01-22 6:39 ` Jay M Martin 1995-01-23 14:37 ` Jules 1995-01-24 18:56 ` Robert A Duff 1995-01-25 15:19 ` Robert I. Eachus 1995-01-22 21:18 ` Robert Dewar 1995-01-23 22:03 ` Charles H. Sampson 1995-01-25 6:38 ` David O'Brien 1995-01-25 15:49 ` Jay Martin 1995-01-25 23:47 ` Jay Martin 1995-01-28 18:52 ` Chris Warack <sys mgr> 1995-01-30 16:44 ` Robert I. Eachus -- strict thread matches above, loose matches on Subject: below -- 1995-01-05 17:12 SBS Engineering 1995-01-06 17:21 ` Huayong YANG 1995-01-09 16:13 ` Cyrille Comar 1995-01-10 4:07 ` Jay Martin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox