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: 10db24,fec75f150a0d78f5 X-Google-Attributes: gid10db24,public X-Google-Thread: 103376,df854b5838c3e14 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,df854b5838c3e14 X-Google-Attributes: gid1014db,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: 146536287 references: <828964950snz@genesis.demon.co.uk> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> 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: "This is so deeply entrenched in the realm of common sense that it isn't even worth mentioning in a standard document! Nevertheless, I have access to the POSIX.1 standard and will look into this." This seems complete nonsense. 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 (especially dubious reasoning about kernels and what not that are totally irrelevant to the semantic specification). The idea that specs are derived from implementations (either by looking at the implementation, or reasoning about it with "common sense" or otherwise) is completely unacceptable! (though unfortunately very common, especially when people are writing in a language that does not make a big deal about separating spec and implementation details). My only at-hand sources are K&R, which has nothing whatever to say on the subject, the Zortech C++ reference, which also has nothing to say, (both describe read, but say nothing about the buffer length), and the Microsoft Runtime Reference which talks about "attempting to read n bytes", but is otherwise unclear. 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. This is of course a rather trivial detail but is instructive with regard to the importance of writing precise specs. Kazimir's claim that the spec obviously requires that the buffer length match the requested, rather than actual length, based on some dubious reasoning about likely implementation models is just the sort of thing that needs to be eliminated from programming practices. 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.