Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: how to understand this CPP syntax?

Reply
Thread Tools

Re: how to understand this CPP syntax?

 
 
Stefan Ram
Guest
Posts: n/a
 
      02-15-2010
Joey Wang <(E-Mail Removed)> writes in comp.lang.c.moderated:
>I have a problem understanding the following definitions in <signal.h>
>#define SIG_ERR (void (*) ())-1
>#define SIG_DFL (void (*) ())0
>#define SIG_IGN (void (*) ())1
>Are they the CPP's way of defining a function pointer (cuz SIG_ERR is
>a func ptr)?
>How to understand this syntax?
>Can anyone guide me through this?


The header files provided by an implementation are not
bounded by the limits of portable C code, but free to use
implementation-specified notations. A user of a
C implementations is not supposed to understand his
implementation's header files nor to modify them.

#define usually just does text substitutions.
The preprocessor usually is not aware of the structure of the
C language proper. But an implementation possibly might even
be free to change the meaning of #define for its own header
files or standard macro names (although I never heard of this).

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-15-2010
http://www.velocityreviews.com/forums/(E-Mail Removed)-berlin.de (Stefan Ram) writes:
> Joey Wang <(E-Mail Removed)> writes in comp.lang.c.moderated:
>>I have a problem understanding the following definitions in <signal.h>
>>#define SIG_ERR (void (*) ())-1
>>#define SIG_DFL (void (*) ())0
>>#define SIG_IGN (void (*) ())1
>>Are they the CPP's way of defining a function pointer (cuz SIG_ERR is
>>a func ptr)?
>>How to understand this syntax?
>>Can anyone guide me through this?

>
> The header files provided by an implementation are not
> bounded by the limits of portable C code, but free to use
> implementation-specified notations. A user of a
> C implementations is not supposed to understand his
> implementation's header files nor to modify them.
>
> #define usually just does text substitutions.
> The preprocessor usually is not aware of the structure of the
> C language proper. But an implementation possibly might even
> be free to change the meaning of #define for its own header
> files or standard macro names (although I never heard of this).


All true, but not entirely relevant to the question.

First of all, the OP omitted some parentheses. The actual definitions
are probably:

#define SIG_ERR ((void (*) ())-1)
#define SIG_DFL ((void (*) ())0)
#define SIG_IGN ((void (*) ())1)

Each definition is an integer constant expression converted,
via a cast, to a pointer-to-function type. The cast is to type
``void(*)()'', i.e., pointer to function returning void.

A modern implementation would probably define the
parameter type:

#define SIG_ERR ((void (*) (int))-1)
#define SIG_DFL ((void (*) (int))0)
#define SIG_IGN ((void (*) (int))1)

SIG_ERR, SIG_DFL, and SIG_IGN have to be function pointers, but
they merely have to be unique values; it needn't be possible to
call anything using their values. Converting a constant 0 to a
pointer-to-function type yields a null pointer, so SIG_DFL happens
to expand to an expression that evaluates to a null pointer value;
(SIG_DFL == NULL) is true. Converting any other integer value to
a pointer-to-function type yields some value that's not specified
by the standard (I'm not sure whether it's implementation-defined
or unspecified). The point is that, for the implementation for
which the above definitions were written, the three expressions
yield pointer values that are distinguishable from any pointer to
an actual function.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      02-15-2010
(E-Mail Removed)-berlin.de (Stefan Ram) writes:
> Joey Wang <(E-Mail Removed)> writes in comp.lang.c.moderated:
>>I have a problem understanding the following definitions in <signal.h>
>>#define SIG_ERR (void (*) ())-1
>>#define SIG_DFL (void (*) ())0
>>#define SIG_IGN (void (*) ())1

[snip]
>
> The header files provided by an implementation are not
> bounded by the limits of portable C code, but free to use
> implementation-specified notations.

[...]

Stefan, the original article was posted only to comp.lang.c.moderated.
Why did you post your followup only to comp.lang.c, and why didn't you
mention that you were changing newsgroups?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
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
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Free online test in C, CPP / Placement papers / CPP,C Interview Questions www.hitechskill.com C++ 0 04-09-2006 10:53 AM
when i compile the cpp file(cmdargs.cpp) int main(int argc, wchar_t* argv[]) Vinu C++ 9 05-05-2005 04:11 AM
Method inlined in source1.cpp and called in source2.cpp Alex Vinokur C++ 7 11-15-2004 09:14 PM
What is better /standard for creating files. a cpp file with header or cpp and seperate file for header DrUg13 C++ 1 02-10-2004 09:20 AM



Advertisments