Environmental limits

n1256.pdf (C99 TC3), 5.2.4.1 Translation limits p1 says:Does that mean that *any* program using an array of two or more
elements other than char is allowed to be rejected by an
implementation?

For example,

int main(void) { int array[2]; return 0; }

*if* sizeof (int) >= 65535/2 + 1

I understand that this is purely theoritical, but I'd like to hear
opinions.
Is this a deficiency? Am I missing something?

re: Environmental limits

vippstar@gmail.com said:
Yes (can you say "pathological"?).
Right. But QoI raises its beatific head and rushes, sword in hand, to the
rescue. This particular dragon will never byte you, because either (a) it
doesn't exist, or (b) it's dead, from starvation.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

re: Environmental limits

Richard Heathfield wrote:If the program is translated and executed,
and excedes environmental limits,
I don't think that the standard library functions
are required to work correctly.

qsort is allowed to be written in C,
and is allowed to use ptrdiff_t expressions
which may be undefined if the qsort function
operates on arrays with more than 65535 bytes.

--
pete

re: Environmental limits

pete said:
I don't think anything is required to work if environmental limits are
exceeded.
Yes. Do you know of any implementations where an array of two int objects
occupies >= 65535 bytes? What is your estimate of the likelihood that such
an implementation would be popular among developers?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

re: Environmental limits

Richard Heathfield wrote:I have a program called "e_driver" at:

http://www.mindspring.com/~pfilandr/C/e_driver/

which times sorting functions.

Typically, I time them on allocated
arrays of about 8000000 bytes.
For that reason,
I don't use ptrdiff_t expressions
in the the sorting functions.

I think that if e_driver is translated and executed,
then even when it excedes translation limits,
it is still a "correct program" and has to work right,
unless I'm using it to time qsort.

--
pete

re: Environmental limits

On 27 Ago, 16:19, vipps...@gmail.com wrote:Uhm, a int of 34 KB is just ridiculous.. no one would use that
implementation.

But.. I wonder if that rule is valid in a scenario like this:
struct Huge {
char fill[32];
};

struct Huge v[2];

I think that's okay, but.. what's the difference?
Thanks,

s.

re: Environmental limits

On Aug 27, 6:51 pm, Sergio Perticone <g4ll...@gmail.comwrote:IMHO 9 bits in a char is also ridiculous, but it exists.
Note "purely theoritical".
The struct might have 65536/2 + 1 - 32 or more padding bytes. :-)

re: Environmental limits

<vippstar@gmail.comwrote in message
news:476e3b98-d402-46f7-837a-723dbe0c8a04@p25g2000hsf.googlegroups.com...The document doesn't seem to define what an object is. It sounds like it
could also be an entire array, which means a C99 translator must be able to
be deal with arrays of at least 65535 bytes.

But, these translator limits appear to be set at a low enough level to make
it easier to generate comforming C99 implementations (which has really
helped..), while most actual implementations can have bigger limits.

In this case, it does seem likely that 'object' refers to entire arrays and
structs, rather than primitive types, where a 255/256-byte limit would have
been more appropriate.

As it is, the standard /does/ appear to allow ints and objects of any size,
for example a 65536-byte int and a 65536-byte maximum object; such an
implementation could only deal with 1-element arrays of int. But a real
implementation with a 65536-byte int would surely have a much larger maximum
object size?

So, it looks like you are right to worry, not about your unlikely huge ints,
but about char array[66000].

--
Bartc

re: Environmental limits

On Aug 27, 7:16 pm, "Bartc" <b...@freeuk.comwrote:It does. See 3.14 p 1:So yes; an array is an object.
Your wording is incorrect. Not at least, but at most, and once.
Indeed. The standard suggests in a footnote that implemenations should
not have fixed limits at all.
I disagree. Why would you want to limit C? That would mean an
implementor wouldn't be able to provide a 1024 byte integer (intmax_t)
correction: minus one. (65535)
Of course, char can't be anything other than 1.
It needs not to, as I understand it.
sizeof (int) == 65535
SIZE_MAX == 65535
I'm not worrying about anything. I just had this idea about creating a
"pathological" implementation that "pushes" C to its "limits". :-)

re: Environmental limits

On 27 Aug 2008 at 15:04, Richard Heathfield wrote:Wow!! Has Heathfield finally seen the light?

Preposterously bad QoI that would never ever exist in the real world is
usually the bread and butter of Heathfield and his sycophants' rantings
in this group.

re: Environmental limits

<vippstar@gmail.comwrote in message
news:8c74c48d-b9ae-42ae-86d9-9bf19e92c80e@59g2000hsb.googlegroups.com...That's not so clear.
No, for the purpose of passing this test, at least 65535 bytes is implied
(dealing with only 65534, at most, would fail, while being able to deal with
65536 bytes or more, would pass with flying colours). (There's also the
question of how many 65535-byte objects should a single module be allowed;
if you can only rely on one such object?... or 2 objects of 32767...?)
Well, 256 bytes gives a generous 2048 bits (more depending on CHAR_BIT); but
this would be the minimum an implementation would need to allow for.
No, 65536, as I've taken the liberty of my hypothetical implementation being
able to do one byte better. But if you like, a rather odd 65535-byte int and
65535-byte object limit have the same problem.
If by 'byte' they are talking about 'character', then yes. In that case
similarly CHAR_BIT appears to have no upper limit.

--
Bartc

re: Environmental limits

Sergio Perticone <g4ll0ws@gmail.comwrites:And 640 kilobytes of memory is enough for anyone. 8-)}

Seriously, I agree that a 34-kilobyte int would be absurd -- though
calculations on very large integers can be quite useful. It's
plausible that some language or implementation in the future could
provide a very large fixed-size integer type when hardware becomes
powerful enough to support it. But by that time, I'd expect that it
wouldn't be called "int", or that some future C standard will deal
with the new limits in some other way.

The point is that the C standard doesn't place *any* upper bound on
the range of an int. Any such bound would be arbitrary. And in some
cases, the standard just relies on implementers to behave sanely.
In theory, there could be an arbitrary amount of padding after the
"fill" member, and sizeof(struct Huge) could be anything in the range
32 .. SIZE_MAX.

If you use an array type directly rather than wrapping it in a struct
then you're safe:

typedef char huge[32];
huge v[2];

It's guaranteed that sizeof v == 64.

*However*, the standard's capacity requirement is merely that it can
accept *one* program that meets all the specified minima. That one
program won't necessarily be yours. Realistically, if you've already
declared a lot of large objects, your 64-byte object just might be
what pushes it over the edge.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

Bartc wrote:.....It's true. If you don't think it's clear, could you explain why?

....Characters are what objects of type "char" represent; 1 byte is the
size of a a char. That's how C defines a byte.
Correct.

re: Environmental limits

On Wed, 27 Aug 2008 07:19:33 -0700, vippstar wrote:It means any program using any non-character object is allowed to be
rejected by an implementation. This includes int[2], but it also includes
int itself.

re: Environmental limits

<jameskuyper@verizon.netwrote in message
news:55a70f91-a751-4cc7-8b32-5ace4aa55fdb@e53g2000hsa.googlegroups.com...Because it's not clear whether an array is one object, or a collection of
objects.


--
Bartc

re: Environmental limits

Bartc wrote:What makes you think that an array can't be both
an object and also a collection of objects?

N869
6.2.5 Types
[#21] Array and structure types
are collectively called aggregate types.


6.5.8 Relational operators
[#5]
If the objects pointed to are members of the same aggregate
object,

--
pete

re: Environmental limits

Harald van Dijk <truedfx@gmail.comwrites:An object of type char[2], which is a non-character object, cannot
exceed the object size limit.

However, the standard only requires an implementation to accept *one*
program that meets each of the stated limits. In theory, an
implementation could specifically recognize one special program and
reject anything else that has an object bigger than 32767 bytes.

The intent of that section of the standard is that the *easiest* way
to meet the requirement is just to provide reasonable limits, or no
fixed limits at all. It does provide some interesting opportunities
for a really perverse implementation, but as far as I know nobody has
actually bothered to implement one. Writing a conforming C
implementation, even one that's not useful, is a sufficiently large
task that nobody has the time to do it as a joke.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

Keith Thompson wrote:
....I was under the impression that someone had done precisely that. All
that is actually required is to implement translation phases 1-4, and
phase 4 only needs to be implemented far enough to identify any #error
directives that survive conditional compilation. If a #error does
survive, then the implementation must reject the code with the
required error message. Otherwise, it can check whether the input is
it's own "one program" that must be translated and executed correctly,
and generate an executable that has the required behavior for that
program. This isn't difficult, since the "one program" is designated
by the implementor, and it's trivial to write a "one program" which
meets all the requirements of that section while having required
behavior which is equivalent to "int main(void) {return 0;}". Finally,
for any other program, issue the message "Program accepted, even
though it may contain syntax errors or constraint violations". At that
point, the "implementation" has technically met all of the
requirements imposed by the standard.

That doesn't seem very difficult, and I thought that someone has
already done so, though I can't remember who.

re: Environmental limits

On Thu, 28 Aug 2008 07:53:18 -0700, Keith Thompson wrote:Nice catch.
I used to agree. It's certainly true that 5.2.4.1p1 only requires an
implementation to accept one program that meets each of the stated limits:
it explicitly says so. However, the implementation needs to support
5.2.4.1p1 at the same time as the rest of the standard. In particular, if
none of the limits are exceeded, then is there any reason why 4p3 does not
apply?

4p3:
"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."

re: Environmental limits

Harald van Dijk <truedfx@gmail.comwrites:[...]If that's the case, then it renders the "one program" clause
meaningless; the implementation must accept *all* correct programs
that do not exceed any of the limits.

For example, an implementation might accept up to 63 significant
characters in a macro name and up to 4095 macro identifiers
simultaneously defined in one preprocessing translation unit, but it
might choke on a translation unit in which all 4095 macro identifiers
are 63 characters long.

I don't believe that was the intent to forbid tihs.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

jameskuyper@verizon.net wrote:I've heard that from the comp.std.c crowd too,
but it doesn't make any sense to me.

I can translate and execute "int main(void) {return 0;}" myself.
How was that?
Want to see me do it again?

It makes more sense to me that a conforming implementation
should be able to translate and execute any strictly conforming program,
but people whom I consider to be more knowledgable about C than I am,
don't agree with me.

--
pete

re: Environmental limits

Harald van Dijk wrote:You left out the part that matters.

It's not what the software did, that determines
whether or not it's a conforming C implementation,
it's what the software is able to do, that determines
whether or not the software is a conforming C implementation.

5.2.4.1 Translation limits

[#1] The implementation shall be able to translate and
execute at least one program that contains at least one
instance of every one of the following limits:

"shall be able to"

A conforming C implementation is running software
that can translate and execute a C program.
If software did translate and execute a C program,
then it was a conforming implementation,
but if it can't do it again,
then it isn't a conforming implementation anymore.

It's not whether or not you were breathing
that determines whether or not you are alive,
it's whether or not you are going breathe again
that determines whether or not you are alive.

--
pete

re: Environmental limits

pete <pfiland@mindspring.comwrites:[...][...]The problem is that implementations have capacity limitations. A
compiler might run out of memory, or overflow some internal data
structure, while compiling some very large or very complex program
unit -- even if that program happens to be strictly conforming.

It's nearly impossible to give an exact specification of what programs
all compilers must be able to handle without running into capacity
limitations. So what the standard does instead is specify that there
must be *one* very large and complex program (which can be different
for each implementation) that the compiler can handle. This is
intended to prevent implementers from claiming conformance while
reporting capacity failures for anything bigger than "hello, world".

Generally the easiest way to satisfy the "one program" requirement
*and* create a compiler that's actually useful is to impose no fixed
limits, allocating resources within the compiler dynamically as
they're needed to deal with the size and complexity of the program
being compiled.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

On Aug 29, 4:13 am, pete <pfil...@mindspring.comwrote:

<snip>
But if you have breathen once, you were alive once, and perhaps that
was the point of those who talked about conforming implementations
being able to translate main return 0.

re: Environmental limits

Keith Thompson wrote:If a computer doesn't have the resources
to translate and execute a C program,
then you can't have a conforming C implementation
on that computer.

--
pete

re: Environmental limits

vippstar@gmail.com wrote:The point being discussed is:
What are the requirements for a conforming C implementation?

--
pete

re: Environmental limits

pete wrote:....It's a mistake to expect it to make sense :-), at least in any obvious
way. The reasons why these things were written the way that they are
involve a lot of considerations that are not immediately obvious.
The point is that this is NOT what the standard says. What the standard
says about strictly conforming programs is only that they must be
accepted (4p6). It does not say that they must be translated and
executed correctly. The standard doesn't define the meaning of "accept"
in this context. The ordinary English meaning of the word does not imply
translation and correct execution. It doesn't imply anything active at
all, in ordinary English, "acceptance" is practically the textbook
example of inactivity.

The only program that a conforming program is required to translate and
correctly execute is the "one program" whose existence is mandated by
the translation limits clause (5.2.4.1p1).

It has been argued that "accepted" should be interpreted as equivalent
to "translated and executed correctly" but that leads to the question of
why the word "accepted" was not used in both contexts.

I don't approve of this state of affairs. I think that there should be
some conformance category defined more loosely than "strictly
conforming", but more restricted than "conforming". I think that the
standard should mandate "translation and correct execution" of any
program in that intermediate conformance category.

However, there are serious problems with making that work, and I can
understand why it hasn't been done yet. The basic problem is that it is
very difficult to formulate limits in a portable fashion, such that
every program satisfying those limits can be compiled by every existing
implementation of C. The translation limits listed in section 5.2.4.1
would not be acceptable for this purpose; it's possible to create
programs that would impossible for a great many implementations to
translate, without violating a single one of those limits.

re: Environmental limits

pete wrote:....If it doesn't have the resources to translate and execute ANY C program,
you are correct. However, the standard only requires that a conforming
implementation possess enough resources to translate and execute a
single program, of the implementor's choice, which has to meet certain
requirements.The most serious constraint that this requirement places on
a conforming implementation is that this "one program" is necessarily
very long and complicated - so the implementation must be able to read
and process a program that long and complicated. However, once it's been
translated, a program meeting those requirements could have required
behavior equivalent to "int main(void) { return 0;}", so the semantic
requirements on a conforming implementation are not very strong.

re: Environmental limits

pete wrote:
....Not as many as you might think:
1. Rejection of programs that contain a #error directive that survives
conditional compilation.
2. Issuance of at least one diagnostic message for every program that
contains a syntax error or a constrain violation. This requirement can
be met by a diagnostic message that is ALWAYS generated, regardless of
whether there is a syntax error or constraint violation.
3. Acceptance of all strictly conforming programs not covered by item 1.
This can be met by accepting ALL programs not covered by item 1.
4. Translation and correct execution of ONE program, chosen by the
implementor, meeting certain rather lax requirements.

Anything more than that is strictly a QoI issue. In the real world, QoI
is a very important issue.

re: Environmental limits

James Kuyper wrote:You're one of those people.
I have argued that.
That's what I've read around here before.
If that's the case, then I would rather think
that there are no conforming C implementations.

My MSVC compiler isn't conforming.
It thinks (sizeof &array) is the same as (sizeof array):

/* BEGIN aname.c */

#include <stdio.h>

int main(void)
{
char array[] = {1};

puts("\n/* BEGIN output aname.c */");
puts("\nchar array[] = {1};\n");
printf(
"sizeof(char (*)[1]) is %lu\n"
"sizeof(&array) is %lu\n"
"sizeof( array) is %lu\n",
(long unsigned)sizeof(char (*)[1]),
(long unsigned)sizeof(&array),
(long unsigned)sizeof( array)
);
puts("\n/* END output aname.c */");
return 0;
}

/* END aname.c */



and it also won't compile:
int main(void) {int zero = 0; return zero && (1 / 0);}

--
pete

re: Environmental limits

On Aug 29, 5:47 am, pete <pfil...@mindspring.comwrote:

<snip>
Well, that's old news :P
I'm curious - what is the output?
AFAIK it also compiles unsigned long double, or something like that. I
remember a post from mr Navia mentioning this.

re: Environmental limits

vippstar@gmail.com wrote:/* BEGIN output aname.c */

char array[] = {1};

sizeof(char (*)[1]) is 4
sizeof(&array) is 1
sizeof( array) is 1

/* END output aname.c */


--
pete

re: Environmental limits

pete <pfiland@mindspring.comwrites:[...]Which C program are you referring to? Or do you mean *all* C
programs?

If a compiler fails to compile a program with a trillion levels of
nested if statements, would you say that compiler is non-conforming?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

pete <pfiland@mindspring.comwrites:
[...][...]

How old is it?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

Keith Thompson wrote:I was refering to a strictly conforming C program.
That would be the test of a conforming C implementation.
Yes.
What problem is a trillion nested if statements supposed to cause?

--
pete

re: Environmental limits

Keith Thompson wrote:11 years.

--
pete

re: Environmental limits

pete wrote:....You should say so explicitly when that is what you mean. Most real-
world C programs are not strictly conforming, so the term "C program"
does not normally, in itself, convey that implication.
It's not a test that the C standard requires a conforming C
implementation to pass.
insufficient storage space for whatever structures the compiler needs
to create for each nested if statement. There are very few (if any)
real-world implementations that could even deal with a million of
them, much less a trillion. The "one program" is only required to have
127 levels of nested blocks.

re: Environmental limits

jameskuyper@verizon.net wrote:Yes, I should have.
What is the point of the standard defining what a strictly
conforming program is?
How is that information supposed to be used?
You can have a trillion nested if statements
without any nested blocks.

--
pete

re: Environmental limits

pete wrote:....It was intended to be a useful conformance category. The intent wasn't
completely achieved. The only thing the standard promises with respect
to strictly conforming code is that it must be accepted, but the
standard fails to identify what that means.

There's also a tricky issue with respect to implementation limits.
Strictly conforming code may not exceed any minimum implementation
limit. This is a bit mysterious: why should exceeding a MINimum limit
be a problem?

It's been argued that the minimum implementation limits that strictly
conforming code must not exceed are those listed in 5.2.4.2. This
conveniently resolves the mystery; those numbers are the minimum value
required for an implementation, but a maximum value for code compiled
by that implementation.

The problem with this argument, aside from the fact that the phrase
"implementation limit" appears nowhere in section 5, is the fact that
strictly conforming code could be written which was arbitrarily
difficult to translate and execute correctly, without exceeding any of
those limits. As a result, very few, if any, compilers are currently
capable of correctly translating and executing all such programs.
Making translation and execution of all strictly conforming code
mandatory would render most (and possibly all) implementations non-
conforming.

Despite it's limitations, "strictly conforming" is the strictest code
conformance category defined by the standard, and the only useful code
conformance category it defines, so as a practical matter the term
gets used even in contexts where its limitations should be a problem.

....The standard uses the term "selection statement" to refer to both if
statements and switch statements.
Section 6.8.4p3 says "A selection statement is a block whose scope is
a strict subset of the scope of its
enclosing block. Each associated substatement is also a block whose
scope is a strict subset of the scope of the selection statement."

re: Environmental limits

jameskuyper@verizon.net wrote:For instance
int main(int argc,char *argv[])
{
int a = argc;

if (a == 1 ||
a == 2 ||
a == 3 ||
/ ... skip 4765 similar lines */
a == 4766) {
return -1;
}
return 0;
}

lcc-win crashes with stack overflow at (if I remember
correctly) 4765. Gcc crashes at a slightly higher value, I
do not remember exactly how much.

This was generated code of course. And I could NOT find
anything in the standard that sets a limit to that.


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

re: Environmental limits

pete <pfiland@mindspring.comwrites:It's not the *only* test. An implementation that rejects all programs
that aren't strictly conforming cannot be a conforming implementation.
For example this program:

#include <stdio.h>
#include <limits.h>
int main(void)
{
printf("INT_MAX = %d\n", INT_MAX);
return 0;
}

clearly is not strictly conforming, but C99 4p3 says:

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.
Running out of memory and/or other resources during compilation.

It would be unreasonable for the standard to require implementations
to handle such huge programs. Unfortunately, it's a bit vague about
what conforming implementations are allowed to do in the presence of
huge programs.

The Ada standard covers this pretty well, with about the right amount
of necessary vagueness:

This International Standard does not specify:

-- [...]

-- The size of a program or program unit that will exceed the
capacity of a particular conforming implementation.

[...]

A conforming implementation shall:

-- Translate and correctly execute legal programs written in Ada,
provided that they are not so large as to exceed the capacity
of the implementation;

-- Identify all programs or program units that are so large as to
exceed the capacity of the implementation (or raise an
appropriate exception at run time);

[...]

If the C standard has similar wording, we probably wouldn't be having
this discussion.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

re: Environmental limits

On Aug 28, 7:36 pm, James Kuyper <jameskuy...@verizon.netwrote:So the following is a conforming, albeit very low-quality,
implementation? Written in Perl just for the hell of it.

#! /usr/bin/perl
while (<>) {
die "Error!" if (/^[ \t]*#[ \t]*error/);
}
warn("Warning: your program might contain an error.");
print "#! /bin/sh\nexit 0\n";

The output is a program that does nothing except return 0. So now I
just have to come up with a complicated program that meets the given
requirements and contains no #error lines, but does nothing except
return 0; my implementation will correctly compile it. Then I'll be
done. Amusing.

(Note: programs that contain #error lines that are #if'ed out will
also be rejected by this, but that seems to be okay.)

Given this, it's not clear to me why the standard authors bothered to
include these requirements, since they're trivially satisfied by
implementations that bear no resemblance to C.

re: Environmental limits

fjbl...@yahoo.com wrote:No - the fact that you have to determine whether or not the #error
directive survives conditional compilation means that you actually
have to implement conditional compilation correctly. That implies that
you'll have to implement all of the other pre-processing directives
correctly, as well. That, in turn, means that you have to correctly
implement translation phases 1-3.

Second problem: your "implementation" translates programs for which
the standard requires behavior which does not match that produced by
your executable output file. A conforming implementation could handle
this case correctly but in a useless fashion by accepting such
programs, but NOT translating them. The only program a conforming
implementation is required to translate and execute correctly is its
"one program".
No, it is not. Strictly conforming code can contain a #error directive
that fails to survive conditional compilation. Such code must be
accepted, not rejected.
They didn't intend that such an implementation should qualify; they
just ran into problems reaching any agreement on more restrictive
requirements. Anything that looks like it should be a simple fix to
this actually has much more complicated issues than you might expect.

re: Environmental limits

jameskuyper@verizon.net wrote:You don't find "correct program" to be as useful?
I was thinking in terms of C90 definitions,
and being unclear by not specifying that.

In C90, selection statements are not defined in terms of blocks.

--
pete

re: Environmental limits

pete wrote:....That could be a useful category, and close to what I want, except for
the fact that the guarantees associated with it by the standard are
inadequate. An implementation is not required to even accept correct
programs, much less translate and execute them correctly. The only
clause that uses the term (4p3) serves solely to clarify that
"unspecified behavior" is not a license for violating the other
requirements of the standard.

....I don't have a copy of the C90 standard; while I was interested in it,
it was way too expensive. By the time that inexpensive copies could be
legally obtained, I was no longer interested in the C90 standard.