Scott Lurndal <slp53@pacbell.net> wrote:
ram@zedat.fu-berlin.de (Stefan Ram) writes:cross@spitfire.i.gajendra.net (Dan Cross) wrote or quoted:>I'm not a huge fan of Carruth.>
(Text after "| " below was generated by a chatbot asked to explain
narrow contracts and the reduction of efficiency by defining UB.)
>
(Let me guess: You are not a huge fan of chatbots either!
Ok, that was easy.)
>
Chandler talked about how narrow contracts allow optimizations.
>
| - Wide Contract: The function guarantees to handle all possible inputs
| gracefully, usually by returning an error code or throwing an
| exception. (e.g., "If the pointer is null, return ERR_NULL_PTR").
|
| - Narrow Contract: The function only guarantees correct behavior if
| the caller meets specific preconditions. If the preconditions are
| violated, the behavior is undefined.
|
| When is it appropriate to have a narrow contract? Always, when
| performance, memory footprint, or direct hardware control are
| paramount. In operating system kernels, embedded systems, real-time
| applications, and high-performance computing, the overhead of
| validating every pointer, checking every array bound, and verifying
| every integer range is unacceptable.
I have a recollection that a version of IBM's MVS operating
system did, indeed, validate input and output arguments to kernel
functions.
>
Indeed, google says it was called MVS/SP and later MVS/XA (extended addressing).
The Midori folks at Microsoft added bounds checking to all array
accesses in M# (the safe language they wrote Midori in). They
expected performance to be awful; when they provided it, the
overhead was pretty much undetectable: the cost was in the
noise.
- Dan C.
Les messages affichés proviennent d'usenet.