Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: size of pointers to functions and size of pointer to data question |
| Date | 2016-06-19 15:29 -0700 |
| Organization | None to speak of |
| Message-ID | <lnbn2wsth0.fsf@kst-u.example.com> (permalink) |
| References | <167656d7-b216-4a24-8b96-d73bf85e81aa@googlegroups.com> <lnziqjtvwm.fsf@kst-u.example.com> <nk6h86$teg$1@dont-email.me> <87eg7tqa69.fsf@bsb.me.uk> <bd42465d-bc9a-49e7-95b5-f713615b95bf@googlegroups.com> |
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 <http://www.ghoti.net/~kst>
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
size of pointers to functions and size of pointer to data question G G <gdotone@gmail.com> - 2016-06-17 12:13 -0700
Re: size of pointers to functions and size of pointer to data question supercat@casperkitty.com - 2016-06-17 12:24 -0700
Re: size of pointers to functions and size of pointer to data question James Kuyper <jameskuyper@verizon.net> - 2016-06-17 16:06 -0400
Re: size of pointers to functions and size of pointer to data question James Kuyper <jameskuyper@verizon.net> - 2016-06-17 16:18 -0400
Hope springs eternal (Was: size of pointers to functions and size ...) question gazelle@shell.xmission.com (Kenny McCormack) - 2016-06-20 14:27 +0000
Re: size of pointers to functions and size of pointer to data question Keith Thompson <kst-u@mib.org> - 2016-06-17 13:14 -0700
Re: size of pointers to functions and size of pointer to data question David Brown <david.brown@hesbynett.no> - 2016-06-19 18:28 +0200
Re: size of pointers to functions and size of pointer to data question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-19 19:57 +0100
Re: size of pointers to functions and size of pointer to data question supercat@casperkitty.com - 2016-06-19 12:32 -0700
Re: size of pointers to functions and size of pointer to data question Keith Thompson <kst-u@mib.org> - 2016-06-19 15:29 -0700
Re: size of pointers to functions and size of pointer to data question supercat@casperkitty.com - 2016-06-20 08:57 -0700
Re: size of pointers to functions and size of pointer to data question Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:49 -0400
Re: size of pointers to functions and size of pointer to data question Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-17 16:54 -0400
Re: size of pointers to functions and size of pointer to data question James Kuyper <jameskuyper@verizon.net> - 2016-06-17 17:15 -0400
Re: size of pointers to functions and size of pointer to data question supercat@casperkitty.com - 2016-06-17 15:04 -0700
Re: size of pointers to functions and size of pointer to data question Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 23:37 -0500
csiph-web