casting

[Rouben Rostamian]

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?

 

[Christian Bau]

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.

 

[Artie Gold]

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

 

[Peter Pichler]

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

 

[Randy Howard]

fizycally diferent hardware

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

 

[August Derleth]

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.

 

[Peter Pichler]

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 :-(

 

[nrk]

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.

 

[Mantorok Redgormor]

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

 

[Peter Pichler]

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.

 

[Dan Pop]

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.

Or, more likely, he's not a native English language speaker and his
spelling is influenced by his native language (especially when he's
concentrating more on the contents than on the form).

Last time I checked, making fun of such issues was considered very poor
taste and an actual violation of the netiquette rules.

Dan

 

[Dan Pop]

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

Nope. For all the standard cares, a pointer to function may require more
memory than available on the target platform.

All the standard implicitly says is that void and character pointers must
be able to contain at least as much information as any other data pointer
type.

The standard treats function pointers and data pointers as two completely
different categories, that have almost nothing in common. Think about
a Harvard architecture where the data address space and the code
address space have different sizes. The most common one being the medium
model of many MSDOS C implementations (16-bit address space for data,
20-bit address space for code). Any chance to squeeze 20 bits into 16
bits? ;-)

Dan

 

[Peter Pichler]

In <[email protected]>

Or, more likely, he's not a native English language speaker and his
spelling is influenced by his native language (especially when he's
concentrating more on the contents than on the form).

....at 1:30 am after a night spent in a pub trying to combine playing
chess with drinking beer. Quite successfully, I must say. Especially the
latter.

Last time I checked, making fun of such issues was considered very poor
taste and an actual violation of the netiquette rules.

Actually, I found it quite funny. Especially the one about learning
English from cereal box tops. It reminds me how I learnt C, to bring this
back on topic ;-)

 

[nobody]

...at 1:30 am after a night spent in a pub trying to combine playing
chess with drinking beer. Quite successfully, I must say. Especially the
latter.


Actually, I found it quite funny. Especially the one about learning
English from cereal box tops. It reminds me how I learnt C, to bring this
back on topic ;-)

What I've found even more funny (and realizing it only after Dan's post,
1st time I took it for what it was, as Dan had already explained), that
you've mispelled it (root of the word) even in your mother's language.
It should be "fyzically"

 

[CBFalconer]

.... snip ...
What I've found even more funny (and realizing it only after Dan's
post, 1st time I took it for what it was, as Dan had already
explained), that you've mispelled it (root of the word) even in
your mother's language. It should be "fyzically"

Try "ghoti". Look it up. There is a connection with G.B. Shaw.

 

[Lew Pitcher]

nobody wrote:

... snip ...



Try "ghoti". Look it up. There is a connection with G.B. Shaw.

I love fish.


--

Lew Pitcher, IT Consultant, Application Architecture
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)

 

[Default User]

Try "ghoti". Look it up. There is a connection with G.B. Shaw.

This is a kind of a dumb strawman. Although some are odd or quirky,
English does have rules. To make "fish" out of the above, you have to
violate several of those rules.

Yes, "gh" can produce an "f" sound, but only in an -ough suffix. There
are no examples that produce that sound from the letters solely paired
that I'm aware of. Similarly "ti" only makes an "sh" in certain
combinations, notably the -tion suffix. Not alone.

The only one that reasonable is the "o", and that's only by it serving
as a schwa.



Brian Rodenborn

 

[Barry Schwarz]

This is a kind of a dumb strawman. Although some are odd or quirky,
English does have rules. To make "fish" out of the above, you have to
violate several of those rules.

Yes, "gh" can produce an "f" sound, but only in an -ough suffix. There

I guess you never laugh.



<<Remove the del for email>>

 

[Dan Pop]

This is a kind of a dumb strawman. Although some are odd or quirky,
English does have rules.

But they have so many exceptions that you simply cannot rely on them.
How do you pronounce "read" according to the rules? How about "bass"?

A language where the same written word gets pronounced in a context
dependent way is simply insane. Especially from the non-native speaker's
point of view ;-)

Dan

 

[CBFalconer]

But they have so many exceptions that you simply cannot rely on
them. How do you pronounce "read" according to the rules? How
about "bass"?

A language where the same written word gets pronounced in a
context dependent way is simply insane. Especially from the
non-native speaker's point of view ;-)

That is why Esperanto was invented, somewhere around a century
ago. It does not seem to have fared as well as English as a
universal medium. IIRC Latin also has many fewer irregularities
than does English, yet it too seems to have fallen into disfavor
as the universal language.