Are C pitfalls the mistake of standard or that of implementations ?

  • Thread starter Jonathan Bartlett
  • Start date
J

Jonathan Bartlett

Greenhorn said:
Hi,
We see that C is a bit liberal towards non-standard syntax,
for e.g. when i tried
<printf("string1", "string2 %d", v1);> in Dev-C++, it printed string1
and no error was raised, is this the mistake of standard or the
implementation (Dev-C++).
I was under the impression that the implementations could have been
better by implementing proper rules and adhering to the standard (ANSI
C) at the same time, for e.g., in the above case i was assuming that
the standard would have specified something like "an implementation
MUST provide printf("string where % is special char..", var1,..);". Now
a good implementor could have implemented this along with an error chek
to see the user code strictly adheres to that format and raise an error
if not (my e.g., above).
But, many implementations, even popular ones don't seem to do this.
What do u opine? People who have read the actual Standard can throw
some light on the specification in the standard.

The issue is that the compiler can't necessarily see what you are
passing to printf, and it doesn't really care, either, as printf is a
library function and not an operator. Think of the following things:

1) the format string given to printf could also be a generated value, in
which case the compiler would not even be able to see what it is
2) printf is a library function, so someone could switch it out with
something that has different functionality, but the compiler wouldn't be
aware, and would generate errors even when there were none.
3) The call signature of printf is printf(char *format, ...). This
means that by its call signature, ANY number of parameters (except zero)
are LEGAL, even if the results aren't defined or useful. This is a
limitation of the C language, as this is a limitation of the way C
function prototypes work.

Jon
 
G

Greenhorn

Hi,
We see that C is a bit liberal towards non-standard syntax,
for e.g. when i tried
<printf("string1", "string2 %d", v1);> in Dev-C++, it printed string1
and no error was raised, is this the mistake of standard or the
implementation (Dev-C++).
I was under the impression that the implementations could have been
better by implementing proper rules and adhering to the standard (ANSI
C) at the same time, for e.g., in the above case i was assuming that
the standard would have specified something like "an implementation
MUST provide printf("string where % is special char..", var1,..);". Now
a good implementor could have implemented this along with an error chek
to see the user code strictly adheres to that format and raise an error
if not (my e.g., above).
But, many implementations, even popular ones don't seem to do this.
What do u opine? People who have read the actual Standard can throw
some light on the specification in the standard.

Greenhorn.
 
B

Ben Pfaff

Greenhorn said:
We see that C is a bit liberal towards non-standard syntax,
for e.g. when i tried
<printf("string1", "string2 %d", v1);> in Dev-C++, it printed string1
and no error was raised, is this the mistake of standard or the
implementation (Dev-C++).

This is the correct behavior. It is usually a mistake, so better
C implementations will warn about it, if you turn on that
feature. GCC is an example of an implementation that will do so.
 
K

Kenneth Bull

Greenhorn said:
Hi,
We see that C is a bit liberal towards non-standard syntax,
for e.g. when i tried
<printf("string1", "string2 %d", v1);> in Dev-C++, it printed string1
and no error was raised, is this the mistake of standard or the
implementation (Dev-C++).
I was under the impression that the implementations could have been
better by implementing proper rules and adhering to the standard (ANSI
C) at the same time, for e.g., in the above case i was assuming that
the standard would have specified something like "an implementation
MUST provide printf("string where % is special char..", var1,..);". Now
a good implementor could have implemented this along with an error chek
to see the user code strictly adheres to that format and raise an error
if not (my e.g., above).
But, many implementations, even popular ones don't seem to do this.
What do u opine? People who have read the actual Standard can throw
some light on the specification in the standard.

Greenhorn.


If you invoke undefined behaviour, any implementation can do anything
with your program. In others words "if you don't follow the rules,
anything can happen, and this 'anything' can be different for any
implementation"
 
W

Walter Roberson

: We see that C is a bit liberal towards non-standard syntax,
:for e.g. when i tried
:<printf("string1", "string2 %d", v1);> in Dev-C++, it printed string1
:and no error was raised, is this the mistake of standard or the
:implementation (Dev-C++).

Neither. There is no requirement in the definition of printf()
that all of the value arguments need to be "consumed" by the printf().

:I was under the impression that the implementations could have been
:better by implementing proper rules and adhering to the standard (ANSI
:C) at the same time, for e.g., in the above case i was assuming that
:the standard would have specified something like "an implementation
:MUST provide printf("string where % is special char..", var1,..);".

I don't understand that last bit. There is nothing in the standard
that requires that the first argument to printf() have a % format
specifier.

:Now
:a good implementor could have implemented this along with an error chek
:to see the user code strictly adheres to that format and raise an error
:if not (my e.g., above).

It isn't an error. Some compilers will warn about it, as will 'lint'.
 
I

infobahn

Walter said:
If a troll and a half can hook a reader and a half in a posting and a half,
how many readers can six trolls hook in six postings?

I make it 24. I stand ready to be corrected.
 
G

Greenhorn

I agree that any implementation can do anything, y not leverage on that
and try to raise warnings and errors when that is not expected in that
form. for e.g., i am guessing that ANSI standard doesn't say something
like "no errors are to be raised when printf("blah bhal.. is used".
which means an implementation can raise error (atleast a warning).
Ofcourse, some implementations use warnings as a proper tool.

Greenhorn
 
G

Greenhorn

I agree that any implementation can do anything, y not leverage on that
and try to raise warnings and errors when that is not expected, say in
an expression. For e.g., i am guessing that ANSI standard doesn't say
something like "no errors are to be raised when printf("blah bhal.. is
used" which means an implementation can raise error (atleast a
warning). Ofcourse, some implementations use warnings as a proper tool.

Greenhorn
 
C

CBFalconer

Greenhorn said:
I agree that any implementation can do anything, y not leverage on that

In c.l.c. and most other newsgroups, PLEASE DO NOT TOPPOST. Your
answer belongs after (or intermixed with) the material you are
quoting, after snipping out anything not germane to your reply.

Also, do not use silly one letter abbreviations for English words.
 
J

jacob navia

Greenhorn said:
Hi,
We see that C is a bit liberal towards non-standard syntax,
for e.g. when i tried
<printf("string1", "string2 %d", v1);> in Dev-C++, it printed string1
and no error was raised, is this the mistake of standard or the
implementation (Dev-C++).
I was under the impression that the implementations could have been
better by implementing proper rules and adhering to the standard (ANSI
C) at the same time, for e.g., in the above case i was assuming that
the standard would have specified something like "an implementation
MUST provide printf("string where % is special char..", var1,..);". Now
a good implementor could have implemented this along with an error chek
to see the user code strictly adheres to that format and raise an error
if not (my e.g., above).
But, many implementations, even popular ones don't seem to do this.
What do u opine? People who have read the actual Standard can throw
some light on the specification in the standard.

Greenhorn.

If you use the lcc-win32 compiler (and other compilers as well)
you get:
D:\lcc\mc63\test>type tpr.c
#include <stdio.h>
int main(void)
{
int v1=7;
printf("string1", "string2 %d", v1);
}

D:\lcc\mc63\test>lc tpr.c
Warning tpr.c: 5 printf: too many arguments
0 errors, 1 warnings

D:\lcc\mc63\test>
 
I

infobahn

D:\lcc\mc63\test>lc tpr.c
Warning tpr.c: 5 printf: too many arguments
0 errors, 1 warnings

Consider:

fprintf(stderr,
"%u error%s, %u warning%s\n",
count_errs,
(count_errs == 1) ? "" : "s",
count_warns,
(count_warns == 1) ? "" : "s");
 
J

jacob navia

infobahn said:
jacob navia wrote:





Consider:

fprintf(stderr,
"%u error%s, %u warning%s\n",
count_errs,
(count_errs == 1) ? "" : "s",
count_warns,
(count_warns == 1) ? "" : "s");

There are no errors in there. If you modify it
slightly:

D:\lcc\mc63\test>type tpr1.c
#include <stdio.h>
int main(void)
{
int count_errs=2,count_warns = 67;

fprintf(stderr,
"%u error%s, %u warning%s\n",
count_errs,
(count_errs == 1) ? 4 : 8, // error in here
count_warns,
(count_warns == 1) ? "" : "s");
}

D:\lcc\mc63\test>lc tpr1.c
Warning tpr1.c: 11 fprintf argument mismatch for format s. Expected
char pointer got int
0 errors, 1 warnings

D:\lcc\mc63\test>


I do not think that lcc-win32 has *all* possible cases in store. The
evaluation of an argument could be of indeterminate type, etc.

BUT

Just because you can't catch 100% of the cases, this doesn't
justify catching 0% and doing nothing. If you get 95% of the errors
it is still much better than nothing!
 
C

Chris Croughton

There are no errors in there. If you modify it
slightly:

Correct, there are no errors in that statement. The error is in your
compiler, and the code snippet is one way to fix it (altering the
variables to suit).

Hint: is one plural?

Chris C
 
I

infobahn

Chris said:
Correct, there are no errors in that statement. The error is in your
compiler, and the code snippet is one way to fix it (altering the
variables to suit).

Hint: is one plural?

Chris: Jacob's (*cough*) reply hasn't hit my server yet, so thanks
for setting him straight.

Sometimes I despair of humanity, I really do.
 
C

CBFalconer

Richard said:
Somewhere in the thousands. Trolls have an exponentiating influence
on eachother.

They closely resemble flies gathering around a dead fish.
 

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

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top