Re: for or against equality, was Why are ambiguous grammars usually a bad idea?

David Brown <>
Thu, 6 Jan 2022 09:11:29 +0100

          From comp.compilers

Related articles
Re: what is defined, was for or against equality (Thomas Koenig) (2022-01-06)
Re: what is defined, was for or against equality (David Brown) (2022-01-07)
Re: what is defined, was for or against equality (Spiros Bousbouras) (2022-01-07)
Undefined behaviour, was: for or against equality (Martin Ward) (2022-01-07)
Re: Undefined behaviour, was: for or against equality (David Brown) (2022-01-07)
Re: Undefined behaviour, was: for or against equality (Spiros Bousbouras) (2022-01-08)
Re: what is defined, was for or against equality (Thomas Koenig) (2022-01-08)
[16 later articles]
| List of all articles for this month |

From: David Brown <>
Newsgroups: comp.compilers
Date: Thu, 6 Jan 2022 09:11:29 +0100
Organization: A noiseless patient Spider
References: <> 22-01-016
Injection-Info:; posting-host=""; logging-data="22569"; mail-complaints-to=""
Keywords: design
Posted-Date: 06 Jan 2022 10:49:10 EST
In-Reply-To: 22-01-016
Content-Language: en-GB

On 05/01/2022 11:25, Martin Ward wrote:

> Using a language that you don't know in its entirety might seem
> dangerous, but everybody seems to do it these days:
> how many C programmers have read the entire 500+ pages of
> the latest C standard and memorised the 200+ varieties
> of "undefined behaviour" so that they can avoid all of them
> in every line of code that they write?

I think it is normal not to know everything about the language you use.
  And if you include the language's standard library, then there are very
few currently used languages where it would even be possible to learn it
all. By the time you learned all of the language and default libraries
of C++, Java, Python, etc., there would be a new version out and you'd
have more to learn.

The important things for writing code are to know enough to be able to
write the kind of code you are doing, and to avoid accidentally doing
things you didn't intend. Static warning tools are vital here - from
syntax-highlighting and check-as-you-type editors and IDE's, through
compiler warning flags, to stand-alone checkers. Your tools should
tell you if you are accidentally using a reserved word as an

There is no need to memorize undefined behaviours for a language -
indeed, such a thing is impossible since everything not defined by a
language standard is, by definition, undefined behaviour. (C and C++
are not special here - the unusual thing is just that their standards
say this explicitly.)

The trick is to memorize the /defined/ behaviours, and stick to them.
You generally don't need to know if a language leaves (1 / 0) as
undefined, or gives a specific value, or prints an error message -
usually it is sufficient to know the values for which (x / y) /is/
defined, and stick to those values.

Basically, trying to execute undefined behaviour is no more and no less
than a bug in the program - whether it is "undefined" in terms of the
language, the library, the code you wrote yourself, the customer's
specification, or anything else. People program primarily by trying to
write correct code - not by trying to think of all the ways they could
write incorrect code!

The real challenge from big languages and big standard libraries is not
/writing/ code, it is /reading/ it. It doesn't really matter if a C
programmer, when writing some code, does not know what the syntax "void
foo(int a[static 10]);" means. (Most C programmers don't know it, and
never miss it.) But it can be a problem if they have to read and
understand code that uses something they don't know.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.