Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #89630

Re: size of pointers to functions and size of pointer to data question

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>

Show all headers | View raw


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


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