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)

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

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

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

[..I am summarizing parts in an effort to get to key aspects..]

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

[snip]
It's important to understand the perspectives of different groups
of participants in the C ecosystem. There are three main groups:

If you're a programmer, you hate undefined behavior, and avoid it
like the plague.

If you're a compiler writer, you love undefined behavior, because
it lets you do whatever you want.

If you're a member of the ISO C standards committee (and I admit
that to a degree I am speculating here), you think of undefined
behavior as a balancing test, of needing to weigh the tensions
inherent in what the first two groups would prefer.

This, I think, is the tragedy of C ("tragedy" in the dramatic,
Shakespearean sense).
[long exposition on the history of C]

My point here is that the users and developers of the language
were the same group, [elaboration]

But, as you pointed out, this is no longer the case. The two are
now distinct, with very different goals. [a consequence of which
is C usage is less uniform (my paraphrase)]

Here, I was referring to the _groups you defined_.

I think this is fair: pretty much no production OS is written in
pure ISO C, if they're written in C at all: they all use compiler
flags or custom toolchains to enable various extensions and pin
down aspects of UB they depend on in one form or another.

And this is the tragedy. This isn't how it started, and I don't
think the folks who created the language wanted it to go down this
way, but here we are. [rest omitted]

I wouldn't call it a tragedy, in fact just the opposite.

The tragedy I alluded to is that precisely the difference
between two groups you yourself suggested: programmers hate UB,
compiler writers love it. The compiler writers and programmers
often appear to have an antagonistic relationship.

If C had
stayed in its original environment it never would have become as
ubiquitous and widespread as it is today. The original ecosystem
doesn't scale. By letting C, and also Unix, enter the public
sphere, a great benefit accrued to the world at large.

I said as much.

[snip] Moreover such non-standard
language usages are not limited to C -- the Rust language is also
used in the linux kernel, and there too some non-standard language
features are used in kernel code.

Rust has no language standard, so saying that "non-standard
language features are used in kernel code" is incorrect.

I don't mean to compare C and Rust. My position here is only that,
in my view, the complaints raised about C are misplaced. Others
are welcome to their own views on the subject.

I don't think you read my note carefully, and your response is
to something I did not say.

It may be that I didn't understand what you were trying to get
at. But I did read your postings carefully, both the earlier
one I responded to before and the one I am replying to now.

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