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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,df854b5838c3e14 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: Lawrence Kirby Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/09 Message-ID: <829066525snz@genesis.demon.co.uk>#1/1 X-Deja-AN: 146609094 x-nntp-posting-host: genesis.demon.co.uk references: <4kb2j8$an0@solutions.solon.com> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca> x-mail2news-path: genesis.demon.co.uk organization: none reply-to: fred@genesis.demon.co.uk newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-09T00:00:00+00:00 List-Id: In article dewar@cs.nyu.edu "Robert Dewar" writes: > Sorry, this is wrong, I lied to the *implemention* of the function as > it occurred in Linux. Now it is true that the spec of the function is > different in Linux than in other systems (you quoted the manual pages > that showed this clearly). So of course we have a portability problem > here. Read is different in different systems, not only at the > implementation level, but at the spec level. The program in question > was correct with respect to the spec on "other systems": What makes the code non-portable is that it depends on a behaviour of read() that is not guaranteed by the relevant standard (POSIX in this case). That this may be down to vagueness in the standard doesn't change the fact. In some cases there may be an argument based on clear intent but I don't think this is one of them. Linux just happened to be the first system that showed up the inherent non-portability of the code. Correctness considerations aside, there is never a good reason to pass a value in the 3rd argument to read() that is greater than the available buffer size. IMHO code that does this is highly suspect whether or not you argue that it is legal. I wish more systems were like Linux and trapped this, maybe they will in the future. >>I checked the manual pages for read() on several systems. Linux documents >>that results if the buffer pointed at by buf is outside of the address space >>of the process. On other systems, it is claimed that EFAULT results if >>the buf pointer is directed outside of the address space. > > Kazimir, perhaps you don't understand the whole idea of specs, but that > quote means that code that makes sure that the pointer is directed inside > the address space is OK if the buffer is not overrun! Right, it appears that the spec. for 'other systems' is incorrect (or at least unlikely to match what happens in practice). -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com -----------------------------------------