Is this program standard conform?

F

Fumeur

Is the following program standard conform?
(reduced as much as possible so it still shows the problem)

/* begin */
#include <stdio.h>

void xfprintf(FILE *);

void xfprintf(FILE *f) {
fprintf(f, "x\n");
}

int main(void) {
xfprintf(stderr);
return 0;
}
/* end */


It compiles with gcc without warnings and works correctly, but trying
to compile it with a particular other popular compiler, it yields the
following diagnostics:

lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Who is at fault here, my program or the compiler?
 
V

vippstar

Is the following program standard conform?
(reduced as much as possible so it still shows the problem)

/* begin */
#include <stdio.h>

void xfprintf(FILE *);

void xfprintf(FILE *f) {
fprintf(f, "x\n");

}

int main(void) {
xfprintf(stderr);
return 0;}

/* end */

It compiles with gcc without warnings and works correctly, but trying
to compile it with a particular other popular compiler, it yields the
following diagnostics:

lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Who is at fault here, my program or the compiler?

int foo(void); is a declaration while int foo(void) { return 42; } is
a definition.
Apparently, xfprintf() is defined twice.
Your snippet is valid ISO C.
 
R

Richard Tobin

lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here

Please don't feed the anonymous troll.

-- Richard
 
R

Richard Bos

Fumeur said:
lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Either you're not calling your implementation correctly, or (in this
case, _highly_ more likely), it is broken. No ISO C implementation is
allowed to declare an identifier called xfprintf in its Standard headers
(which include <stdio.h>); it is in your namespace, not its, and it is
not an existing Standard C function.

Richard
 
J

jacob navia

Fumeur said:
Is the following program standard conform?
(reduced as much as possible so it still shows the problem)

/* begin */
#include <stdio.h>

void xfprintf(FILE *);

void xfprintf(FILE *f) {
fprintf(f, "x\n");
}

int main(void) {
xfprintf(stderr);
return 0;
}
/* end */


It compiles with gcc without warnings and works correctly, but trying
to compile it with a particular other popular compiler, it yields the
following diagnostics:

lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Who is at fault here, my program or the compiler?

You are using a bad bad compiler. This is unacceptable!

I would ask

1) For a full refund of the money you spent.

*After* you get the money :)

2) Ask Ossama bin laden to kill that infidel to the principles
and spirit of C.
 
F

Fumeur

Fumeur said:
lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Either you're not calling your implementation correctly, or (in this
case, _highly_ more likely), it is broken. No ISO C implementation is
allowed to declare an identifier called xfprintf in its Standard headers
(which include <stdio.h>); it is in your namespace, not its, and it is
not an existing Standard C function.

Thanks, that's what I thought. I had a look at the standard myself and
didn't find any reference to xfprintf(), but that was only C99 and not
any previous versions.

In the compiler/implementation's defense, it does not really "define"
said function at the indicated location, even though the diagnostic may
be misleading; line 116 in its <stdio.h> actually reads

int xfprintf(FILE *,const char *,...);


Would that warrant a bug report (rejects a conforming program)?
 
R

Richard Bos

Fumeur said:
Fumeur said:
lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Either you're not calling your implementation correctly, or (in this
case, _highly_ more likely), it is broken. No ISO C implementation is
allowed to declare an identifier called xfprintf in its Standard headers
(which include <stdio.h>); it is in your namespace, not its, and it is
not an existing Standard C function.

Thanks, that's what I thought. I had a look at the standard myself and
didn't find any reference to xfprintf(), but that was only C99 and not
any previous versions.

In the compiler/implementation's defense, it does not really "define"
said function at the indicated location,

It doesn't need to. It is not even allowed to declare it.
even though the diagnostic may
be misleading; line 116 in its <stdio.h> actually reads

int xfprintf(FILE *,const char *,...);

Would that warrant a bug report (rejects a conforming program)?

If you think it'll help. But yes, it's certainly a bug.

Richard
 
M

Malcolm McLean

Fumeur said:
Is the following program standard conform?
(reduced as much as possible so it still shows the problem)

/* begin */
#include <stdio.h>

void xfprintf(FILE *);

void xfprintf(FILE *f) {
fprintf(f, "x\n");
}

int main(void) {
xfprintf(stderr);
return 0;
}
/* end */


It compiles with gcc without warnings and works correctly, but trying
to compile it with a particular other popular compiler, it yields the
following diagnostics:

lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Who is at fault here, my program or the compiler?
Compiler. The programs as it stands is valid and should be accepted. Try
passing strict_ansi or a similar flag to the one that chokes on it.
 
K

Keith Thompson

Fumeur said:
Fumeur said:
lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Either you're not calling your implementation correctly, or (in this
case, _highly_ more likely), it is broken. No ISO C implementation is
allowed to declare an identifier called xfprintf in its Standard headers
(which include <stdio.h>); it is in your namespace, not its, and it is
not an existing Standard C function.

Thanks, that's what I thought. I had a look at the standard myself and
didn't find any reference to xfprintf(), but that was only C99 and not
any previous versions.

No library functions have been dropped since the first C standard of
1989/1990. (gets() has finally been deprecated, but it hasn't been
removed.)
In the compiler/implementation's defense, it does not really "define"
said function at the indicated location, even though the diagnostic may
be misleading; line 116 in its <stdio.h> actually reads

int xfprintf(FILE *,const char *,...);

Would that warrant a bug report (rejects a conforming program)?

If that declaration is visible in what the implementation claims to be
conforming mode, then yes, that's a bug. The implementation *must*
allow you to declare your own xfprintf function.

It's legal for an implementation to declare additional functions in
standard headers *if* they're only enabled in a non-conforming mode
(for example, via a command-line option that sets or clears some
preprocessor macro, or that controls which copy of <stdio.h> to use).
But IMHO it's a bad idea; implementation-defined functions should be
declared in implementation-defined headers, just for the sake of
clarity.
 
K

Keith Thompson

jacob navia said:
Fumeur said:
Is the following program standard conform?
(reduced as much as possible so it still shows the problem)

/* begin */
#include <stdio.h>

void xfprintf(FILE *);

void xfprintf(FILE *f) {
fprintf(f, "x\n");
}

int main(void) {
xfprintf(stderr);
return 0;
}
/* end */


It compiles with gcc without warnings and works correctly, but trying
to compile it with a particular other popular compiler, it yields the
following diagnostics:

lc -ansic -A -shadows -unused -O -c xfprintf.c -o xfprintf.obj
Error xfprintf.c: 4 redefinition of 'xfprintf'
Error c:\lcc\include\stdio.h: 116 Previous definition of 'xfprintf' here
2 errors, 0 warnings
1 error
make: *** [xfprintf.obj] Error 1

Who is at fault here, my program or the compiler?

You are using a bad bad compiler. This is unacceptable!

I would ask

1) For a full refund of the money you spent.

*After* you get the money :)

2) Ask Ossama bin laden to kill that infidel to the principles
and spirit of C.

jacob, this is how you respond to bug reports? Get over yourself.
Not everything posted here is a personal attack on you.

One of your users (I presume Fumeur is using lcc-win) wanted to
declare his own function called "xfprintf". A conforming
implementation *must* allow him to do so. Your compiler didn't,
because you've apparently declared your own "xfprintf" function in a
standard header, infringing on the user's namespace. It appears from
the other responses in this thread that Fumeur ran into this by
accident. And when he came here to ask whether the fault is in his
program or in the compiler, you responded with the above-quoted crap.

Does the fact that your compiler is distributed free of charge mean
that users can have no expectation of quality?

If you wanted to be taken seriously, you would (a) publicly apologize
to Fumeur, (b) fix this bug in your implementation, and (c) search
your implementation for similar bugs, and fix them as well.

Just recently we've seen three examples of lcc-win features that
violate the standard: your "%b" format for printf, your min and max
macros, and now your xfprintf function. I suggest that these are a
symptom of a deeper problem.

For each non-standard function you provide (xfprintf, min, max), you
should make sure either that it's declared in an
implementation-defined header or that its declaration is disabled in
conforming mode. Make sure that every extension you provide (that is
enabled in conforming mode) cannot affect the behavior of any strictly
conforming program.

It's up to you.
 
A

Army1987

Keith said:
Just recently we've seen three examples of lcc-win features that
violate the standard: your "%b" format for printf
Why?
7.19.6.1:
"9 If a conversion specification is invalid, the behavior is undefined."
 
J

jacob navia

Army1987 said:
Why?
7.19.6.1:
"9 If a conversion specification is invalid, the behavior is undefined."

Of course it is undefined but there people
that insist that lcc-win is the devil.

Yeah... I am a sinner...

I will go to C's heretics hell probably condemned to use gcc -v
for all eternity...
 
A

Antoninus Twink

Of course it is undefined but there people
that insist that lcc-win is the devil.

Yeah... I am a sinner...

I will go to C's heretics hell probably condemned to use gcc -v
for all eternity...

You have to remember that many of those people are pathetic bullies, and
attacking lcc-win is one of their few pleasures in life... Heathfield
has even doubled his fun by setting up sock puppets to make personal
attacks on Jacob.
 
P

Peter Nilsson

Lowercase conversion specifiers are reserved for future use
[cf 7.26.9.] If lcc-win used %B instead, it would be fine.

jacob navia said:
Of course it is undefined but there people
that insist that lcc-win is the devil.

The only person bringing religion into this is you. All
I see are people pointing out where your implementation
is not conforming.
Yeah... I am a sinner...

I will go to C's heretics hell probably condemned to use
gcc -v for all eternity...

Or you could fix the problems with lcc-win and give
programmers more reason to use it.
 
A

Army1987

Peter said:
Lowercase conversion specifiers are reserved for future use
[cf 7.26.9.] If lcc-win used %B instead, it would be fine.

So? I think it's not broken *yet*, since as of C99 + TC3 (i.e. n1256), a
program with printf("%b"); is allowed to do anything.
For example, glibc's printf() prints strerror(errno) with the %m specifier.

Yes, using capitals would lower the chances for it to be broken *in
future*, but as it stands, it is not one of the reasons why lcc-win32 is
broken.
 
A

Army1987

jacob said:
Of course it is undefined but there people
that insist that lcc-win is the devil.
That's a persecution complex. In case you didn't get it, I was indeed
saying that you *are* allowed to implement an extra functionality for the
%b specifier.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top