From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-07 17:25:51 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!paloalto-snf1.gtei.net!news.gtei.net!enews.sgi.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc1.bc.home.com.POSTED!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <3b6a453c.1193942215@news.worldonline.nl> <9keejl$fhj@augusta.math.psu.edu> <3c30da40.0108060848.796d9bd9@posting.google.com> <3B6F3216.F410BBFF@home.com> <3B6F3FAE.B9B9FFCF@globetrotter.qc.ca> <3B6F5BB2.A879B933@worldnet.att.net> <%DLb7.26505$B37.537792@news1.rdc1.bc.home.com> <3B7078C3.60194D58@worldnet.att.net> Organization: Psycho-Neurotic Institute for the Very, Very Nervous Reply-To: kaz@ashi.footprints.net User-Agent: slrn/0.9.6.3 (Linux) Message-ID: Date: Wed, 08 Aug 2001 00:25:50 GMT NNTP-Posting-Host: 24.68.85.82 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.bc.home.com 997230350 24.68.85.82 (Tue, 07 Aug 2001 17:25:50 PDT) NNTP-Posting-Date: Tue, 07 Aug 2001 17:25:50 PDT Xref: archiver1.google.com comp.lang.ada:11560 comp.lang.c:72794 comp.lang.c++:80821 Date: 2001-08-08T00:25:50+00:00 List-Id: In article <3B7078C3.60194D58@worldnet.att.net>, James Rogers wrote: >> >The entry may only execute when the boundary condition is true, and >> >no other entry is concurrently accessing the protected object. >> >> All done by the mutex and condition waits. > >Not quite. A mutex and condition waits do not provide a queue >for the waiting tasks. This queue must provide orderly access >to the protected object when the condition allows. If you have >functions associated with the protected object (i.e. read only >functions) then you must allow multiple threads to access the >object through those functions simultaneously, without mutex >locking. At the same time, the entries (functions that update >the object) must be blocked by the mutex so that they are >prevented from simultaneous access, even when the read only >functions are accessing the object. The read only functions >must be blocked from accessing the object when an update >function is accessing the object. So you have a read/write lock with condition variables? I have implemented something exactly like that: a read-write lock in which one can atomically give up a read or write lock to wait on a condition. >What will you do when your platform does not support POSIX threads? Port them. The C++ code that I maintain professionally uses monitors and conditions, and read-write locks. The clases work on Win32, POSIX and PalmOS. I can make them work anywhere. I made them from scratch; they do not simply delegate to POSIX mutexes and conditions. And in fact they were initially developed under Win32. The POSIX and PalmOS ports came out of the blue; they were nowhere on the ``radar'' when the stuff was initially developed. >You will have to recode the non-conforming parts (in a POSIX sense) >to use the local platform's approach. This appears to add a >significant effort in design, coding, testing, and system documentation. >It also adds complexity in configuration management. I understand the point that Ada has built-in standard tasks and synchronization. Standard things are nice, if they exist for every target platform. >> template parameter is greater than zero. The constraint on array >> declarations will take care of this for me: If the parameter is zero >> or negative, the array will be declared as having zero or negative >> elements. (The parameter can't be negative because it's an unsigned type, >> size_t). > >So this means that you must wait until run time to perform the checking. No, the constraint violation on the array declaration is a translation time check. >It also means that you allow the system to create a useless, zero >size communication object. No. You can't declare a zero-sized array in ANSI C++. That is a diagnosable semantic rule violation. >> (In general, you can write a compile_time_assert() macro which exploits >> array constraint checks in order to verify some predicate over a constant >> expression. I learned this trick from Chris Torek of BSDi, Inc). > >Interesting. Does this mean that there is only one such macro in >your system, providing only one size of circular buffer? If so, it >seems to limit the usefulness of defining the buffer in a template. No, the macro takes an arbitrary expression. If that expression is zero, it turns it into some diagnosable constraint rule violation. For instance: #define compile_assert(EXPR) { int array[-1+2*(int)((EXPR)!=0)]; } If the expression is non-zero/true, then an array of 1 element is declared. If it is zero, then an array of -1 elements is declared, triggering a constraint violation. This could be written into the body of a member function of a parametrized class: template foo_class::frob() { compile_assert (foo_param >= 42 && foo_param < 255); } Thus attempted instantiations of the template over foo_param outside of the specified range will cause a diagnostic.