Is this program standard conform?

[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?

[vippstar]

On Jan 21, 3:13 am, Fumeur <[e-mail]:

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.

[Richard Tobin]

In article <26****************@aioe.org>, Fumeur <[e-mail]:

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

[CBFalconer]

Richard Tobin wrote:

Fumeur <[e-mail]:

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

Why do you consider Fumeur to be a troll?

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Richard]

ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

In article <26****************@aioe.org>, Fumeur <[e-mail]:

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

But you can?

[Richard Bos]

Fumeur <[e-mail]:

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

[Kenny McCormack]

In article <3p************@news.individual.net>,
Richard <rg****@gmail.comwrote:

>ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:

>In article <26****************@aioe.org>, Fumeur <[e-mail]:

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

But you can?

Ssssh. You're using logic. Stop that. They don't like it.

[jacob navia]

Fumeur wrote:

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 navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Mark Bluemel]

jacob navia wrote:

I would ask

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

I've found a simpler approach. Jacob goes into the killfile.

[Fumeur]

On Mon, 21 Jan 2008 11:10:47 GMT, Richard Bos wrote:

>Fumeur <[e-mail]:

>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.hactually reads

int xfprintf(FILE *,const char *,...);
Would that warrant a bug report (rejects a conforming program)?

[Richard Bos]

Fumeur <[e-mail]:

On Mon, 21 Jan 2008 11:10:47 GMT, Richard Bos wrote:

Fumeur <[e-mail]:

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

[Keith Thompson]

Fumeur <[e-mail]:

On Mon, 21 Jan 2008 11:10:47 GMT, Richard Bos wrote:

>>Fumeur <[e-mail]:

>>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.hactually 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.hto use).
But IMHO it's a bad idea; implementation-defined functions should be
declared in implementation-defined headers, just for the sake of
clarity.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

Fumeur wrote:

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

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

Keith Thompson wrote:

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

--
Army1987 (Replace "NOSPAM" with "email")

[jacob navia]

Army1987 wrote:

Keith Thompson wrote:

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

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

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Antoninus Twink]

On 21 Jan 2008 at 23:03, jacob navia wrote:

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.

[Peter Nilsson]

Army1987 wrote:

Keith Thompson wrote:

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

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

jacob navia <[e-mail]:

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.

--
Peter

[Army1987]

Peter Nilsson wrote:

>Army1987 wrote:

Keith Thompson wrote:
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."

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.

--
Army1987 (Replace "NOSPAM" with "email")

[Army1987]

jacob navia wrote:

Army1987 wrote:

>Keith Thompson wrote:

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

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.

--
Army1987 (Replace "NOSPAM" with "email")

[Peter Nilsson]

Army1987 <[e-mail]:

Peter Nilsson wrote:

Army1987 wrote:
Keith Thompson wrote:
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."

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.

The issue is whether Jacob's implementation (which claims
conformance) has the right to define a behaviour for %b.
It does not.

For example, glibc's printf() prints strerror(errno) with
the %m specifier.

That too is broken.

Yes, using capitals would lower the chances for it to be
broken *in future*,

You miss the point of some of the standard's reservations.
They allow the committee to make choices that aren't already
tainted with widespread differences, viz snprintf.

But it's not just conversion specifiers with lcc-win, it's
length modifiers as well. Though Jacob at least asked last
time before he ignored advice...

"So many people has stolen the extra format characters for
various purposes that we actually had a hard time finding
one for use with fixed-point types in the embeded systems
TR. Since whoever uses these extensions surely cannot
expect other printf implementations to uderstand them, no
portability purpose is achieved by adding them to printf."
- Doug Gwyn, csc

but as it stands, it is not one of the
reasons why lcc-win32 is broken.

It is certainly not one of the main reasons. Nevertheless,
using a facet that implementors are specifically asked _not_
to use potentially undermines future standards. This is
ironic from a person who claims to want to improve the C
language.

--
Peter

[Randy Howard]

On Mon, 21 Jan 2008 07:54:53 -0600, jacob navia wrote
(in article <fn**********@aioe.org>):

Fumeur wrote:

>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!

Am I to understand that this is your response to a valid test case
submission?

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.

Well, that's professional. I can see why it is so widely used.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:

Keith Thompson wrote:

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

There's a footnote attached to the line you quoted:

See future library directions (7.26.9).

7.26.9 says:

Lowercase letters may be added to the conversion specifiers and
length modifiers in fprintf and fscanf. Other characters may be
used in extensions.

This was discussed here just recently. The use of "%b" as an
extension doesn't break any existing portable code, but a future
version of the standard could break the implementation.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:
[...]

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

jacob, you need to take a break. Seriously.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Army1987]

Peter Nilsson wrote:

Army1987 <[e-mail]:

>Peter Nilsson wrote:

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.

The issue is whether Jacob's implementation (which claims
conformance) has the right to define a behaviour for %b.
It does not.

>For example, glibc's printf() prints strerror(errno) with
the %m specifier.

That too is broken.

I think I'm missing a point.
7.19.6.1 says: "If a conversion specification is invalid, the behavior is
undefined.".
3.7.1 defines "undefined behavior" as "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for which
this International Standard imposes no requirements".

So if I'm right, if a program contains:
printf("%m");
anything it might do wouldn't violate the standard. This includes printing
strerror(errno).

If I'm wrong, what is a conforming implementation allowed to do when
executing the statement above, and what is it forbidden to do?

(Of course I'm using "broken" to mean "not conforming". Your point can
still be valid if you mean something else by it. Is this the case?)

--
Army1987 (Replace "NOSPAM" with "email")

[Keith Thompson]

Army1987 <ar******@NOSPAM.itwrites:

Peter Nilsson wrote:

>Army1987 <[e-mail]:

>>Peter Nilsson wrote:

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

The issue is whether Jacob's implementation (which claims
conformance) has the right to define a behaviour for %b.
It does not.

>>For example, glibc's printf() prints strerror(errno) with
the %m specifier.

That too is broken.

I think I'm missing a point.
7.19.6.1 says: "If a conversion specification is invalid, the behavior is
undefined.".
3.7.1 defines "undefined behavior" as "behavior, upon use of a
nonportable or erroneous program construct or of erroneous data, for which
this International Standard imposes no requirements".

So if I'm right, if a program contains:
printf("%m");
anything it might do wouldn't violate the standard. This includes printing
strerror(errno).

If I'm wrong, what is a conforming implementation allowed to do when
executing the statement above, and what is it forbidden to do?

(Of course I'm using "broken" to mean "not conforming". Your point can
still be valid if you mean something else by it. Is this the case?)

You're right. As far as I can tell, using "%b" as an extension to
print a value in binary doesn't render the compiler non-conforming.
So my statement upthread that this violates the standard was
incorrect. Sorry about that.

But as C99 7.26.9p1 says (under "Future library directions"):

Lowercase letters may be added to the conversion specifiers and
length modifiers in fprintf and fscanf. Other characters may be
used in extensions.

Given the above, I'd say that last sentence is more of a
recommendation than a requirement. I note that it doesn't say that
lowercase letters may not be used in extensions, only that other
characters may be used.

Implementations don't *have* to avoid using lowercase letters for
extensions in fprintf and fscanf, but they should.

jacob's response when this was brought up a week or so ago was quite
reasonable:

| Obvious: I did not know that. Since this is a very minor extension
| maybe I can just change it, but if people use it they will complain
|
| Stupid error from my part.

(I'm not saying it really was a stupid error, merely that jacob was
reasonable about admitting that it was an error.)

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"