Need clarification on a function declaration

wizwx

what does the following mean?
int func2();

According to C++, it surely means func2 is a function that takes no
argument and returns an integer. But what about in C? Does it have the
same meaning or does it mean that func2 is a function that takes any
number of arguments and returns an integer?

Thanks for any clarification.

Feb 11 '07 #1

Ben Pfaff

"wizwx" <wi****@gmail.comwrites:

int func2();

According to C++, it surely means func2 is a function that takes no
argument and returns an integer. But what about in C? Does it have the
same meaning or does it mean that func2 is a function that takes any
number of arguments and returns an integer?

The latter is roughly true, with some limitations. For example,
the function cannot take a variable number of arguments and it
cannot have parameters of type "short" or "float" or other narrow
types.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Feb 11 '07 #2

wizwx

On Feb 11, 6:00 pm, Ben Pfaff <b...@cs.stanford.eduwrote:

"wizwx" <wiz...@gmail.comwrites:

int func2();

According to C++, it surely means func2 is a function that takes no
argument and returns an integer. But what about in C? Does it have the
same meaning or does it mean that func2 is a function that takes any
number of arguments and returns an integer?

The latter is roughly true, with some limitations. For example,
the function cannot take a variable number of arguments and it
cannot have parameters of type "short" or "float" or other narrow
types.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

Will you please clarify what is a narrow type and what is not? Is long
a narrow type?

Feb 11 '07 #3

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=

wizwx wrote:

On Feb 11, 6:00 pm, Ben Pfaff <b...@cs.stanford.eduwrote:

"wizwx" <wiz...@gmail.comwrites:

int func2();

According to C++, it surely means func2 is a function that takes no
argument and returns an integer. But what about in C? Does it have the
same meaning or does it mean that func2 is a function that takes any
number of arguments and returns an integer?

The latter is roughly true, with some limitations. For example,
the function cannot take a variable number of arguments and it
cannot have parameters of type "short" or "float" or other narrow
types.

Will you please clarify what is a narrow type and what is not? Is long
a narrow type?

The integer types smaller than (signed or unsigned) int, and float,
count as narrow types here. Integer types exactly as large as (signed
or unsigned) int may or may not, depending on the implementation. And
all other types don't.

Feb 12 '07 #4

Malcolm McLean

"wizwx" <wi****@gmail.comwrote in message

what does the following mean?
int func2();

According to C++, it surely means func2 is a function that takes no
argument and returns an integer. But what about in C? Does it have the
same meaning or does it mean that func2 is a function that takes any
number of arguments and returns an integer?

Thanks for any clarification.

New C code should always have function prototypes. The return values of the
function and the arguments it takes should be specified expicitly.

However to avoid breaking old code, it is permitted to evade the system by
declaring a function with an empty, as opposed to void, parameter list. In
C++ this is not allowed.
If you've got to deal with code that uses empty parameter lists you are very
unfortunate. Almost certainly you can just ignore the whole issue.
Occasionally a sloppy programmer will write

func2();

when he means

int func2(void);

The difference is that if you call the first version with parameters, the
compiler won't flag an error.

Feb 12 '07 #5

Keith Thompson

"Harald van Dijk" <tr*****@gmail.comwrites:

wizwx wrote:

[...]

>Will you please clarify what is a narrow type and what is not? Is long
a narrow type?

The integer types smaller than (signed or unsigned) int, and float,
count as narrow types here. Integer types exactly as large as (signed
or unsigned) int may or may not, depending on the implementation. And
all other types don't.

Specifically, char, signed char, unsigned char, short, and unsigned
short, and float are all narrow types. It's possible, for example,
for short and int to be the same width, but short is still a narrow
type even if so.

I don't think the standard uses the term "narrow type"; what's being
referred to is types that are affected by argument promotions.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Feb 12 '07 #6

=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=

Keith Thompson wrote:

"Harald van Dijk" <tr*****@gmail.comwrites:

wizwx wrote:

[...]

Will you please clarify what is a narrow type and what is not? Is long
a narrow type?

The integer types smaller than (signed or unsigned) int, and float,
count as narrow types here. Integer types exactly as large as (signed
or unsigned) int may or may not, depending on the implementation. And
all other types don't.

Specifically, char, signed char, unsigned char, short, and unsigned
short, and float are all narrow types.

As well as bool, and possibly extended integer types, which may be
made available via standard typedefs. For example, UINT_MAX ==
0x7FFFFFFF, and SIZE_MAX is 0xFFFF, then size_t must be a narrow type,
even if it is not a typedef for unsigned short (or char or unsigned
char). If UINT_MAX == 0xFFFF, and SIZE_MAX is too, then size_t may or
may not be a narrow type.

It's possible, for example,
for short and int to be the same width, but short is still a narrow
type even if so.

Thanks, I should've mentioned that.

I don't think the standard uses the term "narrow type"; what's being
referred to is types that are affected by argument promotions.

It indeed doesn't use that term. It talks about integer types with a
lower conversion rank than int, and adds float as a special case.

Feb 12 '07 #7

David T. Ashley

"wizwx" <wi****@gmail.comwrote in message
news:11*********************@v45g2000cwv.googlegro ups.com...

>
Will you please clarify what is a narrow type and what is not? Is long
a narrow type?

In the old days, when men were men individual responsibility was a cherished
value, a good programmer could manage function parameters himself and
wouldn't rely on the compiler to spot errors.

int func();

meant that anything could be passed so long as one understood that the
compiler was going to promote all "narrow" types (char becomes int, float
becomes double, etc.). By "narrow" type, the original poster meant "a type
that is promoted to something else when put in the argument list".

However, as programmer skill declined and new standards emerged, it was
decided that:

int func(void);

would mean no parameters.

I don't believe in function prototypes or compiler warnings. They slow down
the compiler. I've calculated that a programmer who uses function
prototypes and compiler warnings may lose, over a lifetime of programming,
as much as 5 seconds due to the compiler processing the prototypes and
issuing the warnings.

However, if you want to do the stylish thing and use them, you should never
leave an argument list empty ...

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

Feb 12 '07 #8

CBFalconer

"David T. Ashley" wrote:

>

.... snip ...

>
I don't believe in function prototypes or compiler warnings. They
slow down the compiler. I've calculated that a programmer who
uses function prototypes and compiler warnings may lose, over a
lifetime of programming, as much as 5 seconds due to the compiler
processing the prototypes and issuing the warnings.

I was about to contradict you. Then I read the 3rd sentence.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

Feb 12 '07 #9

David T. Ashley

"CBFalconer" <cb********@yahoo.comwrote in message
news:45***************@yahoo.com...

"David T. Ashley" wrote:

>>

... snip ...

>>
I don't believe in function prototypes or compiler warnings. They
slow down the compiler. I've calculated that a programmer who
uses function prototypes and compiler warnings may lose, over a
lifetime of programming, as much as 5 seconds due to the compiler
processing the prototypes and issuing the warnings.

I was about to contradict you. Then I read the 3rd sentence.

Well, the losses cited above are just the "first-tier" losses. There is
also:

a)Lost time typing the function prototypes into a text editor.

b)Lost time printing the function prototypes (as well as toner and paper).

c)Extra disk space consumed in version control systems.

d)Etc.

Function prototypes are really a dangerous practice.

I'm actually writing a new book about needless caution and worthless safety
devices. Other things I don't believe in:

a)Condoms.

b)Automobile safety belts and airbags.

c)Swimming pool lifeguards.

d)Safety rails on balconies and so forth.

e)Insurance.

It really is a slippery slope. Once you start believing that you might make
a mistake or that something unforeseen might occur, you just spend lots of
unnecessary money. The economic losses from this type of defective thinking
are staggering. A typical consumer is probably paying $2,000 more per car
for this kind of silliness.

--
David T. Ashley (dt*@e3ft.com)
http://www.e3ft.com (Consulting Home Page)
http://www.dtashley.com (Personal Home Page)
http://gpl.e3ft.com (GPL Publications and Projects)

Feb 13 '07 #10