Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: James Kuyper Newsgroups: comp.lang.c Subject: Re: the language Date: Fri, 19 Dec 2014 09:54:28 -0500 Organization: Self Lines: 34 Message-ID: <54943C24.4040407@verizon.net> References: <_x_ew.46881$066.7036@fx16.am4> <87bnn232xd.fsf@bsb.me.uk> <87oar1zory.fsf@bsb.me.uk> <87k31oyity.fsf@bsb.me.uk> <874msswi3g.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Info: mx02.eternal-september.org; posting-host="39e08c8e41e420e151f672c73609c593"; logging-data="2034"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19S1EL2+I4fm1KaxJ09H7oS4pKxzXeGGLg=" User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 In-Reply-To: Cancel-Lock: sha1:PeJMhh8LpNOLrwIrVwDBW4yhlv4= Xref: csiph.com comp.lang.c:55071 On 12/19/2014 07:54 AM, Richard Heathfield wrote: > James Kuyper wrote: ... >> Why not? What prevents the implementation-defined behavior of a given >> construct from having the effect of giving access to that device? Until >> you define "locked-down C" sufficiently tightly to rule out that >> possibility, it's not clear that there's any problem. Why do you think >> that undefined behavior is necessary for this purpose? Why isn't >> implementation-defined behavior sufficient? > > Let's try it. Implementation-defined behaviour is unspecified behaviour > where each implementation documents how the choice is made. Unspecified > behaviour is behaviour where the Standard provides two or more possibilities > and imposes no further requirements on which is chosen in any instance. > > The Standard does not require any implementation to support my position- > sensing device. The closest it comes is in 7.19.2 Streams, but it does not > define or specify how to map a device to a stream, and it does not require > implementations to provide such a mapping to my specific device. > > Since the Standard doesn't require any implementation to support this > device, it will be necessary to implement it oneself on systems where the > implementation doesn't support it. How, without UB? Again, I can't see the problem. If it's possible to connect your device to a given platform, an implementor of C for that platform can provide features with the implementation-defined behavior of causing user-specified I/O to be performed through those connections. The implementor need not define what happens when that I/O is received through those connections by your device, that's the responsibility of the device designer, but you don't have to call the behavior "undefined" to make that work - it is defined, up to the system interface with external devices.