printf prototype UB

[Mantorok Redgormor]

Would this by any chance invoke undefined behavior?

extern int printf(const char *, ...); int main(void) {
printf("Hello\n"); return 0; }

That is, providing my own printf prototype would invoke undefined
behavior in anyway? Assuming the implementation is c89 of course.

 

[Joona I Palaste]

Would this by any chance invoke undefined behavior?

extern int printf(const char *, ...); int main(void) {
printf("Hello\n"); return 0; }

That is, providing my own printf prototype would invoke undefined
behavior in anyway? Assuming the implementation is c89 of course.

No, I don't think it will invoke undefined behaviour. If the prototype
has the correct form, the compiler won't care who supplied it, you or
the preprocessor.

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bee could, in effect, gather its junk. Llamas (no poor quadripeds) tune
and vow excitedly zooming."
- JIPsoft

 

[Dan Pop]

Would this by any chance invoke undefined behavior?

extern int printf(const char *, ...); int main(void) {
printf("Hello\n"); return 0; }

That is, providing my own printf prototype would invoke undefined
behavior in anyway? Assuming the implementation is c89 of course.

As long as your declaration is compatible with the function interface
specified by the relevant standard, everything is OK.

The main argument against doing it is that many functions have different
interfaces in the two C standards. This doesn't affect correct code that
uses the implementation-provided declaration, but it is theoretically
problematic to code providing its own declarations (even if you try to
accomodate both C89 and C99, who knows what's going to happen if C0x
ever gets released and implemented?).

Dan

 

[Christopher Benson-Manica]

No, I don't think it will invoke undefined behaviour. If the prototype
has the correct form, the compiler won't care who supplied it, you or
the preprocessor.

Under what circumstances would supplying the prototype yourself be advisable?

 

[Mike Wahler]

Under what circumstances would supplying the prototype yourself be

advisable?

None, as far as I'm concerned.

IMO it's easier to type

#include <stdio.h>

and get it right the first time.

If you foul up the 'hand made' declaration, it
might not become evident until your program
behaves in a bizarre fashion.

-Mike

 

[Jack Klein]

Would this by any chance invoke undefined behavior?

extern int printf(const char *, ...); int main(void) {
printf("Hello\n"); return 0; }

That is, providing my own printf prototype would invoke undefined
behavior in anyway? Assuming the implementation is c89 of course.

From ANSI89/ISO90 standard:

"Provided that a library function can, be declared without reference
to any type defined in a header, it is also permissible to declare the
function, either explicitly or implicitly, and use it without
including its associated header. If a function that accepts a variable
number of arguments is not declared (explicitly or by including its
associated header), the behavior is undefined."

So as long as the prototype is correct, it is perfectly well defined.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Irrwahn Grausewitz]

Under what circumstances would supplying the prototype yourself be advisable?

Under no circumstances I can think of. Furthermore supplying only the
prototype of printf might not be sufficient to make things work (think
about stdout).

Regards

Irrwahn

 

[Dave Vandervies]

Under no circumstances I can think of.

If for some reason you want to be able to put an entire program on
one line (f'rexample, wanting a program to print its own source code
without having embedded backslashes to worry about escaping in the
output, as was discussed here not long ago), you'd need some way to
avoid preprocessor directives.

Whether or not this is a good reason is subject to debate. I can't
think of any other reasons that could claim to be good ones.

Furthermore supplying only the
prototype of printf might not be sufficient to make things work (think
about stdout).

The code that calls printf need not know anything about stdout; the
implementation of printf (in the runtime library) needs to know where to
put its output, but as long as the calling code calls it correctly (which
in the case of printf means having a correct prototype in scope[1][2]
and matching the arguments to the format string), the implementation is
required to make it work with no further requirements on the calling code.


dave

[1] This is best done by using "#include <stdio.h>" (you'll get no
argument about the "best" here), but "int printf(const char *,...);"
(in C89) is also perfectly valid.

[2] The requirement to have a prototype in scope is a result of printf
being a variadic function. In general, you can call a non-variadic
function whose arguments aren't subject to promotion without a
prototype[3], though there's no excuse for actually doing so.

[3] Question for the language lawyers: Is this legal? (There's no
argument that it's Evil, but that's not the same question.)
/*Not a prototype, but makes sure we have the correct return type*/
void *malloc();
/*size_t is assumed to not be subject to the usual promotions.
(Is this guaranteed?)
Note that we use sizeof to get a size_t without actually having
the implementation's definition in scope.
*/
struct foo *foo_ptr=malloc(sizeof *foo);

--
Dave Vandervies (e-mail address removed)

How neat do I have to be with my garbage?

That depends. How much do you want your programs to smell?
--Al Morgan and Richard Heathfield in comp.lang.c

 

[Mike Wahler]

advisable?

Under no circumstances I can think of. Furthermore supplying only the
prototype of printf might not be sufficient to make things work (think
about stdout).

I'm not supporting the 'handmade' prototypes for lib
functions, but your 'reason' above isn't valid, since
there's no need to refer to 'stdout' when invoking
'printf()' (Unless of course you're wanting to print
its value).

-Mike

 

[Irrwahn Grausewitz]

I'm not supporting the 'handmade' prototypes for lib
functions, but your 'reason' above isn't valid, since
there's no need to refer to 'stdout' when invoking
'printf()' (Unless of course you're wanting to print
its value).

Hm, right, thanks to you and Dave for pointing out.

Irrwahn

 

[Irrwahn Grausewitz]

If for some reason you want to be able to put an entire program on
one line (f'rexample, wanting a program to print its own source code
without having embedded backslashes to worry about escaping in the
output, as was discussed here not long ago), you'd need some way to
avoid preprocessor directives.

Whether or not this is a good reason is subject to debate.

Indeed...

 

[Mark McIntyre]

Under what circumstances would supplying the prototype yourself be advisable?

when you need the function prototype, but want to avoid including the
header due to side-effects of other prototypes, declarations or
definitions.

For example you have to maintain badly written legacy code that
#defines NULL to be something other than 0 or (void*)0, and fixing the
real bug is not an option.

 

[Eric Sosman]

when you need the function prototype, but want to avoid including the
header due to side-effects of other prototypes, declarations or
definitions.

For example you have to maintain badly written legacy code that
#defines NULL to be something other than 0 or (void*)0, and fixing the
real bug is not an option.

If you're writing (or tempted to write) the prototype
yourself, it's clear you already have license to modify the
freaky code. True, this doesn't necessarily imply that you
have license to fix all its problems, but some amount of
change is clearly in the wind.

Another point of view is to consider the language in which
this screwball code is written: should that language be called
"C" or something else? It seems to me that defining NULL as
(char*)42 or using it as a function name or any such similar
abuse is reason to doubt the "C-ness" of the code. (And to
doubt the sanity of the coder, too.)

#define void int
void main(void argc, char **argv) {
return !puts("Hello, world!");
}

.... is at best "Sort-Of-C," not "C."

 

[Mark McIntyre]

If you're writing (or tempted to write) the prototype
yourself, it's clear you already have license to modify the
freaky code. True, this doesn't necessarily imply that you
have license to fix all its problems, but some amount of
change is clearly in the wind.

I think you missed my point. I'm not rewriting the dodgy legacy code
here. I'm maintaining something that uses it. I can't change that
header because its used by a zillion other house projects. So I'm
stuck with the fact that its header declares functions strtod() and
frexp(), macros __LINE__ etc.

Another point of view is to consider the language in which
this screwball code is written: should that language be called
"C" or something else?

I like to call it "a bl**dy mess"

 

[Dan Pop]

#define void int
void main(void argc, char **argv) {
return !puts("Hello, world!");
}

... is at best "Sort-Of-C," not "C."

Well, it happens to be a strictly conforming C program That is,
if we assume that the definition of a s.c. program allows its existence...

Oddly enough, the standard allows replacing the C keywords by macros
if no header is included while the replacement is still in effect.

Dan