What does "ill-formed" mean?

[Juha Nieminen]

Seems like a relatively simple question, but I couldn't find clear
answers. The standard mentions a lot the notion of something being
"ill-formed", but it's not clear to me what exactly that means, and
especially how it's different from undefined behavior or implementation
defined.

(The closest thing I could find is that if something is "ill-formed"
a diagnostic from the compiler is required. Except that doesn't always
seem to be the case either...)

[Ben Bacarisse]

My starting point would be the definitions at the start of the
standard. (Sorry if that's obvious.)

1.3.9
ill-formed program
program that is not well formed

1.3.26
well-formed program
C ++ program constructed according to the syntax rules, diagnosable
semantic rules, and the One Definition Rule (3.2).

Does this not fit all the situations you are seeing? It does match,
pretty well, what you said was the closest thing you could find (so it's
probably what yo are starting from too) but you did not say what the
exceptions were so I can't be sure.

--
Ben.

[Öö Tiib]

The diagnostic is required for ill-formed program unless standard
explicitly states that diagnostic is not required in particular
situation. As for the difference between "ill-formed; no diagnostic
required" and "undefined behavior", there isn't any to my knowledge.

I suspect the inconsistency is because some authors of standard did
think that all errors are undefined behavior unless said otherwise
and others that all errors require diagnostic unless said otherwise.
Both schools of language lawyers have otherwise tried to be as explicit
as they can.

[Juha Nieminen]

Ben Bacarisse <ben.u...@bsb.me.uk> wrote:
> 1.3.9
> ill-formed program
> program that is not well formed
>
> 1.3.26
> well-formed program
> C ++ program constructed according to the syntax rules, diagnosable
> semantic rules, and the One Definition Rule (3.2).
>
> Does this not fit all the situations you are seeing? It does match,
> pretty well, what you said was the closest thing you could find (so it's
> probably what yo are starting from too) but you did not say what the
> exceptions were so I can't be sure.

Is an out-of-bounds access ill-formed? It's certainly UB.

Accessing an array out of bounds is certainly not a syntactic error,
nor a diagnosale semantic error (afaik).

[Ben Bacarisse]

1.4 Implementation compliance

1 The set of diagnosable rules consists of all syntactic and semantic
rules in this International Standard except for those rules containing
an explicit notation that “no diagnostic is required” or which are
described as resulting in “undefined behavior.”

Since I imagine that out-of-bounds access is described as resulting in
undefined behaviour, either explicitly or implicitly through a violated
"shall", it does not result in the program being ill-formed.

(I'm not as familiar with the C++ standard as I am with the C one so I
am feeling my way here.)

--
Ben.

[james...@alumni.caltech.edu]

On Sunday, September 9, 2018 at 6:35:34 AM UTC-4, Ben Bacarisse wrote:
...

> Since I imagine that out-of-bounds access is described as resulting in
> undefined behaviour, either explicitly or implicitly through a violated
> "shall", it does not result in the program being ill-formed.
>
> (I'm not as familiar with the C++ standard as I am with the C one so I
> am feeling my way here.)

The two standards say this is pretty much the same way:

Re: pointer + integer:
"If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object, the
evaluation shall not produce an overflow; otherwise, the behavior is
undefined. If the result points one past the last element of the array
object, it shall not be used as the operand of a unary * operator that
is evaluated." (C 6.5.6p8).

"If both the pointer operand and the result point to elements of the
same array object, or one past the last element of the array object, the
evaluation shall not produce an overflow; otherwise, the behavior is
undefined." (C++ 5.7p4)

However, the last sentence of the C 6.5.6p8 doesn't seem to have a
corresponding clause in the C++ standard, which surprises me.