Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > casting

Reply
Thread Tools

casting

 
 
Rouben Rostamian
Guest
Posts: n/a
 
      10-31-2003
I am reading the last chapter in Kernighan and Pike's
"The Unix Programming Environment" where they describe their
program "hoc" which, in effect, is a multifunction programmable
calculator.

In the heart of hoc is an array, named prog[], that hold the
calculator's instructions. It is defined as follows (I have taken
the liberty to strip down to essentials):

typedef struct Symbol {
double val;
struct Symbol *fp;
} Symbol;

typedef void (*Inst)(void);

Inst prog[100];

void add(void)
{
... details snipped, but note that `add' is off type Inst ...
}

Then:

int main(void)
{
Symbol *s;
Inst *pc = prog;

s = ... allocate memory and define s ...;

*pc++ = add;
*pc++ = (Inst)s;

...

}

My question is regarding the (Inst) cast in the last line shown in main().

To what extent is it legal to cast s, which a pointer to Symbol,
to type Inst, which is a pointer to a function. Is it safe to assume
than any pointer type can be cast into any other pointer type?

--
Rouben Rostamian <(E-Mail Removed)>
 
Reply With Quote
 
 
 
 
Christian Bau
Guest
Posts: n/a
 
      10-31-2003
In article <bnscef$3tu$(E-Mail Removed)>,
http://www.velocityreviews.com/forums/(E-Mail Removed) (Rouben Rostamian) wrote:

> To what extent is it legal to cast s, which a pointer to Symbol,
> to type Inst, which is a pointer to a function. Is it safe to assume
> than any pointer type can be cast into any other pointer type?


Its very unsafe indeed. There have been C implementations where void*
was 32 bit, and a pointer to a function was 16 bits. If you cast the a
data pointer to a function pointer and back on such an implementation,
you will most likely not get the correct result.
 
Reply With Quote
 
 
 
 
Artie Gold
Guest
Posts: n/a
 
      10-31-2003
Christian Bau wrote:
> In article <bnscef$3tu$(E-Mail Removed)>,
> (E-Mail Removed) (Rouben Rostamian) wrote:
>
>
>>To what extent is it legal to cast s, which a pointer to Symbol,
>>to type Inst, which is a pointer to a function. Is it safe to assume
>>than any pointer type can be cast into any other pointer type?

>
>
> Its very unsafe indeed. There have been C implementations where void*
> was 32 bit, and a pointer to a function was 16 bits. If you cast the a
> data pointer to a function pointer and back on such an implementation,
> you will most likely not get the correct result.


Note, however, that `The Unix Programming Environment" was published
in 1984, predating the ANSI/ISO standard by five and six years
respectively.

But, yes, in either C89/90 or C99 this invokes (the dreaded)
undefined behavior.

HTH,
--ag

--
Artie Gold -- Austin, Texas
Oh, for the good old days of regular old SPAM.

 
Reply With Quote
 
Peter Pichler
Guest
Posts: n/a
 
      10-31-2003
"Rouben Rostamian" <(E-Mail Removed)> wrote in message
news:bnscef$3tu$(E-Mail Removed)...
> (I have taken the liberty to strip down to essentials):


So have I

> typedef struct Symbol {
> double val;
> struct Symbol *fp;
> } Symbol;
>
> typedef void (*Inst)(void);
>
> Inst prog[100];

....
> int main(void)
> {
> Symbol *s;
> Inst *pc = prog;
>
> s = ... allocate memory and define s ...;

....
> *pc++ = (Inst)s;

....
> }
>
> My question is regarding the (Inst) cast in the last line shown in main().
>
> To what extent is it legal to cast s, which a pointer to Symbol,
> to type Inst, which is a pointer to a function. Is it safe to assume
> than any pointer type can be cast into any other pointer type?


No, it isn't. You can't even portably allocate a space for a function.
They can be completely separate memory areas, for example. (And by that
I do not only mean different segments, but fizycally diferent hardware
for code and data memory. Such architectures do exist, e.g. the 8051
processor family.)

The example above might be good enough in the given context (Unix
programming), but in general it is a bad idea.


 
Reply With Quote
 
Randy Howard
Guest
Posts: n/a
 
      10-31-2003
In article <IRiob.1145$(E-Mail Removed)>, pichlo6
@pobox.sk says...
> fizycally diferent hardware


I've some intentional typos, and some unintentional typos, but you
have *got* to be kidding.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: (E-Mail Removed)
 
Reply With Quote
 
August Derleth
Guest
Posts: n/a
 
      10-31-2003
Randy Howard <(E-Mail Removed)> wrote in message news:<(E-Mail Removed). net>...
> In article <IRiob.1145$(E-Mail Removed)>, pichlo6
> @pobox.sk says...
> > fizycally diferent hardware

>
> I've some intentional typos, and some unintentional typos, but you
> have *got* to be kidding.


Maybe he's one of those people trying to rectify the orthography of
the English language.

Like Noah Webster and Thomas Jefferson and a few other unknown
crazies, you know?

Or, hell, maybe he's an alien who's pieced together a knowledge of
English from cereal box tops and Ovaltine lids.

Or maybe he's getting messages from his neighbor's dogs. Frightening,
hilarious messages. Messages about typing with his left foot and
tongue.
 
Reply With Quote
 
Peter Pichler
Guest
Posts: n/a
 
      10-31-2003
"Randy Howard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) et...
> In article <IRiob.1145$(E-Mail Removed)>, pichlo6
> @pobox.sk says...
> > fizycally diferent hardware

>
> I've some intentional typos, and some unintentional typos, but you
> have *got* to be kidding.


Sadly, no. My only excuse is that it was after 1 am when I wrote that


 
Reply With Quote
 
nrk
Guest
Posts: n/a
 
      10-31-2003
Artie Gold wrote:

> Christian Bau wrote:
>> In article <bnscef$3tu$(E-Mail Removed)>,
>> (E-Mail Removed) (Rouben Rostamian) wrote:
>>
>>
>>>To what extent is it legal to cast s, which a pointer to Symbol,
>>>to type Inst, which is a pointer to a function. Is it safe to assume
>>>than any pointer type can be cast into any other pointer type?

>>
>>
>> Its very unsafe indeed. There have been C implementations where void*
>> was 32 bit, and a pointer to a function was 16 bits. If you cast the a
>> data pointer to a function pointer and back on such an implementation,
>> you will most likely not get the correct result.

>
> Note, however, that `The Unix Programming Environment" was published
> in 1984, predating the ANSI/ISO standard by five and six years
> respectively.
>
> But, yes, in either C89/90 or C99 this invokes (the dreaded)
> undefined behavior.
>


I agree with the undefined behavior part... but FWIW, short of coming up
with your own virtual machine, instruction set and execution semantics,
this is the quick and easy cop-out to code-generation and execution on the
fly. Another example of this trick can be found in "The Practice of
Programming" by Kernighan and Pike, where they cast an array of int to
(void(*)(void)) [and note that this was published distinctly after ANSI/ISO
standards ].

-nrk.
 
Reply With Quote
 
Mantorok Redgormor
Guest
Posts: n/a
 
      10-31-2003
Christian Bau <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> In article <bnscef$3tu$(E-Mail Removed)>,
> (E-Mail Removed) (Rouben Rostamian) wrote:
>
> > To what extent is it legal to cast s, which a pointer to Symbol,
> > to type Inst, which is a pointer to a function. Is it safe to assume
> > than any pointer type can be cast into any other pointer type?

>
> Its very unsafe indeed. There have been C implementations where void*
> was 32 bit, and a pointer to a function was 16 bits. If you cast the a
> data pointer to a function pointer and back on such an implementation,
> you will most likely not get the correct result.


Does it say in the standard how wide a pointer to function can be?

- nethlek
 
Reply With Quote
 
Peter Pichler
Guest
Posts: n/a
 
      10-31-2003
"Mantorok Redgormor" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) om...
>
> Does it say in the standard how wide a pointer to function can be?


It doesn't say how wide _any_ pointer can be. Remember, pointers are not
numbers, so it makes no sense talking about them in terms of "width",
"range" or "precision". That most platforms implement them in the same
way has no relevance whatsoever.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Up casting and down casting Sosuke C++ 2 12-20-2009 03:24 PM
Problem with depracated casting method (down casting) Wally Barnes C++ 3 11-20-2008 05:33 AM
type casting vs. type converting Toby VHDL 3 09-07-2005 01:42 PM
Another question about inheritance (up-casting and down-casting) kevin Java 11 01-08-2005 07:11 PM
'STD_LOGIC_VECTOR ' to 'unsigned' type casting Ben Nguyen VHDL 6 09-20-2003 05:09 PM



Advertisments