By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,159 Members | 947 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,159 IT Pros & Developers. It's quick & easy.

printf("%d", INT_MAX);

P: n/a
Hey,

It was mentioned elsewhere that printf("%d", INT_MAX);
is implementation-defined. Why? Is it because INT_MAX
value is implementation-defined so output depends
on implementation, or is it something more subtle so
that output of the following is also implementation-defined:

if (INT_MAX == 65535)
printf("%d", INT_MAX);
else
printf("%d", 65535);

Thanks,
Yevgen
Mar 14 '07 #1
Share this Question
Share on Google+
26 Replies


P: n/a
Yevgen Muntyan wrote:
Hey,

It was mentioned elsewhere that printf("%d", INT_MAX);
is implementation-defined. Why? Is it because INT_MAX
value is implementation-defined so output depends
on implementation, or is it something more subtle so
that output of the following is also implementation-defined:

if (INT_MAX == 65535)
printf("%d", INT_MAX);
else
printf("%d", 65535);
Um, I again made it overcomplicated. Is this implementation-defined:

printf("%d\n", 65535);

(if \n matters, then we print \n after the first piece of code too,
it's there in main()).

Yevgen
Mar 14 '07 #2

P: n/a
Yevgen Muntyan wrote:
Yevgen Muntyan wrote:
>Hey,

It was mentioned elsewhere that printf("%d", INT_MAX);
is implementation-defined. Why? Is it because INT_MAX
value is implementation-defined so output depends
on implementation, or is it something more subtle so
that output of the following is also implementation-defined:

if (INT_MAX == 65535)
printf("%d", INT_MAX);
else
printf("%d", 65535);

Um, I again made it overcomplicated. Is this implementation-defined:

printf("%d\n", 65535);
After consulting the standard, the above should be

printf("%d\n", 32767);

Oh well.

Yevgen
Mar 14 '07 #3

P: n/a
Yevgen Muntyan wrote On 03/14/07 13:29,:
Yevgen Muntyan wrote:
>>Yevgen Muntyan wrote:
>>>Hey,

It was mentioned elsewhere that printf("%d", INT_MAX);
is implementation-defined. Why? Is it because INT_MAX
value is implementation-defined so output depends
on implementation, or is it something more subtle so
that output of the following is also implementation-defined:

if (INT_MAX == 65535)
printf("%d", INT_MAX);
else
printf("%d", 65535);

Um, I again made it overcomplicated. Is this implementation-defined:

printf("%d\n", 65535);


After consulting the standard, the above should be

printf("%d\n", 32767);
It seems there are several questions here.

The value of INT_MAX is implementation-defined, so the
output produced by printf("%d\n", INT_MAX) is implementation-
defined. There is nothing "wrong" with the operation, but
a strictly-conforming program must not perform it.

The effect of printf("%d\n", 65535) is implementation-
UNdefined (if I may coin a term). If the implementation-
defined value of INT_MAX is >= 65535, then the output is
well defined. If INT_MAX < 65535, the constant 65535 is
of type unsigned int and the behavior is undefined because
"%d" requires a signed int. Hence, it is implementation-
defined whether the behavior is well defined or undefined.

The effect of printf("%d\n", 32767) is the same on all
hosted implementations (barring I/O errors).

--
Er*********@sun.com
Mar 14 '07 #4

P: n/a
Eric Sosman wrote:
Yevgen Muntyan wrote On 03/14/07 13:29,:
>Yevgen Muntyan wrote:
>>Yevgen Muntyan wrote:

Hey,

It was mentioned elsewhere that printf("%d", INT_MAX);
is implementation-defined. Why? Is it because INT_MAX
value is implementation-defined so output depends
on implementation, or is it something more subtle so
that output of the following is also implementation-defined:

if (INT_MAX == 65535)
printf("%d", INT_MAX);
else
printf("%d", 65535);
Um, I again made it overcomplicated. Is this implementation-defined:

printf("%d\n", 65535);

After consulting the standard, the above should be

printf("%d\n", 32767);

It seems there are several questions here.

The value of INT_MAX is implementation-defined, so the
output produced by printf("%d\n", INT_MAX) is implementation-
defined. There is nothing "wrong" with the operation, but
a strictly-conforming program must not perform it.
Sure.
The effect of printf("%d\n", 65535) is implementation-
UNdefined (if I may coin a term). ...
I thought (wrongly) 65535 was minimal value for INT_MAX.

[snip]
The effect of printf("%d\n", 32767) is the same on all
hosted implementations (barring I/O errors).
And this is what I asked about. I wanted to make sure there
is nothing special about passing INT_MAX as int to a variadic
function or something.
This printf thing was mentioned in connection to another instance
of implementation-defined behavior, where any behavior other
than the "right" one would break code in a serious way, so I wanted
to clarify if this INT_MAX is a usual pedant's story or something
serious.

Thanks,
Yevgen
Mar 14 '07 #5

P: n/a
Yevgen Muntyan wrote On 03/14/07 13:59,:
Eric Sosman wrote:
> The effect of printf("%d\n", 32767) is the same on all
hosted implementations (barring I/O errors).


And this is what I asked about. I wanted to make sure there
is nothing special about passing INT_MAX as int to a variadic
function or something.
No, nothing special. INT_MAX must expand to an expression
whose type is `int'; an expansion with the right value but
some other type would be wrong. Since INT_MAX is already an
`int', no promotions occur. Similarly, `32767' is already an
`int' and nothing happens to it.
This printf thing was mentioned in connection to another instance
of implementation-defined behavior, where any behavior other
than the "right" one would break code in a serious way, so I wanted
to clarify if this INT_MAX is a usual pedant's story or something
serious.
Neither, I think, since there's nothing wrong with it.
My point about printf("%d\n", 65535) is purest pedantry, but
printf("%d\n", INT_MAX) is beyond reproach (despite not being
strictly conforming).

--
Er*********@sun.com
Mar 14 '07 #6

P: n/a
Yevgen Muntyan wrote:
>
.... snip ...
>
Um, I again made it overcomplicated. Is this implementation-defined:

printf("%d\n", 65535);
Yes, because there is no guarantee that 65535 is an int. It may be
a long int. It is outside the guaranteed range of an int.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Mar 15 '07 #7

P: n/a
CBFalconer wrote:
Yevgen Muntyan wrote:
... snip ...
>Um, I again made it overcomplicated. Is this implementation-defined:

printf("%d\n", 65535);

Yes, because there is no guarantee that 65535 is an int. It may be
a long int. It is outside the guaranteed range of an int.
It's not implementation-defined if INT_MAX is less than 65535, is it?
Anyway, as you probably know, it was a wrong question.

Yevgen
Mar 15 '07 #8

P: n/a
On Wed, 14 Mar 2007 17:24:02 GMT, Yevgen Muntyan
<mu****************@tamu.eduwrote in comp.lang.c:
Hey,

It was mentioned elsewhere that printf("%d", INT_MAX);
is implementation-defined. Why? Is it because INT_MAX
value is implementation-defined so output depends
on implementation, or is it something more subtle so
that output of the following is also implementation-defined:

if (INT_MAX == 65535)
printf("%d", INT_MAX);
else
printf("%d", 65535);

Thanks,
Yevgen
Aside from newline issue, that you posted a correction to, the snippet
above, when packaged within an appropriate program with inclusion of
<stdio.hand <limits.his not strictly conforming, as pointed out in
4 p5 of the C99 standard:

"A strictly conforming program shall use only those features of the
language and library specified in this International Standard. It
shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit."

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Mar 15 '07 #9

P: n/a
Eric Sosman wrote:
[...]
The value of INT_MAX is implementation-defined, so the
output produced by printf("%d\n", INT_MAX) is implementation-
defined. There is nothing "wrong" with the operation, but
a strictly-conforming program must not perform it.
[...]

So, technically speaking, the following is non-conforming?

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
printf("INT_MAX is %d\n",INT_MAX);
return(EXIT_SUCCESS);
}

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>
Mar 15 '07 #10

P: n/a
Kenneth Brody <ke******@spamcop.netwrites:
So, technically speaking, the following is non-conforming?

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
printf("INT_MAX is %d\n",INT_MAX);
return(EXIT_SUCCESS);
}
It's not strictly conforming, but it is conforming:

A strictly conforming program shall use only those features
of the language and library specified in this International
Standard.2) It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior,
and shall not exceed any minimum implementation limit.

...
A conforming program is one that is acceptable to a
conforming implementation.4)

...
4) Strictly conforming programs are intended to be maximally
portable among conforming implementations. Conforming
programs may depend upon nonportable features of a
conforming implementation.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms
Mar 15 '07 #11

P: n/a
Kenneth Brody wrote On 03/15/07 10:46,:
Eric Sosman wrote:
[...]
> The value of INT_MAX is implementation-defined, so the
output produced by printf("%d\n", INT_MAX) is implementation-
defined. There is nothing "wrong" with the operation, but
a strictly-conforming program must not perform it.

[...]

So, technically speaking, the following is non-conforming?

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
printf("INT_MAX is %d\n",INT_MAX);
return(EXIT_SUCCESS);
}
It is conforming, but not strictly conforming. From
section 4, paragraphs 5 and 7 and footnote 4:

A /strictly conforming program/ [...] shall not
produce output dependent on [...] implementation-
defined behavior [...]

A /conforming program/ is one that is acceptable to
a conforming implementation. 4)

4) Strictly conforming programs are intended to be
maximally portable among conforming implementations.
Conforming programs may depend upon nonportable
features of a conforming implementation.

The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!

When the ANSI Standard was young there used to be a lot of
discussions in c.l.c. about just what "strictly conforming" and
"conforming" were, with reams of writing claiming to explicate
the Real Intent of the writers, sort of like lawyers trying to
find an inherent right to broadband in the U.S. Constitution.
Among these cacophonies of opinion one would occasionally find
"proofs" of the non-existence of strictly conforming programs,
or of "non-silly" strictly conforming programs. For example:

- An S.C. program cannot use the #include directive except
for the headers described in the Standard itself, because
the search algorithm for other headers is implementation-
defined. Since the effect of #include "foo.h" is defined
by the implementation, a program that uses it depends on
implementation-defined behavior.

- An S.C. program cannot terminate, because its termination
status is part of its "output" and has an implementation-
defined form, hence a program that terminates produces
output that depends on implementation-defined behavior.

- An S.C. program cannot produce any output at all, because
the output is rendered in an implementation-defined
character encoding.

- An S.C. program cannot allow its output to be affected by
the success or failure of any particular malloc() call,
because the conditions under which malloc() succeeds or
fails are implementation-defined. An S.C. program can
call malloc(), but even if every single malloc() call
returns NULL its output must be unchanged.

.... and so on. Some arguments of this sort were probably raised
for the purpose of amusement (like the fanciful descriptions of
undefined behavior that used to be popular; "demons will fly from
your nose" was just one of many). Some were probably raised to
mock the newly-minted Standard. Some may have been intended as
serious criticisms. All seem to me to have had tiny grains of
truth (however distorted), enough grains to suggest that this
part of the Standard may have feet of slowly-crumbling clay.

--
Er*********@sun.com
Mar 15 '07 #12

P: n/a
Eric Sosman wrote:
>
Kenneth Brody wrote On 03/15/07 10:46,:
Eric Sosman wrote:
[...]
The value of INT_MAX is implementation-defined, so the
output produced by printf("%d\n", INT_MAX) is implementation-
defined. There is nothing "wrong" with the operation, but
a strictly-conforming program must not perform it.
[...]

So, technically speaking, the following is non-conforming?

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(void)
{
printf("INT_MAX is %d\n",INT_MAX);
return(EXIT_SUCCESS);
}

It is conforming, but not strictly conforming. From
section 4, paragraphs 5 and 7 and footnote 4:

A /strictly conforming program/ [...] shall not
produce output dependent on [...] implementation-
defined behavior [...]

A /conforming program/ is one that is acceptable to
a conforming implementation. 4)

4) Strictly conforming programs are intended to be
maximally portable among conforming implementations.
Conforming programs may depend upon nonportable
features of a conforming implementation.

The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!
Kenneth Brody's program
is what the C standard calls "a correct program".

N869
4. Conformance
[#3] A program that is correct in all other aspects,
operating on correct data, containing unspecified behavior
shall be a correct program and act in accordance with
5.1.2.3.

Even though the term isn't used that often on this newsgroup,
"correct programs"
is what I consider this newsgroup to be mostly about.

Ben Pfaff likes the term "correct program".

"When I wrote my earlier article in this thread, I knew that
"strictly conforming" was not a perfect term, but I didn't have a
better one and didn't feel like adding a lot of qualifiers or an
extended explanation."

http://groups.google.com/group/comp....807153d40349c7

--
pete
Mar 16 '07 #13

P: n/a
Eric Sosman wrote:
>
.... snip ...
>
The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!
I don't think a strictly conforming *program* exists, but many
strictly conforming *routines* do exist. I.E. those routines that
can be implemented anywhere.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Mar 16 '07 #14

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Eric Sosman wrote:
>>
... snip ...
>>
The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!

I don't think a strictly conforming *program* exists, but many
strictly conforming *routines* do exist. I.E. those routines that
can be implemented anywhere.
The standard doesn't talk about strictly conforming routines, and I
think the phrase "strictly conforming" is so narrowly defined that we
should avoid using it other than in the sense specified in the
standard. The idea of "routines that can be implemented anywhere" is
certainly a useful one, though; perhaps that's the same as "routines
(function?) that can potentially be used in a strictly conforming
program".

There's some controversy about what is or is not a "strictly
conforming program", but here's a program that I think meets the
definition unambiguously:

int main(void) { return 0; }

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 16 '07 #15

P: n/a
CBFalconer wrote, On 15/03/07 21:52:
Eric Sosman wrote:
... snip ...
> The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!

I don't think a strictly conforming *program* exists,
<pedantic>
What about:
int main(void)
{
return 0;
}
</pedantic>
but many
strictly conforming *routines* do exist. I.E. those routines that
can be implemented anywhere.
I think we can deal with code that is not strictly conforming within
certain limits. Such as, to take a simple example, a program printing
values from limits.h
--
Flash Gordon
Mar 16 '07 #16

P: n/a
Flash Gordon wrote On 03/16/07 14:48,:
CBFalconer wrote, On 15/03/07 21:52:
>>Eric Sosman wrote:
... snip ...
>> The distinction between strictly conforming and conforming
programs is one that the Standard is pretty much forced to make,
but it has always seemed to me that the Standard's definition
of strict conformance is too restrictive to be as useful as it
should be. When a program like Kenneth Brody's turns out not
to be strictly conforming, I think the baby has been thrown out
with the bath water. But I have no better definition to offer,
so I can't complain very convincingly!

I don't think a strictly conforming *program* exists,


<pedantic>
What about:
int main(void)
{
return 0;
}
</pedantic>
Sorry: It returns an implementation-defined form of
"success" to the host environment. Something that goes
from the program to the environment is surely "output,"
hence the program produces implementation-defined output.

;-)
I think we can deal with code that is not strictly conforming within
certain limits. Such as, to take a simple example, a program printing
values from limits.h
Nailing down the "certain limits" is the hard part,
the part for which I at least have nothing constructive
to offer.

"I shall not today attempt further to define the
kinds of material I understand to be embraced
within that shorthand description; and perhaps I
could never succeed in intelligibly doing so. But
I know it when I see it, [...]"
-- Justice Potter Stewart

--
Er*********@sun.com
Mar 16 '07 #17

P: n/a
Keith Thompson wrote:
CBFalconer <cb********@yahoo.comwrites:
.... snip ...
>>
I don't think a strictly conforming *program* exists, but many
strictly conforming *routines* do exist. I.E. those routines that
can be implemented anywhere.

The standard doesn't talk about strictly conforming routines, and I
think the phrase "strictly conforming" is so narrowly defined that
we should avoid using it other than in the sense specified in the
standard. The idea of "routines that can be implemented anywhere"
is certainly a useful one, though; perhaps that's the same as
"routines (function?) that can potentially be used in a strictly
conforming program".
For many years I have made a practice of trying to isolate routines
that operate only on memory from something that affects
peripherals, in any language. For example, I may have a routine
that outputs a char, and one that converts a nibble to hex, I
would break this up (in assembly) to:

push acc
shr 4
call hexcvt
call cout
pop acc
call hexcvt
call cout

and use of 'fallthru' can shorted the overall code. This might
give me couthx as:

couthx: call hexcvt
; " " (fall thru)
cout: whatever

reducing the above to:

push acc
shr 4
call couthx
pop acc
; " " (fall thru)
couthx:

You can't apply the fall thru strategies in C, but the rest
applies.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Mar 16 '07 #18

P: n/a
Eric Sosman <Er*********@sun.comwrites:
Flash Gordon wrote On 03/16/07 14:48,:
>CBFalconer wrote, On 15/03/07 21:52:
[...]
>>>I don't think a strictly conforming *program* exists,


<pedantic>
What about:
int main(void)
{
return 0;
}
</pedantic>

Sorry: It returns an implementation-defined form of
"success" to the host environment. Something that goes
from the program to the environment is surely "output,"
hence the program produces implementation-defined output.

;-)
I feel reasonably confident that the comittee did not intend the
concept of "strictly conforming" to be quite *that* useless.

However:

int main(void) { while (1); }

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 16 '07 #19

P: n/a
Keith Thompson wrote, On 16/03/07 21:50:
Eric Sosman <Er*********@sun.comwrites:
>Flash Gordon wrote On 03/16/07 14:48,:
>>CBFalconer wrote, On 15/03/07 21:52:
[...]
>>>I don't think a strictly conforming *program* exists,

<pedantic>
What about:
int main(void)
{
return 0;
}
</pedantic>
Sorry: It returns an implementation-defined form of
"success" to the host environment. Something that goes
from the program to the environment is surely "output,"
hence the program produces implementation-defined output.

;-)

I feel reasonably confident that the comittee did not intend the
concept of "strictly conforming" to be quite *that* useless.

However:

int main(void) { while (1); }
It even still leaves us something to discuss. I prefer
int main(void)
{
for (;;)
continue;
}

:-)
--
Flash Gordon
Mar 17 '07 #20

P: n/a
Flash Gordon wrote:
>
Keith Thompson wrote, On 16/03/07 21:50:
.... snip ...
>
>I feel reasonably confident that the comittee did not intend the
concept of "strictly conforming" to be quite *that* useless.

However:

int main(void) { while (1); }

It even still leaves us something to discuss. I prefer
int main(void)
{
for (;;)
continue;
}
You both omitted the final "return 0" for C90. :-)

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

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

Mar 17 '07 #21

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Flash Gordon wrote:
>Keith Thompson wrote, On 16/03/07 21:50:
... snip ...
>>
>>I feel reasonably confident that the comittee did not intend the
concept of "strictly conforming" to be quite *that* useless.

However:

int main(void) { while (1); }

It even still leaves us something to discuss. I prefer
int main(void)
{
for (;;)
continue;
}

You both omitted the final "return 0" for C90. :-)
Which could cause problems as soon as control reaches the closing
brace. Wait here and let me know what happens.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Mar 17 '07 #22

P: n/a
Keith Thompson wrote On 03/16/07 17:50,:
Eric Sosman <Er*********@sun.comwrites:
>>Flash Gordon wrote On 03/16/07 14:48,:
>>>CBFalconer wrote, On 15/03/07 21:52:

[...]
>>>>I don't think a strictly conforming *program* exists,
<pedantic>
What about:
int main(void)
{
return 0;
}
</pedantic>

Sorry: It returns an implementation-defined form of
"success" to the host environment. Something that goes
from the program to the environment is surely "output,"
hence the program produces implementation-defined output.

;-)


I feel reasonably confident that the comittee did not intend the
concept of "strictly conforming" to be quite *that* useless.

However:

int main(void) { while (1); }
Strictly conforming, I believe. The problem is to find
an implementation that can execute it correctly.

--
Er*********@sun.com
Mar 19 '07 #23

P: n/a
Eric Sosman wrote:
>
Keith Thompson wrote On 03/16/07 17:50,:
int main(void) { while (1); }

Strictly conforming, I believe. The problem is to find
an implementation that can execute it correctly.
Here's another one that's strictly conforming
and which some M$ compilers won't compile:

int main(void)
{
int zero = 0;

return zero && (1 / 0);
}

--
pete
Mar 19 '07 #24

P: n/a
pete wrote:
Eric Sosman wrote:

Keith Thompson wrote On 03/16/07 17:50,:
int main(void) { while (1); }
Strictly conforming, I believe. The problem is to find
an implementation that can execute it correctly.

Here's another one that's strictly conforming
and which some M$ compilers won't compile:

int main(void)
{
int zero = 0;

return zero && (1 / 0);
}
Here's another one that's strictly conforming and which some G¢¢
(seriously, enough with the "M$") compilers won't compile:

int f(void)
{
int result = 1 / 0;
return result;
}

int main(void)
{
return 0 && f();
}

Mar 19 '07 #25

P: n/a
Harald van Dijk wrote:
pete wrote:
>Eric Sosman wrote:
>>Keith Thompson wrote On 03/16/07 17:50,:
int main(void) { while (1); }
Strictly conforming, I believe. The problem is to find
an implementation that can execute it correctly.
Here's another one that's strictly conforming
and which some M$ compilers won't compile:

int main(void)
{
int zero = 0;

return zero && (1 / 0);
}

Here's another one that's strictly conforming and which some G¢¢
(seriously, enough with the "M$") compilers won't compile:

int f(void)
{
int result = 1 / 0;
return result;
}

int main(void)
{
return 0 && f();
}
My DJGPP (GNU C 3.1) issues a warning..

d0.c: In function `f':
d0.c:3: warning: division by zero

...and compiles. Running the program gives no error so I'll assume f()
doesn't get called.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Mar 20 '07 #26

P: n/a
Joe Wright wrote:
Harald van Dijk wrote:
pete wrote:
Eric Sosman wrote:
Keith Thompson wrote On 03/16/07 17:50,:
int main(void) { while (1); }
Strictly conforming, I believe. The problem is to find
an implementation that can execute it correctly.
Here's another one that's strictly conforming
and which some M$ compilers won't compile:

int main(void)
{
int zero = 0;

return zero && (1 / 0);
}
Here's another one that's strictly conforming and which some G¢¢
(seriously, enough with the "M$") compilers won't compile:

int f(void)
{
int result = 1 / 0;
return result;
}

int main(void)
{
return 0 && f();
}
My DJGPP (GNU C 3.1) issues a warning..

d0.c: In function `f':
d0.c:3: warning: division by zero

..and compiles. Running the program gives no error so I'll assume f()
doesn't get called.
Try compiling with the -ansi and -pedantic-errors options (with which
GCC aims to conform to C90 as strictly as allowed). If it still works
then, you're not using a version of GCC affected by that particular
bug.

Mar 20 '07 #27

This discussion thread is closed

Replies have been disabled for this discussion.