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: 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: mshan@ibm.net (Mike Shannon) Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada) Date: 1996/04/10 Message-ID: <4kets3$ic0@news-s01.ny.us.ibm.net>#1/1 X-Deja-AN: 146632765 references: <828964950snz@genesis.demon.co.uk> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> reply-to: mshan@ibm.net (Mike Shannon) newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu Date: 1996-04-10T00:00:00+00:00 List-Id: In , dewar@cs.nyu.edu (Robert Dewar) writes: >There are two possible semantics that ould >be defined for read (buffer must be at least size of the read argument, >or buffer must be at least size of data read). Both are easy to specify, >both are easy to implement. You cannot rely on common sense > ... I'm a latecomer to this dispute, but this is not smart: char buf[100]; read(fd,buf,1000); Common sense, which tells me not to do such things, is a welcome ally. >We are after all dealing with a language interface where in practice the >proper check (whichever it is) cannot be made, because the called routine >does not know the length of the buffer passed. I think a natural default >assumption, in the absence of any statement to the contrary, is that the >bytes are blindly read into the buffer, and disaster strikes if the number >of bytes read is greater than the buffer length, but otherwise all is well. >Unless there is a VERY clear statement of semantics to the contrary, I >don't see how anyone can call code that makes this assumption obviously >broken. 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. >Specs need to be made precise, >so that a caller knows EXACTLY what the requirements are without having >to guess, or, worse still, examine the actual implementation code. Good specs do not write good code - good programmers do. By the way, how did all this get started? Mike Shannon Houston, Texas Once we had computers and dumb terminals. Now we have computers and stupid terminals. Thanks, Microsoft.