David R Tribble <dtribble@technologist.com> writes:

>James Kuyper <kuyper@wizard.net> writes:
>>
>> Norman Diamond wrote:
>>>
>>> Now, why was %p ever approved anyway?
>>
>> How could you print out the value of a pointer without it? The
>> standard doesn't require that there exist any integer it could be
>> converted to for printing.
>
>Fergus Henderson wrote:
>>     void print_ptr(FILE *f, void *p) {
>                             ^const
>>             int i;
>>             unsigned char buf[sizeof(p)];
>>
>>             memcpy(buf, &p, sizeof(p));
>>             for (i = 0; i < sizeof(p); i++) {
>>                     fprintf("%02x", buf[i]);
>>             }
>>     }
>
>Well, that certainly is preferrable to the bulky
>    fprintf(f, "%p", p);

For some purposes it *is* preferable.  And this catches
many programmers by surprise.

For example, suppose you want to write some kind of
profiler that prints out pointers and usage counts
to a file, for post-processing by some Perl/Python/awk/sh/whatever script.
"How do I print a pointer?", you think, "I know, I'll use %p".
But if you use %p, then it may be very difficult for the script to parse
the output in a portable manner, because the output is implementation
defined, and different C implementations use different kinds of formats.

This particular problem has caught programmers on my current team twice --
once when writing the Mercury profiler (which prints pointers to a file,
as described above), and once when writing the Mercury debugger
(which sends text representations of pointers down a socket connecting
the debugger with the program being debugged).  The first time, the code
worked fine on the original platform it was written on, and we didn't
realize the problem until we got a bug report when porting to a new
system.  That was a couple of years ago, I think.  The second time,
which occurred just today as it happens, I was able to catch it during
code review.  But it's an easy mistake for less experienced programmers
to fall into.

I grant that "%p" is useful for debugging.  However, my negative
experiences with the use of "%p" for other purposes make me wonder
if the net effect is positive.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> James Kuyper wrote:
...
> > I seldom care about the actual value of a pointer (though the issue
> > has come up).
> ...
>
> Printing the value of pointers is pretty useful for debugging,
> especially when you're trying to track down stale pointers and
> multiple deallocations of the same object.  %p provides a nice
> way to do this.

Agreed; all I was saying is that the actual value of the pointer is
technically not needed; as I said in the part you dropped, all that
really matters for that purpose is which pointers compare equal to each
other. Of course, for four or more pointer values, the simplest way to
convey that information is printing the pointer values themselves,
rather than the results of pairwise equality comparisons.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Fergus Henderson wrote:
> I grant that "%p" is useful for debugging.  However, my negative
> experiences with the use of "%p" for other purposes make me wonder
> if the net effect is positive.

So, what, you're suggesting that %p should never have been added to
the library in the first place?

Any item in the library/language can be inappropriate for some use
at one time or another.  As experienced programmers, we should know
when, and when not, to use those items.  %p is only one of a long
list of items that might not work in all circumstances.  That is
not a good reason, though, for arguing that it was a mistake.  At
least we can be thankful that the language is sufficiently powerful
that we aren't forced into using a single technique for each
circumstance.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> David R Tribble wrote:
> >
> > Printing the value of pointers is pretty useful for debugging,
>
> Agreed; all I was saying is that the actual value of the pointer is
> technically not needed; as I said in the part you dropped, all that
> really matters for that purpose is which pointers compare equal to each
> other.

The relative differences (offsets) between the pointers can be relevant
if they point into the same array.

     - John Hauser


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> writes:

>Fergus Henderson wrote:
>> I grant that "%p" is useful for debugging.  However, my negative
>> experiences with the use of "%p" for other purposes make me wonder
>> if the net effect is positive.
>
>So, what, you're suggesting that %p should never have been added to
>the library in the first place?

I wouldn't go that far on only one data point.
Perhaps other people have had more positive experiences with %p.

And there may have been better alternatives than not adding it to
the library at all, e.g. nailing down the output format more tightly
and/or better documenting %p's limitations.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

John Hauser wrote:
>
> James Kuyper wrote:
> >
> > David R Tribble wrote:
> > >
> > > Printing the value of pointers is pretty useful for debugging,
> >
> > Agreed; all I was saying is that the actual value of the pointer is
> > technically not needed; as I said in the part you dropped, all that
> > really matters for that purpose is which pointers compare equal to each
> > other.
>
> The relative differences (offsets) between the pointers can be relevant
> if they point into the same array.

Yes, and I've done that on occasion; however, I've checked them for
equality far more often than I've ever subtracted them. Also, when
you're subtracting pointers, it's safest to let the compiler do it;
there might be "compiler magic" involved in the subtraction:

 printf("%ld", (long)(pointer1-pointer2));

or better, in C9X:

 printf("%td", pointer1-pointer2);


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Norman Diamond wrote:
>>
>> Now, why was %p ever approved anyway?
>
>How could you print out the value of a pointer without it? The standard
>doesn't require that there exist any integer it could be converted to
>for printing.

 void print_ptr(FILE *f, void *p) {
  int i;
  unsigned char buf[sizeof(p)];

  memcpy(buf, &p, sizeof(p));
  for (i = 0; i < sizeof(p); i++) {
   fprintf("%02x", buf[i]);
  }
 }

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Norman Diamond wrote:
> >
> > Actually the idea is not workable, but I have to respond to
> > something first:
> >
> > David R Tribble <dtribble@technologist.com> writes:
> > >"Clive D.W. Feather" wrote:
> ....
> > >>Personally I think it fills a little hole, but I'm not in a lather
> > >>about it.
> >
> > It would fill a hole of exactly the same size that %p filled.
> > That is, if it were workable, it would.
> > Now, why was %p ever approved anyway?
>
> How could you print out the value of a pointer without it? The
> standard doesn't require that there exist any integer it could be
> converted to for printing.
> I seldom care about the actual value of a pointer (though the issue
> has come up).
...

Printing the value of pointers is pretty useful for debugging,
especially when you're trying to track down stale pointers and
multiple deallocations of the same object.  %p provides a nice
way to do this.

Printing function pointer values can also be useful for debugging,
especially when tracking down which callback functions have been
established/called.  Unfortunately, there is no printf() specifier
for function pointers, which is why I suggested %jp.

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:
>
> Norman Diamond wrote:
>>
>> Now, why was %p ever approved anyway?
>
> How could you print out the value of a pointer without it? The
> standard doesn't require that there exist any integer it could be
> converted to for printing.

Fergus Henderson wrote:
>     void print_ptr(FILE *f, void *p) {
                             ^const
>             int i;
>             unsigned char buf[sizeof(p)];
>
>             memcpy(buf, &p, sizeof(p));
>             for (i = 0; i < sizeof(p); i++) {
>                     fprintf("%02x", buf[i]);
>             }
>     }

Well, that certainly is preferrable to the bulky
    fprintf(f, "%p", p);

We could get rid of the redundant %s specifier, too, while we're
at it:
    void print_str(FILE *f, const char *s)
    {
        while (*s != '\0')
            putc(*s, f), s++;
    }

It only takes a couple of uses of %p in debugging code to become
a believer.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

|> In article <36C0DA07.B7FD02CD@technologist.com>, David R Tribble <dtribble@technologist.com> writes:
|> |> "Clive D.W. Feather" wrote:
|> |> >
|> |> > David R Tribble <dtribble@technologist.com> writes:
|> |> >> True, there may be some loss of information when converting any
|> |> >> function pointer to 'void (*)()' - caveat emptor.
|> |> >
|> |> > There can't be much of a loss, because it must be possible to convert
|> |> > the pointer back and get something that works.
|> |>
|> |> Clive is correct.  Despite the fact that the wording of 6.2.5p7
|> |> implies that different function pointer types might have different
|> |> representations, the wording of 6.3.2.3p8 is quite clear about
|> |> casting between function pointer types:
|> |>
|> |>   A pointer to a function of one type may be converted to a pointer
|> |>   to a function of another type and back again; the result shall
|> |>   compare equal to the original pointer.
|>
|> The same is true for object pointers, incidentally.

No.  You can only cast reliably to void* (or char*) and back, but not to
any other type.  With function pointers any type is as good as the other.

--
Andreas Schwab                                      "And now for something
schwab@issan.cs.uni-dortmund.de                      completely different"
schwab@gnu.org
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Norman Diamond wrote:
>
> Actually the idea is not workable, but I have to respond to something first:
>
> In article <36B89F51.56BF725B@technologist.com>, David R Tribble <dtribble@technologist.com> writes:
> >"Clive D.W. Feather" wrote:
....
> >>Personally I think it fills a little hole, but I'm not in a lather
> >>about it.
>
> It would fill a hole of exactly the same size that %p filled.
> That is, if it were workable, it would.
> Now, why was %p ever approved anyway?

How could you print out the value of a pointer without it? The standard
doesn't require that there exist any integer it could be converted to
for printing.
I seldom care about the actual value of a pointer (though the issue has
come up). I'm usually more interested in knowing which pointers in a set
are equal to each other. In principle all I need to do is to print out
p[i]==p[j], for all cases where j>i. In practice, it's much simpler to
print out the pointer values.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <79m1eq$12$1@nntpd.lkg.dec.com>,
  diamond@tbj.dec.com (Norman Diamond) wrote:
>
> Actually this points out why it isn't workable.  A pointer to void
> is a single type.  A pointer to a function is one of an infinite
> number of possible types.  The standard guarantees that a pointer
> to a function can be converted to a different type of pointer to
> function and converted back and compare equal, but this isn't enough
> to make the types smell alike.  One type of pointer to function could
> have sizeof be 5 with 13 unused bits (holes) while another type of
> pointer to function could have sizeof be 7 with 31 unused bits.
> %jp won't know how many bytes to pull off the stack.

Thats just an implementation detail. You could apply the same argument to
floats & doubles which are passed to printf. The compiler solves it by
implicitly converting float arguments to double when passing them to varargs
functions. The same solution is available for function pointers... when
passing to a varargs function, convert it to any one of the standard types.
Then %jp knows what type of function pointer its using.

Mark Williams

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
>
> David R Tribble <dtribble@technologist.com> writes:
>> True, there may be some loss of information when converting any
>> function pointer to 'void (*)()' - caveat emptor.
>
> There can't be much of a loss, because it must be possible to convert
> the pointer back and get something that works.

Clive is correct.  Despite the fact that the wording of 6.2.5p7
implies that different function pointer types might have different
representations, the wording of 6.3.2.3p8 is quite clear about
casting between function pointer types:

  A pointer to a function of one type may be converted to a pointer
  to a function of another type and back again; the result shall
  compare equal to the original pointer.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36C0DA07.B7FD02CD@technologist.com>, David R Tribble <dtribble@technologist.com> writes:
|> "Clive D.W. Feather" wrote:
|> >
|> > David R Tribble <dtribble@technologist.com> writes:
|> >> True, there may be some loss of information when converting any
|> >> function pointer to 'void (*)()' - caveat emptor.
|> >
|> > There can't be much of a loss, because it must be possible to convert
|> > the pointer back and get something that works.
|>
|> Clive is correct.  Despite the fact that the wording of 6.2.5p7
|> implies that different function pointer types might have different
|> representations, the wording of 6.3.2.3p8 is quite clear about
|> casting between function pointer types:
|>
|>   A pointer to a function of one type may be converted to a pointer
|>   to a function of another type and back again; the result shall
|>   compare equal to the original pointer.

The same is true for object pointers, incidentally.  The following
is actually undefined:

    double fred;
    printf("%p\n",&fred);


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <79m1eq$12$1@nntpd.lkg.dec.com>,
Norman Diamond <diamond@tbj.dec.com> wrote:
>
>>To make things simple, here is the complete set of changes to the
>>C9X draft needed to add this feature:
>[...]
>>Change 7.19.6.1p8 by adding the bracketed text:
>>  p  The argument shall be a pointer to void{, or if the format
>>     specifier was preceded by a j modifier, the argument shall
>>     be a pointer to a function}.
>
>Actually this points out why it isn't workable.  A pointer to void
>is a single type.  A pointer to a function is one of an infinite
>number of possible types.  The standard guarantees that a pointer
>to a function can be converted to a different type of pointer to
>function and converted back and compare equal, but this isn't enough
>to make the types smell alike.  One type of pointer to function could
>have sizeof be 5 with 13 unused bits (holes) while another type of
>pointer to function could have sizeof be 7 with 31 unused bits.
>%jp won't know how many bytes to pull off the stack.

Change 7.19.6.1p8 by adding the bracketed text:
  p  The argument shall be a pointer to void{, or if the format
     specifier was preceded by a j modifier, the argument shall
     be a pointer to a function of type void(void).}
                                ^^^^^^^^^^^^^^^^^^


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> writes:
>> To make things simple, here is the complete set of changes to the
>> C9X draft needed to add this feature:
> [...]
>> Change 7.19.6.1p8 by adding the bracketed text:
>>   p  The argument shall be a pointer to void{, or if the format
>>      specifier was preceded by a j modifier, the argument shall
>>      be a pointer to a function}.

Norman Diamond wrote:
> Actually this points out why it isn't workable.  A pointer to void
> is a single type.  A pointer to a function is one of an infinite
> number of possible types.  The standard guarantees that a pointer
> to a function can be converted to a different type of pointer to
> function and converted back and compare equal, but this isn't enough
> to make the types smell alike.  One type of pointer to function could
> have sizeof be 5 with 13 unused bits (holes) while another type of
> pointer to function could have sizeof be 7 with 31 unused bits.
> %jp won't know how many bytes to pull off the stack.

You didn't read my footnote:

> (Note: It is assumed that pointer to function types may have
> different representations than other (data) pointer types; see
> 6.2.5p27.  It is also assumed that all pointer to function types
> have the same representation; 6.2.5p27 does not, however, state
> this.
>  If this poses a problem, we could further stipulate that
> the argument for a %jp format specifier is of type 'pointer to
> function taking unspecified arguments and returning void', i.e.,
> 'void (*)()'.)

Like I said, if type 'pointer to any function' is a problem, we
can simply limit the argument for "%jp" to be the single type
'void (*)()'.

True, there may be some loss of information when converting any
function pointer to 'void (*)()' - caveat emptor.  But I'd be
interested in hearing about existing C implementations that really
do use different representations for different function pointer
types (modulo the 'near' and 'far' pointer debacle of Wintel).

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Actually the idea is not workable, but I have to respond to something first:

In article <36B89F51.56BF725B@technologist.com>, David R Tribble <dtribble@technologist.com> writes:
>"Clive D.W. Feather" wrote:
>>Douglas A. Gwyn <DAGwyn@null.net> writes
[Attribution stolen:]
>>>>Let's have a show of hands:
>>>A "show of hands" here is not indicative of very much...
>>A show of hands indicates one thing: if nobody on this newsgroup
>>supports this idea, there's little point in continuing with it in C9X
>>timescales.
>Well, obviously *I* support it.

A show of hands doesn't work politically because ISO's rules are set out.
A show of hands only shows what the real world wants.  Are lowly lusers
even irrelevant in this forum?

>>Personally I think it fills a little hole, but I'm not in a lather
>>about it.

It would fill a hole of exactly the same size that %p filled.
That is, if it were workable, it would.
Now, why was %p ever approved anyway?

>To make things simple, here is the complete set of changes to the
>C9X draft needed to add this feature:
[...]
>Change 7.19.6.1p8 by adding the bracketed text:
>  p  The argument shall be a pointer to void{, or if the format
>     specifier was preceded by a j modifier, the argument shall
>     be a pointer to a function}.

Actually this points out why it isn't workable.  A pointer to void
is a single type.  A pointer to a function is one of an infinite
number of possible types.  The standard guarantees that a pointer
to a function can be converted to a different type of pointer to
function and converted back and compare equal, but this isn't enough
to make the types smell alike.  One type of pointer to function could
have sizeof be 5 with 13 unused bits (holes) while another type of
pointer to function could have sizeof be 7 with 31 unused bits.
%jp won't know how many bytes to pull off the stack.

--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36BF13EC.65750BE7@technologist.com>, David R Tribble
<dtribble@technologist.com> writes
>True, there may be some loss of information when converting any
>function pointer to 'void (*)()' - caveat emptor.

There can't be much of a loss, because it must be possible to convert
the pointer back and get something that works.

--
Clive D.W. Feather    | Director of            | Work: <clive@demon.net>
Tel: +44 181 371 1138 |   Software Development | Home: <clive@davros.org>
Fax: +44 181 371 1037 | Demon Internet Ltd.    | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
>
> Douglas A. Gwyn <DAGwyn@null.net> writes
> >> Let's have a show of hands:
> >A "show of hands" here is not indicative of very much...
>
> A show of hands indicates one thing: if nobody on this newsgroup
> supports this idea, there's little point in continuing with it in C9X
> timescales.

Well, obviously *I* support it.

> Personally I think it fills a little hole, but I'm not in a lather
> about it.

To make things simple, here is the complete set of changes to the
C9X draft needed to add this feature:

Change 7.19.6.1p7 by adding the bracketed text:

  j  Specifies that a following d, i, o, u, x, or X conversion
     specifier applies to an intmax_t or uintmax_t argument; or
     that a following n conversion specifier applies to a pointer
     to an intmax_t argument{; or that a following p conversion
     specifier applies to a pointer to a function argument}.

Change 7.19.6.1p8 by adding the bracketed text:

  p  The argument shall be a pointer to void{, or if the format
     specifier was preceded by a j modifier, the argument shall
     be a pointer to a function}.  The value of the pointer is
     converted to a sequence of printable characters, in an
     implementation-defined manner.

Change 7.19.6.2p11 by adding the bracketed text:

  j  Specifies that a following d,i, o, u, x, X, or n conversion
     specifier applies to an argument with type intmax_t or
     uintmax_t{; or that a following p conversion specifier applies
     to an argument with pointer to function type}.

Change 7.19.6.2p12 by adding the bracketed text:

  p  Matches an implementation-defined set of sequences, which
     should be the same as the set of sequences that may be
     produced by the %p {or %jp} conversion of the fprintf function.
     The corresponding argument shall be a pointer to a pointer to
     void{, or if the format specifier was preceded by a j modifier,
     the argument shall be a pointer to a pointer to a function}.
     The interpretation of the input item is implementation-defined.
     If the input item is a value converted earlier during the same
     program execution, the pointer that results shall compare equal
     to that value; otherwise the behavior of the %p {or %jp}
     conversion is undefined.

(Note: It is assumed that pointer to function types may have
different representations than other (data) pointer types; see
6.2.5p27.  It is also assumed that all pointer to function types
have the same representation; 6.2.5p27 does not, however, state
this.  If this poses a problem, we could further stipulate that
the argument for a %jp format specifier is of type 'pointer to
function taking unspecified arguments and returning void', i.e.,
'void (*)()'.)

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36B1BB7A.BBF059D4@null.net>, Douglas A. Gwyn
<DAGwyn@null.net> writes
>> Let's have a show of hands:
>A "show of hands" here is not indicative of very much...

A show of hands indicates one thing: if nobody on this newsgroup
supports this idea, there's little point in continuing with it in C9X
timescales.

Personally I think it fills a little hole, but I'm not in a lather about
it.

--
Clive D.W. Feather    | Director of            | Work: <clive@demon.net>
Tel: +44 181 371 1138 |   Software Development | Home: <clive@davros.org>
Fax: +44 181 371 1037 | Demon Internet Ltd.    | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <78kj1c$7hb$3@news.clinet.fi>,
Kristoffer Lawson  <setok@oksidi.fishpool.com> wrote:
>
>In comp.std.c Francis Glassborow <francis@robinton.demon.co.uk> wrote:
>: I would think that fwrite/fread should meet your needs.  If we had a
>: portable way of providing a function address lookup table (Note that you
>: cannot have an array of function pointers because there is no generic
>: function pointer) that would (I think) be preferable.
>
>Well this is not a problem as all the functions I store are of the same
>type. As for generic function pointers can't that mostly be done by

So why don't you want to have an array and pass the index to the network
client?  The nice thing about this is that it can even work across
different server processes, so long as the array indexes are consistent.

>using void pointers and then casting to whatever type of function is used?

It's only well-defined to cast object pointers to/from void*, not function
pointers.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> Kristoffer Lawson <setok@oksidi.fishpool.com> writes
> >In comp.std.c David R Tribble <dtribble@technologist.com> wrote:
> >
> >: So, I ask, could we add a printf/scanf format specifier for
> >: function pointers?  Something similar to %p, perhaps %jp?
...
> >
> >That sounds like a sensible proposal.
>
> First can [it] be done otherwise?  Yes (using an array of char).
> Second can it be done easily? Yes sort of.
> Will it have wide usage?  Probably not.

Francis Glassborow wrote:
> In that case is it worth the not inconsiderable cost (Assume 25
> attendees at a meeting at $3000 per person = $75000 per week = about
> $3000 per hour) of adding to the Standard?  The answer is probably
> 'No' as there are other things of greater cost benefit to do first.

This is pure sophistry.  I'll admit that using the cost of committee
meetings as an argument against a proposal is a novel one (and one
I've never seen before), but I simply can't take it seriously.

The cost of these discussions on the newgroups is entirely minimal,
and perform the great service of hashing out such things like my
proposal *before* they are even brought to the committee formally.

So please, do you have any *technical* reasons why my proposal is
unworthy of discussion?

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <78kj1c$7hb$3@news.clinet.fi>, setok@oksidi.fishpool.com
says...

[ ... ]

> Well this is not a problem as all the functions I store are of the same
> type. As for generic function pointers can't that mostly be done by
> using void pointers and then casting to whatever type of function is used?

No.  You cannot cast a pointer to a function to a pointer to void,
then back, and depend upon getting anything useful at all.  With quite
a few current machines, you've got a single, flat address space and a
pointer to void can address any of it, so this will work perfectly
well.  There's NO guarantee that this is the case.

Just for example, in medium memory model under MS-DOS, a pointer to
data is 16 bits, but a pointer to a function is 32 bits.  I wouldn't
recommend this as a particularly wonderful situation, but it
definitely IS legal.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c Barry Margolin <barmar@bbnplanet.com> wrote:
:>
:>Well this is not a problem as all the functions I store are of the same
:>type. As for generic function pointers can't that mostly be done by

: So why don't you want to have an array and pass the index to the network
: client?  The nice thing about this is that it can even work across
: different server processes, so long as the array indexes are consistent.

It's an extra lookup that I don't need for the application in question.
If I could directly pass the pointer values and then read them back
into a similar pointer I could call it in a straightforward way without
having to lookup the index first from a table. Of course it is only one
lookup.. ;-)

:>using void pointers and then casting to whatever type of function is used?

: It's only well-defined to cast object pointers to/from void*, not function
: pointers.

Yes. I wasn't aware that functions are not considered objects. This could
potentially be annoying.

--
         -     ---------- = = ---------//--+
         |    /     Kristoffer Lawson      |    www.fishpool.com
         +-> |    setok@fishpool.com       |  - - --+
             |-- Fishpool Creations Ltd - /         |
             +-------- = - - - = ---------      /~setok/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36AE1722.1F811868@technologist.com>, David R Tribble
<dtribble@technologist.com> writes
>This is pure sophistry.  I'll admit that using the cost of committee
>meetings as an argument against a proposal is a novel one (and one
>I've never seen before), but I simply can't take it seriously.

When any organisation with limited resources has to prioritise actions
the cost benefit analysis is one of the tools used to arrive at
decisions.  We do not have unlimited resources and the per hour cost of
meetings is much higher than people realise.  If we had nothing else to
do fine, but we have so you must justify why you proposal is more
important and worth the cost in committee time.  That is the real World.

Actually the cost in real terms of Internet discussions is considerable.
Or do you value your own time so little?


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Let's say, your OS-platform is DOS, and your program has more
than one code segment - if you load the program the next time,
the offset of a function pointer is the same as erery time, but the
segment portion may vary. So you will make a call to a memory
location, where any code maybe (perhaps a jump to the BIOS to
format your harddisk).

Let's say, your OS-platform is MS-Windows, and your program
code is more than one Windows-memomy-segment (I don't know
the length). MS-Windows may had swapped this memory segment,
so you will again call any code without knowing if it's your function.

Klaus-Werner Konrad




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
> In that case is it worth the not inconsiderable cost (Assume 25
> attendees at a meeting at $3000 per person = $75000 per week = about
> $3000 per hour) of adding to the Standard?  The answer is probably
> 'No' as there are other things of greater cost benefit to do first.

David R Tribble <dtribble@technologist.com> writes
>> This is pure sophistry.  I'll admit that using the cost of committee
>> meetings as an argument against a proposal is a novel one (and one
>> I've never seen before), but I simply can't take it seriously.

Francis Glassborow wrote:
> When any organisation with limited resources has to prioritise actions
> the cost benefit analysis is one of the tools used to arrive at
> decisions.  We do not have unlimited resources and the per hour cost
> of meetings is much higher than people realise.  If we had nothing
> else to do fine, but we have so you must justify why you proposal is
> more important and worth the cost in committee time.  That is the real
> World.
>
> Actually the cost in real terms of Internet discussions is
> considerable. Or do you value your own time so little?

Compared to the cost of ISO committee meetings, the cost of the
time I spend on newsgroups is small.  (I can also claim it as part
of my job duties, i.e., keeping abreast of language standards.)

Besides, the point I was making was that newsgroup discussions are
just the sort of arena where priorities are debated for probable
proposals.  Simply rejecting a proposal outright because of
committee meeting costs isn't logical; rejecting a proposal because
its relative merit falls well below most other proposals is
more reasonable.

But we can't know if the proposal at hand has merit or not unless
we debate its technical aspects (in some forum, such as this one),
can we now?  I haven't seen enough debate yet to consider the
matter closed.

Let's have a show of hands:

    Is it worthwhile to add a format specifier to printf and
    scanf (something like "%jp") to allow for the writing/reading
    of function pointer values?

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> Let's have a show of hands:
>     Is it worthwhile to add a format specifier to printf and
>     scanf (something like "%jp") to allow for the writing/reading
>     of function pointer values?

A "show of hands" here is not indicative of very much...
Anyway, I vote against it.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36B10C77.5ABD03D@technologist.com> David R Tribble <dtribble@technologist.com> writes:
>
>Francis Glassborow wrote:
>> In that case is it worth the not inconsiderable cost (Assume 25
>> attendees at a meeting at $3000 per person = $75000 per week = about
>> $3000 per hour) of adding to the Standard?  The answer is probably
>> 'No' as there are other things of greater cost benefit to do first.
>
>David R Tribble <dtribble@technologist.com> writes
>>> This is pure sophistry.  I'll admit that using the cost of committee
>>> meetings as an argument against a proposal is a novel one (and one
>>> I've never seen before), but I simply can't take it seriously.
>
>Francis Glassborow wrote:
>> When any organisation with limited resources has to prioritise actions
>> the cost benefit analysis is one of the tools used to arrive at
>> decisions.  We do not have unlimited resources and the per hour cost
>> of meetings is much higher than people realise.  If we had nothing
>> else to do fine, but we have so you must justify why you proposal is
>> more important and worth the cost in committee time.  That is the real
>> World.
>>
>> Actually the cost in real terms of Internet discussions is
>> considerable. Or do you value your own time so little?
>
>Compared to the cost of ISO committee meetings, the cost of the
>time I spend on newsgroups is small.  (I can also claim it as part
>of my job duties, i.e., keeping abreast of language standards.)

This is not small for some people.

>Besides, the point I was making was that newsgroup discussions are
>just the sort of arena where priorities are debated for probable
>proposals.

And many proposals that have made their way into the committee and
the standard have come from the newsgroups.  And will continue to
(for instance, the Defect Reports process will be using them at some level).

>Simply rejecting a proposal outright because of
>committee meeting costs isn't logical;

Francis did not reject the "proposal" outright.

It may not be technically logically, but it is logical in other ways,
so to say it isn't doesn't make it not.  The business world functions
this way on many decisions.  It is simply and definitely not novel at all.

>rejecting a proposal because
>its relative merit falls well below most other proposals is
>more reasonable.

The two are connected, but totally disjoint.
In some cases, if the merits fall, then it is considered "too expensive".

>But we can't know if the proposal at hand has merit or not unless
>we debate its technical aspects (in some forum, such as this one),
>can we now?  I haven't seen enough debate yet to consider the
>matter closed.
>
>Let's have a show of hands:
>
>    Is it worthwhile to add a format specifier to printf and
>    scanf (something like "%jp") to allow for the writing/reading
>    of function pointer values?

I would not be interested in seeing it in the standard.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- New Release!  We now do Windows too.
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.com ***
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> Note that you
> cannot have an array of function pointers because there is no generic
> function pointer

Of course you can have an array of function pointers -- all function
pointer types are generic types.  6.3.2.3p8:

 A pointer to a function of one type may be converted to a
 pointer to a function of another type and back again; the
 result shall compare equal to the original pointer.

-Larry Jones

TIME?!  I just finished the first problem! -- Calvin


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36ACED0C.167EB0E7@sdrc.com>, Larry Jones
<larry.jones@sdrc.com> writes
>Of course you can have an array of function pointers -- all function
>pointer types are generic types.  6.3.2.3p8:
>
>       A pointer to a function of one type may be converted to a
>       pointer to a function of another type and back again; the
>       result shall compare equal to the original pointer.

Yes I had forgotten that, but which document are you referencing?  Your
quoted para is in 6.3.4 Cast operators in my copy 05 ISO/IEC 9899:1990

Of course the basic problem is how to track what kind of pointer you
need to convert an array member into before calling through it.



Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c Francis Glassborow <francis@robinton.demon.co.uk> wrote:
: I would think that fwrite/fread should meet your needs.  If we had a
: portable way of providing a function address lookup table (Note that you
: cannot have an array of function pointers because there is no generic
: function pointer) that would (I think) be preferable.

Well this is not a problem as all the functions I store are of the same
type. As for generic function pointers can't that mostly be done by
using void pointers and then casting to whatever type of function is used?
Of course then you need some sort of information to define the exact cast
to use, but I'm not sure how a generic function pointer table would help?

--
         -     ---------- = = ---------//--+
         |    /     Kristoffer Lawson      |    www.fishpool.com
         +-> |    setok@fishpool.com       |  - - --+
             |-- Fishpool Creations Ltd - /         |
             +-------- = - - - = ---------      /~setok/


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> Yes I had forgotten that, but which document are you referencing?  Your
> quoted para is in 6.3.4 Cast operators in my copy 05 ISO/IEC 9899:1990

The current C9X draft -- for some peculiar reason, it's what I tend to
have at hand. ;-)

> Of course the basic problem is how to track what kind of pointer you
> need to convert an array member into before calling through it.

Yea, verily.

-Larry Jones

The problem with the future is that it keeps turning into the present.
-- Hobbes


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kristoffer Lawson wrote:
>
> Francis Glassborow <francis@robinton.demon.co.uk> wrote:
>: I would think that fwrite/fread should meet your needs.  If we had a
>: portable way of providing a function address lookup table (Note that
>: you cannot have an array of function pointers because there is no
>: generic function pointer) that would (I think) be preferable.
>
> Well this is not a problem as all the functions I store are of the
> same type. As for generic function pointers can't that mostly be done
> by using void pointers and then casting to whatever type of function
> is used? Of course then you need some sort of information to define
> the exact cast to use, but I'm not sure how a generic function pointer
> table would help?

No, you can't use 'void*' to convert between function pointers;
that was the crux of my original post that started this thread.

However, all function pointers are assumed to be inter-convertible,
i.e., that they have fundamentally the same underlying representation,
so you can safely convert them to 'void(*)()' and back without loss
of information.  But remember that 'void(*)()' function pointers
may have an entirely different representation (and maybe even a
different size) than 'void*' data pointers.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <dtribble@technologist.com> wrote:
> > I notice that there is no convenient way to write (and read)
> > function pointer values in C (nor C++).
...

Jack Klein wrote:
> There are two things you can do with a function:  call it or take its
> address.  There has never been any guarantee that you could represent
> its address to the outside world.  Is there a realistic need to store
> the address of a function in a file?

Of course; I can think of a few uses for it.

> However you are allowed to access any object whatsoever as an array of
> unsigned chars (including an uninitialized one at least in C) so if
> there is some reason to do this I can't think of any cause for
> undefined behavior.
>
> Of course there is no guarantee that the value read back from the file
> is valid, even from another execution of the same program.

But what about storing a function pointer value and then retrieving
it later in the *same* program execution?  I can do this with data
pointers, so why not function pointers?

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <78d49i$gkn$4@news.clinet.fi>, Kristoffer Lawson
<setok@oksidi.fishpool.com> writes
>In comp.std.c David R Tribble <dtribble@technologist.com> wrote:
>
>: So, I ask, could we add a printf/scanf format specifier for function
>: pointers?  Something similar to %p, perhaps %jp?
>
>:     void   (*fp)();
>:     ...
>:     printf("%jp", (void (*)())fp);
>
>That sounds like a sensible proposal.

First can be done otherwise?  Yes (using an array of char)
Second can it be done easily? Yes sort of
Will it have wide usage?  Probably not.

In that case is it worth the not inconsiderable cost (Assume 25
attendees at a meeting at $3000 per person = $75000 per week = about
$3000 per hour) of adding to the Standard?  The answer is probably 'No'
as there are other things of greater cost benefit to do first.

>
>On a slightly related topic: I need a method by which I can
>portably transfer a function pointer across a network, and then back
>again to the original process. That would save having lookup tables as
>the process on the other side of a network could simply say "call this
>function" by converting the value back to a pointer.
>
>My question is can this currently be done in a portable way? Can I use
>fwrite/fread to do this? Is printf and scanf enough or is there something
>I need to worry about? Not that a dynamic pointer array accessed by
>indexes is that terribly difficult, but it would be nice to have a straight
>method.

I would think that fwrite/fread should meet your needs.  If we had a
portable way of providing a function address lookup table (Note that you
cannot have an array of function pointers because there is no generic
function pointer) that would (I think) be preferable.

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 22 Jan 1999 21:34:23 GMT, David R Tribble
<dtribble@technologist.com> wrote:

>
> I notice that there is no convenient way to write (and read) function
> pointer values in C (nor C++).
>
> My first thought was to simply cast the function pointer to 'void*'
> and then use printf("%p"), but this isn't guaranteed to work on all
> systems (because function pointers and data pointers might have
> different representations and even different sizes).  The standard,
> in fact, makes no guarantees about converting a function pointer
> into anything other than another function pointer.
>
> My next idea was the usual union hack, to wit, something like this:
>
>     typedef void    (*fp_t)();             // Func ptr
>
>     union FPtrHack
>     {
>         void            (*fp)();           // Func ptr
>         unsigned char   b[sizeof(fp_t)];   // Bytes
>     };
>
>     void printFuncPtr(void (*fp)())
>     {
>         union FPtrHack   u;
>         int              i;
>
>         u.fp = fp;
>         for (i = 0;  i < sizeof(u.fp);  i++)
>             printf("%02X", u.b[i]);
>     }
>
> Reading a function pointer value back in from a file would be done
> in a similar fashion.
>
> But this is a pain, I have the nagging feeling that this is inviting
> undefined behavior.
>
> So, I ask, could we add a printf/scanf format specifier for function
> pointers?  Something similar to %p, perhaps %jp?
>
>     void   (*fp)();
>     ...
>     printf("%jp", (void (*)())fp);
>
> We would probably have to mandate that the pointer value must be
> cast to 'void (*)()' to be completely portable/reliable.
>
> -- David R. Tribble, dtribble@technologist.com --

<Jack>

There are two things you can do with a function:  call it or take its
address.  There has never been any guarantee that you could represent
its address to the outside world.  Is there a realistic need to store
the address of a function in a file?

However you are allowed to access any object whatsoever as an array of
unsigned chars (including an uninitialized one at least in C) so if
there is some reason to do this I can't think of any cause for
undefined behavior.

Of course there is no guarantee that the value read back from the file
is valid, even from another execution of the same program.

</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In comp.std.c David R Tribble <dtribble@technologist.com> wrote:

: So, I ask, could we add a printf/scanf format specifier for function
: pointers?  Something similar to %p, perhaps %jp?

:     void   (*fp)();
:     ...
:     printf("%jp", (void (*)())fp);

That sounds like a sensible proposal.

On a slightly related topic: I need a method by which I can
portably transfer a function pointer across a network, and then back
again to the original process. That would save having lookup tables as
the process on the other side of a network could simply say "call this
function" by converting the value back to a pointer.

My question is can this currently be done in a portable way? Can I use
fwrite/fread to do this? Is printf and scanf enough or is there something
I need to worry about? Not that a dynamic pointer array accessed by
indexes is that terribly difficult, but it would be nice to have a straight
method.

--
         -     ---------- = = ---------//--+
         |    /     Kristoffer Lawson      |    www.fishpool.com
         +-> |    setok@fishpool.com       |  - - --+
             |-- Fishpool Creations Ltd - /         |
             +-------- = - - - = ---------      /~setok/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I notice that there is no convenient way to write (and read) function
pointer values in C (nor C++).

My first thought was to simply cast the function pointer to 'void*'
and then use printf("%p"), but this isn't guaranteed to work on all
systems (because function pointers and data pointers might have
different representations and even different sizes).  The standard,
in fact, makes no guarantees about converting a function pointer
into anything other than another function pointer.

My next idea was the usual union hack, to wit, something like this:

    typedef void    (*fp_t)();             // Func ptr

    union FPtrHack
    {
        void            (*fp)();           // Func ptr
        unsigned char   b[sizeof(fp_t)];   // Bytes
    };

    void printFuncPtr(void (*fp)())
    {
        union FPtrHack   u;
        int              i;

        u.fp = fp;
        for (i = 0;  i < sizeof(u.fp);  i++)
            printf("%02X", u.b[i]);
    }

Reading a function pointer value back in from a file would be done
in a similar fashion.

But this is a pain, I have the nagging feeling that this is inviting
undefined behavior.

So, I ask, could we add a printf/scanf format specifier for function
pointers?  Something similar to %p, perhaps %jp?

    void   (*fp)();
    ...
    printf("%jp", (void (*)())fp);

We would probably have to mandate that the pointer value must be
cast to 'void (*)()' to be completely portable/reliable.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]