Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: size of pointers to functions and size of pointer to data question Date: Sun, 19 Jun 2016 15:29:31 -0700 Organization: None to speak of Lines: 47 Message-ID: References: <167656d7-b216-4a24-8b96-d73bf85e81aa@googlegroups.com> <87eg7tqa69.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="7685"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/EwPltFN/xiEt2hW251kT+" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:0Kq2o36MwnZfRa8qqAqrqdV/Wjo= sha1:QyafH/IjsMFGyc94Zd90xuF+o5E= Xref: csiph.com comp.lang.c:89630 supercat@casperkitty.com writes: [...] > IMHO, the purposes of the Standard could have been better served > by recognizing the concept of compliant-but-non-normative > implementations which fall short of certain features a > strictly-conforming program might expect to be available, but which > document the ways they fall short and are otherwise compliant. > For example, if an implementation has hardware 32-bit float support > but nothing wider, meeting the requirements for double precision > would be very expensive; if code doesn't need precision beyond > what "float" would provide, being able to use 32-bit precision > for everything, including var-args passing, may be more useful > than a guarantee that anything passed to a var-args function > will have precision an application may not need. Likewise, > for programs that don't need recursion, an implementation which > allocates automatic variables statically may offer more useful > performance than one which needs to compute addresses at run-time. (I'll ask you once again to keep your lines a bit shorter so I don't have to reformat them when I post a followup.) The only reasonable way to make implementations that, for example, don't support floating-point wider than 32 bits would be to make wider floating-point types an optional feature. Your idea of "compliant-but-non-normative implementations" doesn't make much sense to me. The word "normative" refers to certain wording in the standard; it doesn't apply to an implementation. I wouldn't object to making some features, such as wide floating-point, 64-bit integers, or even recursion, optional for freestanding implementation. (I don't think there would be much benefit in making them optional for hosted implementation.) But until and unless a future standard make such a change, there's already a perfectly valid and useful solution: provide a C-like implementation that's not fully conforming but still useful. An implementation could, for example, say in its documentation that it conforms to the C11 standard with certain listed exceptions. As far as the standard is concerned, it would simply not be a conforming C implementations -- but its users could rely on most of the guarantees made by the standard. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"