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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID 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: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,public X-Google-Thread: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/09 Message-ID: #1/1 X-Deja-AN: 146661791 references: <828964950snz@genesis.demon.co.uk> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> <4kets3$ic0@news-s01.ny.us.ibm.net> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-09T00:00:00+00:00 List-Id: Mike said "SIGSEGV is invited, not by any "statement of semantics", but by careless code. If you use these functions without reasonable care, then you experience the consequences. If you do this for a living, you learn not to waste time on unnecessary chances." No, that's confused. First of all, the clear specifications of most specific systems, e.g. SunOS, GUARANTEE *not* to give a sigsegv for the call in question. Linux may or may nt give a SIGSEGV depending on the luck of the draw (where the buffer is in memory). Basically the original code (not mine incidentally, I never write in C these days), was taking a short cut that was reasonably safe on most systems, and this "bug" might have survived for ever in the absence of the check in Linux + the happenstance that the buffr was near the end of memory. True, if someone appended to the file while it was being compiled, disaster could have struck, but most compilers and assemblers tend to assume that this is unlikely and of course in systems with decent file protection it is impossible. So for example, the code as originally written is 100% reliable on OS/2. Of course writing portable code requires careful consideration of various possibilities, and failure to be careful certainly results in portability problems. But it is clear that if the spec for read had been clearer, this bug would NOT have been present in the first place!