antispam@fricas.org (Waldek Hebisch) writes:

[...] for some time there was a belief that correct and full BNF
for C was impossible to give or too messy.

I find this statement hard to believe. There is nothing especially
difficult about a syntax for the C language. There is of course the
well-known problem with typedef names, but that has long been
understood to be unresolvable in any context-free way (and so cannot
be dealt with in BNF). Earlier versions of C (pre-K&R) had other
syntax for some constructs, and maybe that was the issue. I'm at a
loss to understand how people could have thought a BNF for C, for
the post K&R version of the language, would be challenging or
difficult.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

antispam@fricas.org (Waldek Hebisch) writes:

[...] for some time there was a belief that correct and full BNF
for C was impossible to give or too messy.

I find this statement hard to believe. There is nothing especially
difficult about a syntax for the C language. There is of course the well-known problem with typedef names, but that has long been
understood to be unresolvable in any context-free way (and so cannot
be dealt with in BNF). Earlier versions of C (pre-K&R) had other
syntax for some constructs, and maybe that was the issue. I'm at a
loss to understand how people could have thought a BNF for C, for
the post K&R version of the language, would be challenging or
difficult.

I'm having trouble figuring out what you mean here. You acknowledge
that typedefs make a full BNF grammar for C impossible, and then
you say that it's not challenging or difficult.

I'm aware that there are workarounds, basically treating typedef
names a context-dependent keywords.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

antispam@fricas.org (Waldek Hebisch) writes:

[...] for some time there was a belief that correct and full BNF
for C was impossible to give or too messy.

I find this statement hard to believe. There is nothing especially
difficult about a syntax for the C language. There is of course the
well-known problem with typedef names, but that has long been
understood to be unresolvable in any context-free way (and so cannot
be dealt with in BNF). Earlier versions of C (pre-K&R) had other
syntax for some constructs, and maybe that was the issue. I'm at a
loss to understand how people could have thought a BNF for C, for
the post K&R version of the language, would be challenging or
difficult.

I'm having trouble figuring out what you mean here. You acknowledge
that typedefs make a full BNF grammar for C impossible, and then
you say that it's not challenging or difficult.

Because I think the problem with typedef names is orthogonal to
what Waldek was saying. The problem with typedef names is not
solvable in a context-free grammar, and that is just as true today
as it was 50 years ago. The syntax I am talking about is C syntax
without regard to the problem with typedef names.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

antispam@fricas.org (Waldek Hebisch) writes:

[...] for some time there was a belief that correct and full BNF
for C was impossible to give or too messy.

I find this statement hard to believe. There is nothing especially
difficult about a syntax for the C language. There is of course the
well-known problem with typedef names, but that has long been
understood to be unresolvable in any context-free way (and so cannot
be dealt with in BNF). Earlier versions of C (pre-K&R) had other
syntax for some constructs, and maybe that was the issue. I'm at a
loss to understand how people could have thought a BNF for C, for
the post K&R version of the language, would be challenging or
difficult.

I'm having trouble figuring out what you mean here. You acknowledge
that typedefs make a full BNF grammar for C impossible, and then
you say that it's not challenging or difficult.

Because I think the problem with typedef names is orthogonal to
what Waldek was saying. The problem with typedef names is not
solvable in a context-free grammar, and that is just as true today
as it was 50 years ago. The syntax I am talking about is C syntax
without regard to the problem with typedef names.

I still don't understand your point. A "C syntax without regard
to the problem with typedef names" would not be a correct C syntax
(unless it's for a pre-typedef version of the language).

Typedef names aren't a huge problem, but they're something that has
to be dealt with in a non-trivial way if you want to use something
close to a BNF grammar.

When I read Waldek's statement that "and for some time there was a
belief that correct and full BNF for C was impossible to give or
too messy", I assumed that the typedef issue was exactly what he
was talking about. Perhaps I was mistaken, but I don't know of
any other reason to think that a full BNF for C would be thought
to be impossible, and I think you're saying you don't know of any
such reason either.

Whatever Waldek meant, I think you and I are in agreement that (a)
a full BNF grammar for C is impossible because of the typedef issue,
but (b) the typedef issue can be worked around without too much
difficulty, using something reasonably close to a full BNF grammar.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

antispam@fricas.org (Waldek Hebisch) writes:

[...] for some time there was a belief that correct and full BNF
for C was impossible to give or too messy.

I find this statement hard to believe. There is nothing especially
difficult about a syntax for the C language. There is of course the
well-known problem with typedef names, but that has long been
understood to be unresolvable in any context-free way (and so cannot
be dealt with in BNF). Earlier versions of C (pre-K&R) had other
syntax for some constructs, and maybe that was the issue. I'm at a
loss to understand how people could have thought a BNF for C, for
the post K&R version of the language, would be challenging or
difficult.

I'm having trouble figuring out what you mean here. You acknowledge
that typedefs make a full BNF grammar for C impossible, and then
you say that it's not challenging or difficult.

Because I think the problem with typedef names is orthogonal to
what Waldek was saying. The problem with typedef names is not
solvable in a context-free grammar, and that is just as true today
as it was 50 years ago. The syntax I am talking about is C syntax
without regard to the problem with typedef names.

I still don't understand your point. [...]

Yes, I can see that.

By the way, it wasn't a point, it was only an explanation. I'm
sorry that it wasn't more understandable for you.

--- PyGate Linux v1.5.14
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

antispam@fricas.org (Waldek Hebisch) writes:
[...]

If you ask "how does it work?", the answer is that parsers using
that where shift-reduce parsers and priorities are used to choose
between shift and reduce actions. People also realised to
operator precedence can be used together with recursive descent,
leading to small and efficient parsers handling rich language.
Operator precedence alone puts restrictions on the language
(but there were languages specially designed to be parsed using
operator precedence), recursive descent alows more general
languages, but gets messy on constructs well handled by operator
precedence. AFAIK first C compiler used combination of operator
precedence and recursive descent, and for some time there was a
belief that correct and full BNF for C was impossible to give or
too messy. Current gramamr only appeared during ANSI process.

You say that it was believed that a full BNF for C was "impossible
to give or too messy". Can you expand on that and/or provide
a citation?

The only problem in that area that I'm aware of is "typedef",
but that was a later addition (some time between 1975 and 1978).

What exactly did you mean?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86pl2yi0n3.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

[...]

My main point is that "byte" and "octet" are talking about
different kinds of things.

Not really. It has always been understood to refer to the same
kind of thing that "byte" refers to.

I agree, at least for the way I understand the terms. For me,
"octet" and "byte" refer to the same kind of thing. [...]

An octet is a quantity of information. An octet can be stored in
a computer memory, transmitted over a network wire, shown on a
movie screen, sent in a text message, or written on a piece of
paper.

In C, a byte is an addressable unit of data storage large enough
to hold any member of the basic character set of the execution
environment. There was slightly different wording in the original
C standard, but since C99 the definition has stayed the same up to
the present (specifically, n3220).

If someone wants to use the term "byte" in a C program to mean
something other than the above definition, there is nothing
stopping them from doing so, but it comes with a risk of ambiguity
and confusion. A safer path is to follow the suggestion given by
many people familiar with the C standard, which is to use terms
defined in the C standard in the same way that they are used in
the standard.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Bart <bc@freeuk.com> writes:

[...]

I don't think what you said helped anyone.

Perhaps not. I daresay the percentage of my postings that some
other people find helpful is higher than yours.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86ecjkshx0.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

Examples of statically typed languages include SML, Haskell,
Rust, etc. Those are also all strongly typed.

Rust is not generally considered to be strongly typed.

By whom?

Rust has
raw pointers and unsafe functions, both of which (can) violate
type safety.

That is orthogonal to whether or not it the language is strongly
typed.

Perhaps you meant memory safety? In which case it is worth
stating that the langauge only guarantees memory safety for the
safe subset.

Dereferencing a raw pointer, including for assignment through
that pointer, can only be done in an `unsafe` block. Unsafe
functions have no _a priori_ bearing on memory (let alone type)
safety; they only impose the requirement that they must be
called from from an `unsafe` block.

Using the `unsafe` language requires using an `unsafe` block,
even in a function marked `unsafe` (admitted, this did change
from earlier editions of the language).

There is something I would say here, but I am reminded that my
remarks would be off topic, so I simply going to stop. My
apologies for my earlier off-topic post upthread.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

In article <86v7c1dhs5.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <86ecjkshx0.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

Examples of statically typed languages include SML, Haskell,
Rust, etc. Those are also all strongly typed.

Rust is not generally considered to be strongly typed.

By whom?

Rust has
raw pointers and unsafe functions, both of which (can) violate
type safety.

That is orthogonal to whether or not it the language is strongly
typed.

Perhaps you meant memory safety? In which case it is worth
stating that the langauge only guarantees memory safety for the
safe subset.

Dereferencing a raw pointer, including for assignment through
that pointer, can only be done in an `unsafe` block. Unsafe
functions have no _a priori_ bearing on memory (let alone type)
safety; they only impose the requirement that they must be
called from from an `unsafe` block.

Using the `unsafe` language requires using an `unsafe` block,
even in a function marked `unsafe` (admitted, this did change
from earlier editions of the language).

There is something I would say here, but I am reminded that my
remarks would be off topic, so I simply going to stop. My
apologies for my earlier off-topic post upthread.

No, I think you should say it. The contrast was explicitly with
C, which is widely acknowledged to be weakly typed, and of
course C is relevant and on-topic.

Rust, by every definition I am aware of, is strongly typed. I
have never before heard the assertion that it is not. If you
are aware of some serious dissenting view, since you said that
"Rust is not generally considered to be strongly typed", then
you should provide a reference. The topicality is that it helps
to frame the discussion with respect to strong and weak typing
and how those intersect with C.

- Dan C.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 3 May 2026 00:30:01 -0000 (UTC), antispam@fricas.org (Waldek
Hebisch) wrote:

Bart <bc@freeuk.com> wrote:

[about overflow]

I tried another experiment with printing the result of 2 * 2000000000 across several languages. All these printed -294967296:

C#
D
Java
Fortran
Kotlin

(All run from rextester.com.) These also printed an overflowed result:

That's only one Fortran implementation, and quite possibly a
particular mode of it. Fortran the language, like C, does not define
this, and I have used multiple implementations that DID trap for
integer overflow, sometimes depending on what options you used. And
since Fortran was designed and mostly used for applications where
correct numerical results are important, most Fortran programmers, and
shops, preferred this. Most, not all.

Java OTOH does define wrapping, and Kotlin is mostly syntax sugar for
Java so it adopts that.

In the days when c.l.fortran was almost as active as c.l.c now -- over
5 years ago for sure, probably over 10 -- their equivalent of nasal
demons, i.e. canonical example for (unintended) use of something
nonstandard, was 'starts World War III'. Given some of the application
domains in which Fortran was popular, especially in earlier decades,
that came closer to realism than I think most people want(ed).

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)