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

Groups > comp.lang.c > #89442 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  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

#89442 — size of pointers to functions and size of pointer to data question

is the size of a pointer to a function the same size of a 
pointer to data on a given width of processor?
8 bit, 16 bit, 32 bit, 64 bit.

does the latest specification of the language dictate 
sizing of the pointer between pointer to function or pointer to data?

And if different, why?

thanks,

g.

[toc] | [next] | [standalone]

#89443

On Friday, June 17, 2016 at 2:13:57 PM UTC-5, G G wrote:
> is the size of a pointer to a function the same size of a 
> pointer to data on a given width of processor?
> 8 bit, 16 bit, 32 bit, 64 bit.

Either could be larger or smaller than the other.  While it is common for
processors to use the same addressing space for code and data, it is not
universal.  Some microcontrollers have less than 256 bytes of RAM but have
more code than that, so data pointers may be one byte while code pointers
are two.  Some may have 64K bytes of data (two-byte pointers) but between
64K and 16M of code (3-byte pointers).  Some don't have code pointers hold
addresses but instead have a table of all functions whose address is taken
(an approach I'm surprised I haven't seen used more often, especially on
8-bit processors, since few programs have more than a few dozen functions
that are targeted by function pointers, and the cost of the jump table
would be more than offset by the reduced cost of manipulating code pointers.

[toc] | [prev] | [next] | [standalone]

#89451

On 06/17/2016 03:13 PM, G G wrote:
> is the size of a pointer to a function the same size of a 
> pointer to data on a given width of processor?
> 8 bit, 16 bit, 32 bit, 64 bit.

Not necessarily.

It's not even necessarily the case that all pointers to objects have the
same size.

> does the latest specification of the language dictate 
> sizing of the pointer between pointer to function or pointer to data?

The standard imposes very few such requirements:

"A pointer to void shall have the same representation and alignment
requirements as a pointer to a character type.48) Similarly, pointers to
qualified or unqualified versions of compatible types shall have the
same representation and alignment requirements. All pointers to
structure types shall have the same representation and alignment
requirements as each other. All pointers to union types shall have the
same representation and alignment requirements as each other. Pointers
to other types need not have the same representation or alignment
requirements."  (6.2.5p28)

> And if different, why?

The most common reason for function pointer types to have a different
size from object pointer types is if programs and data are stored in
physically different parts of memory, with very different sizes. For
instance, a system might allow only 64KB of code, but 1MB of data, so
function pointers could be 16 bits, while data pointers would have to be
at least 20 bits.

The most common reason why a system might have two different sizes of
pointers is if it has a word size that is bigger than the byte size. On
such a system, a T* pointer where _Alignof(T) >= 16 need merely identify
which word the object starts in; it necessarily starts in the first byte
of the object. If such a system has a maximum of 2GB of memory
installed, a pointer to such an object can be stored in one word (16
bits). However, if _Alignof(T) < 16, the pointer must identify not only
the word, but also the byte within the word where the object starts. As
a result, it needs to store 1 extra bit of information, which means it
must occupy at least three bytes (it might (or might not) be worthwhile
to round the size up to two words.

There are real-world machines that have these characteristics, though I
personally could not identify them.

[toc] | [prev] | [next] | [standalone]

#89454

On 06/17/2016 04:06 PM, James Kuyper wrote:
> On 06/17/2016 03:13 PM, G G wrote:
...
>> does the latest specification of the language dictate 

Note: the questions you're asking have had fundamentally the same answer
in every version of the C standard - nothing relevant to those questions
has changed in "the latest specification".

>> sizing of the pointer between pointer to function or pointer to data?
> 
> The standard imposes very few such requirements:
> 
> "A pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type.48) Similarly, pointers to
> qualified or unqualified versions of compatible types shall have the
> same representation and alignment requirements. All pointers to
> structure types shall have the same representation and alignment
> requirements as each other. All pointers to union types shall have the
> same representation and alignment requirements as each other. Pointers
> to other types need not have the same representation or alignment
> requirements."  (6.2.5p28)

I forgot to point out that "same representation" implies "same size" -
which might seem blindingly obvious - but if it isn't, my response might
seem like a non-sequitur.

[toc] | [prev] | [next] | [standalone]

#89653 — Hope springs eternal (Was: size of pointers to functions and size ...) question

In article <nk1luf$ae3$1@dont-email.me>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>On 06/17/2016 04:06 PM, James Kuyper wrote:
>> On 06/17/2016 03:13 PM, G G wrote:
>...
>>> does the latest specification of the language dictate 
>
>Note: the questions you're asking have had fundamentally the same answer
>in every version of the C standard - nothing relevant to those questions
>has changed in "the latest specification".

I think OP was hoping that it had.  I.e., his question takes the form of:

    Yeah, I know it was pretty yucko in early (non-current) versions of the
    standard, but I was hoping they had finally gotten around to fixing it.

-- 
b w r w g y b r y b

[toc] | [prev] | [next] | [standalone]

#89453

G G <gdotone@gmail.com> writes:
> is the size of a pointer to a function the same size of a 
> pointer to data on a given width of processor?
> 8 bit, 16 bit, 32 bit, 64 bit.

Maybe.  (Incidentally, I don't believe a conforming implementation could
have 8-bit pointers, at least not a conforming hosted implementation.)

> does the latest specification of the language dictate 
> sizing of the pointer between pointer to function or pointer to data?

No.

> And if different, why?

Many, probably most implementations use the same size and
representation for all pointer types.  Those that don't would
have their own implementation-specific reasons for making them
different.  I've heard of systems (AS/400, maybe?) where function
pointers contain extra informatoin.  Or a function pointer could be
implemented as an index into a table (I haven't heard of a system
that actually does that).

POSIX requires the result of dlsym() (a void*) to be convertible to a
function pointer without loss of information.  The simplest way to do
that is for them to have the same representation, or at least for void*
to be at least as big as a function pointer, but POSIX permits other
approaches.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#89618

On 17/06/16 22:14, Keith Thompson wrote:
> G G <gdotone@gmail.com> writes:
>> is the size of a pointer to a function the same size of a
>> pointer to data on a given width of processor?
>> 8 bit, 16 bit, 32 bit, 64 bit.
>
> Maybe.  (Incidentally, I don't believe a conforming implementation could
> have 8-bit pointers, at least not a conforming hosted implementation.)

I read that to mean "8-bit processor", rather than "8-bit wide pointers".

These days, 8-bit processor almost always means "small embedded system" 
which means almost always means "free-standing" rather than "hosted" 
implementations.  And I /think/ 8-bit wide pointers should be allowed 
there (even though it is unusual for "int" to be wider than pointers).

>
>> does the latest specification of the language dictate
>> sizing of the pointer between pointer to function or pointer to data?
>
> No.
>
>> And if different, why?
>

There are some 8-bit devices that have significantly larger code space 
than data space, such as some AVR's with 256 KB flash but only a few KB 
of ram (plus some IO registers in data space).  It would not be 
unreasonable to have 24-bit pointers to functions and 16-bit pointers to 
data.  It is also common on systems like that to have multiple types of 
pointers, such as "far pointers" or pointers to specific flash segments.

I am happy that I haven't had to use these things.  8-bit devices like 
the AVR are fine when you are below 64 KB memory, but beyond that it 
just gets too messy for my tastes - it makes more sense just to jump to 
a small ARM device at that point.

[toc] | [prev] | [next] | [standalone]

#89621

David Brown <david.brown@hesbynett.no> writes:

> On 17/06/16 22:14, Keith Thompson wrote:
>> G G <gdotone@gmail.com> writes:
>>> is the size of a pointer to a function the same size of a
>>> pointer to data on a given width of processor?
>>> 8 bit, 16 bit, 32 bit, 64 bit.
>>
>> Maybe.  (Incidentally, I don't believe a conforming implementation could
>> have 8-bit pointers, at least not a conforming hosted implementation.)
>
> I read that to mean "8-bit processor", rather than "8-bit wide pointers".
>
> These days, 8-bit processor almost always means "small embedded
> system" which means almost always means "free-standing" rather than
> "hosted" implementations.  And I /think/ 8-bit wide pointers should be
> allowed there (even though it is unusual for "int" to be wider than
> pointers).

I think it would go against the spirit of the standard.  For example, in
section 5.2.4.1 "Translation limits" it says the a conforming
implementation must be able to translate "at least one program that
contains at least one instance of..."

 -- 4095 characters in a string literal (after concatenation)
 
 -- 511 identifiers with block scope declared in one block

 -- 1023 members in a single structure or union

The bytes of the array that results from the string literal all need
distinct addresses, and if the identifiers name objects so do those
objects,, and if the structure can actually be used to declare an
instance of it, the members also need distinct addresses.  Of course
there is no requirement to be able to do anything with any of these
objects that would show that the addresses are distinct, but I would
argue that that is being very narrowly literal.

Mind you, if you are limited to 8-bit addresses you will be very happy
indeed to have an compiler that is almost but not quite conforming, so
it's really a non issue.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#89622

On Sunday, June 19, 2016 at 1:57:14 PM UTC-5, Ben Bacarisse wrote:
> I think it would go against the spirit of the standard.  For example, in
> section 5.2.4.1 "Translation limits" it says the a conforming
> implementation must be able to translate "at least one program that
> contains at least one instance of..."

> ...                                                       Of course
> there is no requirement to be able to do anything with any of these
> objects that would show that the addresses are distinct, but I would
> argue that that is being very narrowly literal.

If one isn't willing to read any requirements into the Standard beyond
what's actually there, the Standard is pretty much meaningless once
one gets past the preprocessor stage.  If a compilation unit has #error
directives, a compliant implementation has to output the text thereof
after macro expansion, which implies that a compliant implementation
must have at least that much logic.  Beyond that, though, nothing in
the Standard would forbid an implementation from specifying that each
stack frame may require up to five petabytes of memory except in largely-
unspecified cases where a compiler was able to "optimize" things down
from that, provided that there was at least one source file that the
compiler was able to "optimize" well enough to run.  Since there's no
requirement that the source file in question actually do anything useful,
nor is there any requirement as to what an implementation may do if the
stack overflows, an implementation that always output a do-nothing
executable could be conforming provided it came bundled with a source
file that exercised all the translation limits but wouldn't have any
observable behavior when run correctly.

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.

[toc] | [prev] | [next] | [standalone]

#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  <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"

[toc] | [prev] | [next] | [standalone]

#89659

On Sunday, June 19, 2016 at 5:29:37 PM UTC-5, Keith Thompson wrote:
> 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.

Let me offer a more concrete possible proposal: add definitions of
"selectively-compliant" compilers and "selectively-conforming" programs.
All fully-compliant compilers would be selectively-compliant, but not
vice versa, and all strictly-conforming programs would be selectively-
conforming, but not vice versa.

Feeding any selectively-conforming program to any selectively-complaint
compiler would be required to have one of two effects:

1. The compiler indicates that directives in the program specify an
   optional feature or guarantee that the program requires, but the
   compiler does not support (and compilation should thus be regarded
   as having failed).

2. The compiler processes the program in conformance with all optional
   features and guarantees indicated via program directives.

To facilitate optimization and/or support from limited architectures,
directives could also waive guarantees the Standard would normally
provide by default.

The defining difference between a fully-compliant compiler and a
selectively-compliant one would be that a fully-complaint compiler
must support a Standard-specified minimal set of features.  The
defining difference between a strictly-conforming program and a
selectively-conforming program would be that a strictly-conforming
program would not be allowed to require features beyond the Standard-
defined set that strictly-compliant compilers are required to support.

If an implementation uses 32-bit precision floating-point for everything,
it would be required to refuse compilation of any program which would
use type "double" and which does not include a directive indicating that
it can tolerate low-precision floats.

> 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.)

Given that nothing prohibits freestanding implementations from offering
any combination of features from hosted implementations, I agree that
the value of allowing severely-limited hosted implementations is pretty
minimal; actually, I'd go a bit further and say that the *default*
guarantees for hosted implementations should be extended in a number of
ways beyond what the Standard presently requires, such as extending the
size of "int" to at least 32 bits *except in programs that expressly
waive that guarantee*.

> 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.

The authors of the Standard were afraid that defining more than two
kinds of compilers would cause "market" fragmentation.  I would suggest
that it is not reasonable to suggest that two kinds of C compilers
will suffice for all applications, and the failure of the Standard to
acknowledge that forced the development world to adopt something of an
ad-hoc approach.  Some people seem to think that anything that would
require behavioral guarantees beyond the C Standard should be written in
assembly-language instead, but I fail to see any reason assembly language
should be needed more today than in the 1990s.

[toc] | [prev] | [next] | [standalone]

#89457

On 6/17/2016 3:13 PM, G G wrote:
> is the size of a pointer to a function the same size of a
> pointer to data on a given width of processor?
> 8 bit, 16 bit, 32 bit, 64 bit.

     No.  There are four groups that are required to be "the same,"
in size and in representation:

	- void*, char*, unsigned char*, signed char* all look alike

	- all pointers to structs of whatever kind look alike

	- all pointers to unions of whatever kind look alike

	- all pointers to functions of whatever kind look alike

These four groups need not be the same as each other, nor as any
other kind of pointer (double*, int*, ...).

> does the latest specification of the language dictate
> sizing of the pointer between pointer to function or pointer to data?

     No.

> And if different, why?

     Because C was intended to be fairly easily implementable on a
wide variety of host systems, including systems that use different
representations for different kinds of pointers.  I'm told (can't
vouch for this personally) that function pointers on the IBM AS/400
(or whatever they're calling it nowadays) are 128 bits wide.  You
feel like telling IBM they should change?

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#89459

On 6/17/2016 4:49 PM, Eric Sosman wrote:
> [...]
>     - all pointers to functions of whatever kind look alike

     "Upon further review," as they say in American football, I may
have overstated the case here.  All pointers to functions of whatever
kind can be converted to each other and back again (via casts) without
damage, but I'm not 100% sure that implies a common representation.
(That'd be the easiest way to ensure interconvertibility, but other
ways might be possible.)


-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#89461

On 06/17/2016 04:54 PM, Eric Sosman wrote:
> On 6/17/2016 4:49 PM, Eric Sosman wrote:
>> [...]
>>     - all pointers to functions of whatever kind look alike
> 
>      "Upon further review," as they say in American football, I may
> have overstated the case here.  All pointers to functions of whatever
> kind can be converted to each other and back again (via casts) without
> damage, but I'm not 100% sure that implies a common representation.

It doesn't. All it requires is that every pointer to a function contain
all the information needed to convert it to a pointer to a function of
an arbitrary different type - they need not store that information in
the same way. However, offhand, I can't come up with any motivation for
such differences.

[toc] | [prev] | [next] | [standalone]

#89466

On Friday, June 17, 2016 at 4:15:47 PM UTC-5, James Kuyper wrote:
> It doesn't. All it requires is that every pointer to a function contain
> all the information needed to convert it to a pointer to a function of
> an arbitrary different type - they need not store that information in
> the same way. However, offhand, I can't come up with any motivation for
> such differences.

How about having a jump table for each distinct function signature?  Unless
one needs to allow more than 255 distinct functions for any signature, I
would think that would allow one to use single-byte function pointers (on
some processors, using a jump table would be slower than doing a call to a
direct address, but on some 8-bit microcontrollers the reverse would be
true, since dealing with the upper half of a 16-bit pointer would take
at least as long as the extra jump required when using 8-bit pointer.

[toc] | [prev] | [next] | [standalone]

#89500

On Fri, 17 Jun 2016 12:13:48 -0700 (PDT), G G <gdotone@gmail.com>
wrote:

>is the size of a pointer to a function the same size of a 
>pointer to data on a given width of processor?
>8 bit, 16 bit, 32 bit, 64 bit.
>
>does the latest specification of the language dictate 
>sizing of the pointer between pointer to function or pointer to data?
>
>And if different, why?


No.  Perhaps the most commonly encountered example was in programs for
16-bit x86, in both real and protected mode, where you could set the
implementations to be "small", "medium", "compact" or "large" model,
and each of those would have a different combination of 16 and 32-bit
data and function pointers.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web