If you want to make C a safer language, one obvious thing is to disallow
using “=” in the middle of an expression. Instead of returning the value
of the expression, have it return void. Or just disallow it syntactically
altogether.

Sure, you may still want to write something like

a = b = c;

but Python has found a way to allow that, without saying that “b = c” has
to return a value.

On 09/02/2024 00:39, Lawrence D'Oliveiro wrote:
> If you want to make C a safer language, one obvious thing is to disallow
> using “=” in the middle of an expression. Instead of returning the value
> of the expression, have it return void. Or just disallow it syntactically
> altogether.
>
> Sure, you may still want to write something like
>
> a = b = c;
>
> but Python has found a way to allow that, without saying that “b = c” has
> to return a value.

while( (ch = fgetc(fp)) != EOF)

is the idiomatic way of accessing a stream a character by character in
C. So you would disallow this.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-02-09, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> If you want to make C a safer language, one obvious thing is to disallow
> using “=” in the middle of an expression. Instead of returning the value
> of the expression, have it return void. Or just disallow it syntactically
> altogether.
>
> Sure, you may still want to write something like
>
> a = b = c;
>
> but Python has found a way to allow that, without saying that “b = c” has
> to return a value.

Python's original solution is stupid. All they had to do is to use :=
for assignment, and leave = as a comparison.

.... and that's what they did now, as of Python 3.8.

There is a := assignment that can be used in the middle of an
expression. This is given the idiotic nickname "walrus operator".

:= can be used in the middle of expressions.

Except they can't drop the old = assignment due to backward
compatibility.

Walrus is what should have been assignment in the first place.
But because Van Possum was coding Python in C, he just aped
some C choices into the language.

(I'm guessing that he knew that the first people to get their hands on
Python and popularize it would be C-and-Unix people, who would
balk at a := operator.)

By the way, assignment in the middle of expressions comes from Lisp.
Basically the idea that everything is an expression, even things
that perform side effects or behave like statements. The ternary
operator comes from Lisp: (if expr then else).

[CLISP]
[1]> (let ((i 0)) (list (incf i) (incf i) (incf i)))
(1 2 3)

You're unlikely to type setf or incf when you wanted a comparison.
ANSI Common Lisp is strictly evaluated so the above is required
to produce (1 2 3) and not (2 1 3) or whatever. Stuffing side
effects into Lisp expressions is less risky than in C.

(Not so with Scheme: in Scheme, the evaluation order of function
arguemnts is unspecified, like in C!)

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On Fri, 9 Feb 2024 00:53:42 +0000, Malcolm McLean wrote:

> while( (ch = fgetc(fp)) != EOF)
>
> is the idiomatic way of accessing a stream a character by character in
> C. So you would disallow this.

Yes!

On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
> If you want to make C a safer language, one obvious thing is to disallow
> using “=” in the middle of an expression. Instead of returning the value
> of the expression, have it return void. Or just disallow it syntactically
> altogether.
>

I think that C would have been a safer language if assignment had been a
statement, not an expression (such as is the case in Pascal, for
example). But I don't think it is remotely feasible to change this in C
- you are fifty years too late.

The nearest you can come to changes like this in C would be optional
warnings or checks in compilers and static analysers.

David Brown <david.brown@hesbynett.no> writes:

> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>> If you want to make C a safer language, one obvious thing is to disallow
>> using “=” in the middle of an expression. Instead of returning the value
>> of the expression, have it return void. Or just disallow it syntactically
>> altogether.
>
> I think that C would have been a safer language if assignment had been a
> statement, not an expression

Surely someone has studied this, no? There must be some paper
describing bugs "in the wild"* and categorising them by what language
features would have made them either impossible or less likely. I don't
know of any (it was not even remotely my field) but there is such a
large pool of data out there I can't imagine that it's not been done.

* I mean to exclude bugs that get found early. For example, I've never
seen a = vs. == bug that survived even the most crude tests (and most,
like many other typo bugs, don't survive compilation without being
picked up).

--
Ben.

On 09/02/2024 10:16, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>> If you want to make C a safer language, one obvious thing is to disallow
>>> using “=” in the middle of an expression. Instead of returning the value
>>> of the expression, have it return void. Or just disallow it syntactically
>>> altogether.
>>
>> I think that C would have been a safer language if assignment had been a
>> statement, not an expression
>
> Surely someone has studied this, no? There must be some paper
> describing bugs "in the wild"* and categorising them by what language
> features would have made them either impossible or less likely. I don't
> know of any (it was not even remotely my field) but there is such a
> large pool of data out there I can't imagine that it's not been done.
>
> * I mean to exclude bugs that get found early. For example, I've never
> seen a = vs. == bug that survived even the most crude tests (and most,
> like many other typo bugs, don't survive compilation without being
> picked up).
>

This is what ChatGPT says ...

User
Can you list C language bugs, categorising them by what language
features would have made them either impossible or less likely.

ChatGPT
Certainly! Here are some common bugs in C categorized by language
features that could have prevented them or made them less likely:

Null Pointer Dereference:
Language Feature: Safe pointer handling like in Rust or smart pointers
in C++. Features like optional nullability annotations or language
constructs that enforce non-null pointers can help prevent null pointer
dereference bugs.

Buffer Overflows:
Language Feature: Bounds checking in arrays. Languages like Rust have
built-in checks to prevent buffer overflows at compile-time.
Safe string handling functions like those provided by libraries such as
Safe C String Library (SCL) or SafeLib.

Memory Leaks:
Language Feature: Automatic memory management like garbage collection or
smart pointers. Languages like Java, C#, and modern C++ with RAII
(Resource Acquisition Is Initialization) significantly reduce the
occurrence of memory leaks.

Use After Free:
Language Feature: Automated memory management, such as garbage
collection, or ownership tracking systems like those found in Rust's
ownership model.

Uninitialized Variables:
Language Feature: Initialization guarantees or compiler warnings for
uninitialized variables. Tools like static code analyzers or compilers
with strong type checking can help detect such issues.

Type Safety Violations:
Language Feature: Strong static typing. Languages like Java, C#, or Rust
enforce stronger type safety, reducing the likelihood of type-related bugs.

Race Conditions:
Language Feature: Built-in support for concurrent programming paradigms,
such as message passing (e.g., Erlang) or ownership model (e.g., Rust),
or immutability (e.g., functional programming languages like Haskell).

Integer Overflows:
Language Feature: Safe arithmetic operations. Languages like Rust
provide safe arithmetic operations that panic on overflow, preventing
undefined behavior.

Resource Management Issues (e.g., File Handles, Sockets):
Language Feature: RAII (Resource Acquisition Is Initialization) or using
constructs like "defer" in Go. Languages like Rust with its ownership
model can enforce proper resource management.

Unprotected Access to Shared Resources:
Language Feature: Mechanisms for synchronization and concurrent access
control, such as locks, semaphores, or higher-level constructs like
channels in Go or message passing in Erlang.

Floating Point Precision Errors:
Language Feature: Enhanced floating-point arithmetic support or
arbitrary-precision arithmetic libraries. Languages like Python or
libraries like GNU MPFR provide arbitrary-precision arithmetic, reducing
precision errors.

Pointer Arithmetic Errors:
Language Feature: Restricted or controlled pointer arithmetic. Safe
pointer operations and bounds checking can prevent pointer arithmetic
errors.

By incorporating these language features or using languages with
built-in protections against common programming errors, developers can
significantly reduce the likelihood of encountering these bugs.

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 09/02/2024 10:16, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>>> If you want to make C a safer language, one obvious thing is to disallow
>>>> using “=” in the middle of an expression. Instead of returning the value
>>>> of the expression, have it return void. Or just disallow it syntactically
>>>> altogether.
>>>
>>> I think that C would have been a safer language if assignment had been a
>>> statement, not an expression
>> Surely someone has studied this, no? There must be some paper
>> describing bugs "in the wild"* and categorising them by what language
>> features would have made them either impossible or less likely. I don't
>> know of any (it was not even remotely my field) but there is such a
>> large pool of data out there I can't imagine that it's not been done.
>> * I mean to exclude bugs that get found early. For example, I've never
>> seen a = vs. == bug that survived even the most crude tests (and most,
>> like many other typo bugs, don't survive compilation without being
>> picked up).
>
> This is what ChatGPT says ...

Seriously? You do know how large language models work, yes?

--
Ben.

On 09/02/2024 11:16, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>> If you want to make C a safer language, one obvious thing is to disallow
>>> using “=” in the middle of an expression. Instead of returning the value
>>> of the expression, have it return void. Or just disallow it syntactically
>>> altogether.
>>
>> I think that C would have been a safer language if assignment had been a
>> statement, not an expression
>
> Surely someone has studied this, no? There must be some paper
> describing bugs "in the wild"* and categorising them by what language
> features would have made them either impossible or less likely. I don't
> know of any (it was not even remotely my field) but there is such a
> large pool of data out there I can't imagine that it's not been done.

I think it is very difficult to get good statistics on this kind of
thing. You can't really do a controlled study comparing one group
programming in "C where assignment is an expression" with a group
programming in "C where assignment is a statement". And you certainly
can't do a double-blind placebo controlled test!

There are plenty of coding standards which ban the use of the results of
assignment expressions, and I think there is little doubt that stricter
coding standards reduce at least some kinds of errors in code. But it
would be impossible to isolate the effect of one particular rule.

If someone knows about such studies, it would be great to hear about
them - failing that, guesses and gut feelings based on personal
experience is about as good as we can get.

>
> * I mean to exclude bugs that get found early. For example, I've never
> seen a = vs. == bug that survived even the most crude tests (and most,
> like many other typo bugs, don't survive compilation without being
> picked up).
>

I would agree with that.

However, I /have/ seen such bugs in code that has been written and
deployed, precisely because even the most crude tests and static
checking where not employed.

Far and away the biggest steps towards "safe C" is for people to use
good development practices, including good testing, good static error
checking, appropriate training, code reviews, etc. The unfortunate
reality is that there are many programmers who don't use such practices,
or don't use them correctly. And I don't think a change to how
assignment works would make a noticeable difference to this much larger
and more general problem.

On 09/02/2024 13:17, Ben Bacarisse wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
>
>> On 09/02/2024 10:16, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>>>> If you want to make C a safer language, one obvious thing is to disallow
>>>>> using “=” in the middle of an expression. Instead of returning the value
>>>>> of the expression, have it return void. Or just disallow it syntactically
>>>>> altogether.
>>>>
>>>> I think that C would have been a safer language if assignment had been a
>>>> statement, not an expression
>>> Surely someone has studied this, no? There must be some paper
>>> describing bugs "in the wild"* and categorising them by what language
>>> features would have made them either impossible or less likely. I don't
>>> know of any (it was not even remotely my field) but there is such a
>>> large pool of data out there I can't imagine that it's not been done.
>>> * I mean to exclude bugs that get found early. For example, I've never
>>> seen a = vs. == bug that survived even the most crude tests (and most,
>>> like many other typo bugs, don't survive compilation without being
>>> picked up).
>>
>> This is what ChatGPT says ...
>
> Seriously? You do know how large language models work, yes?
>

Sure: It has read the entire internet - especially the the bit about
how Rust is better than C, apparently - and regurgitates the same.

Considering my five seconds of effort; I didn't think it was /that/ bad
of a list.

On 09/02/2024 00:39, Lawrence D'Oliveiro wrote:
> If you want to make C a safer language, one obvious thing is to disallow
> using “=” in the middle of an expression. Instead of returning the value
> of the expression, have it return void. Or just disallow it syntactically
> altogether.
>
> Sure, you may still want to write something like
>
> a = b = c;
>
> but Python has found a way to allow that, without saying that “b = c” has
> to return a value.

I suspect that quite a number of existing programs will become invalid.

But what is the problem with 'a = b = c'? The real problems with
assignments inside expressions is when you accidentally use '=' instead
of '=='. That's due to a poor choice of syntax.

What I wouldn't care about banning however is this:

a += b += c;

Because it's just confusing. If you don't think so, consider a, b, c all
having different numerical types.

(It's also a bit of a pain when implementing a language that allows it.)

On 09/02/2024 16:43, bart wrote:
> On 09/02/2024 00:39, Lawrence D'Oliveiro wrote:
>> If you want to make C a safer language, one obvious thing is to disallow
>> using “=” in the middle of an expression. Instead of returning the value
>> of the expression, have it return void. Or just disallow it syntactically
>> altogether.
>>
>> Sure, you may still want to write something like
>>
>>      a = b = c;
>>
>> but Python has found a way to allow that, without saying that “b = c” has
>> to return a value.
>
>
> I suspect that quite a number of existing programs will become invalid.

Yes. It's not used often IME, and would be easy to fix, but you only
need it once in a program to make such a suggestion a breaking change.

>
> But what is the problem with 'a = b = c'?

My preference is to do one thing at a time - then it's clear what is
going on. I think it is rare that you could make use of such chained
assignment, and even rarer where you could reasonably argue that it is
clearer than simply writing two separate lines. (And when you use a
"declare variables when you are ready to initialise them" style, it is
much more natural to use two lines.)

About the only time when I think you might say that chained assignment
is clearer is for very closely related variables set to zero :

int x, y, z;
x = y = z = 0;

I would probably be happy to throw that clear usage out in order to stop
people making unclear usage of chained assignment.

> The real problems with
> assignments inside expressions is when you accidentally use '=' instead
> of '=='. That's due to a poor choice of syntax.
>

That's a non-issue for anyone who can use a compiler with static error
checking, because it is almost always easy to spot automatically.

> What I wouldn't care about banning however is this:
>
>     a += b += c;
>
> Because it's just confusing. If you don't think so, consider a, b, c all
> having different numerical types.

Agreed 100%.

(I hope that didn't shock you too much!)

On 2024-02-09, David Brown <david.brown@hesbynett.no> wrote:
> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>> If you want to make C a safer language, one obvious thing is to disallow
>> using “=” in the middle of an expression. Instead of returning the value
>> of the expression, have it return void. Or just disallow it syntactically
>> altogether.
>>
>
> I think that C would have been a safer language if assignment had been a
> statement, not an expression (such as is the case in Pascal, for
> example). But I don't think it is remotely feasible to change this in C
> - you are fifty years too late.

It was probably Lisp that introduced the idea of assignment being an
expression (due to everything being an expression). It's a safe
language, and not less safe on that account. This is because you are
vanishingly unlikely to accidentally write (setq a b) when you intended
(eq a b), and if that were to happen, another pair of reviewing eyes
would likely not gloss over it.

Python has now reintroduced a form of assignment you can use
in the middle of an expression; the token is := which is unlikely
to be used by mistake instead of an equality test or whatnot.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

David Brown <david.brown@hesbynett.no> writes:
> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>> If you want to make C a safer language, one obvious thing is to disallow
>> using “=” in the middle of an expression. Instead of returning the value
>> of the expression, have it return void. Or just disallow it syntactically
>> altogether.
>
> I think that C would have been a safer language if assignment had been
> a statement, not an expression (such as is the case in Pascal, for
> example). But I don't think it is remotely feasible to change this in
> C - you are fifty years too late.
>
> The nearest you can come to changes like this in C would be optional
> warnings or checks in compilers and static analysers.

I suggest that the bug of using "=" where "==" was intended occurs
almost exclusively among inexperienced C programmers, particularly those
who are inexperienced with programming in general.

It's a mistake that's made because the programmer assumes that "="
is a comparison operator, as it is in mathematics and in some other
programming languages. It's an easy and understandable mistake
to make, but any reasonably experienced C programmer will have
internalized the fact that "=" means assignment, not comparison.
To a newbie, `if (x = y)` *looks like* a comparison. To an
experienced C programmer it doesn't.

(It's possible I'm overgeneralizing. For example, a programmer who
commonly switches between C and other languages might still mix up "="
and "==" occasionally.)

If C had used ":=" for assignment and "=" for comparison (and "=="
probably not used for anything), the problem would never have come up,
because ":=" doesn't look like a comparison even to a newbie. But it's
far too late to fix that in any language called "C".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 09/02/2024 17:09, Keith Thompson wrote:
>
> (It's possible I'm overgeneralizing. For example, a programmer who
> commonly switches between C and other languages might still mix up "="
> and "==" occasionally.)
>

I had do to my PhD in Fortran, for my sins. It's := for assignment and =
for comparison, and when I switched back to C, I was always writing "="
for "==".
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 09/02/2024 17:09, Keith Thompson wrote:
>> (It's possible I'm overgeneralizing. For example, a programmer who
>> commonly switches between C and other languages might still mix up "="
>> and "==" occasionally.)
>
> I had do to my PhD in Fortran, for my sins. It's := for assignment and
> = for comparison, and when I switched back to C, I was always writing
> "=" for "==".

Are you sure you're not thinking of Pascal?

Fortan doesn't use := as far as I can tell. It uses = for assignment
and .EQ. (or ==) for equality. (I think the == form is relatively new;
it's there in Fortran 90.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> I suggest that the bug of using "=" where "==" was intended occurs
> almost exclusively among inexperienced C programmers, particularly those
> who are inexperienced with programming in general.

Almost exclusively. I've had this sneak upon me maybe once or twice in
the past 15 years. GCC warns well in most situations in which the typo
is made, so it doesn't easily sneak through.

This is in the bug category of "used to be menacing before we had better
diagnostics", along with forgetting to include <stdlib.h> before using
malloc.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> I suggest that the bug of using "=" where "==" was intended occurs
>> almost exclusively among inexperienced C programmers, particularly those
>> who are inexperienced with programming in general.
>
> Almost exclusively. I've had this sneak upon me maybe once or twice in
> the past 15 years. GCC warns well in most situations in which the typo
> is made, so it doesn't easily sneak through.
>
> This is in the bug category of "used to be menacing before we had better
> diagnostics", along with forgetting to include <stdlib.h> before using
> malloc.

One issue with C is that its syntax is what I think of as "dense".

In more verbose languages (Ada is an example), a typo is very likely to
result in an easily diagnosable syntax error. In C, many typos result
in syntactically valid code that means something different. Examples
are = vs ==, > vs >>, etc. Compilers can detect and warn about some
things that are likely to be typos, like `if (a = b)`, but certain kinds
of errors are still easier to make in C than in some other languages.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 09/02/2024 17:22, Malcolm McLean wrote:
> On 09/02/2024 17:09, Keith Thompson wrote:
>>
>> (It's possible I'm overgeneralizing.  For example, a programmer who
>> commonly switches between C and other languages might still mix up "="
>> and "==" occasionally.)
>>
>
> I had do to my PhD in Fortran, for my sins. It's := for assignment and =
> for comparison, and when I switched back to C, I was always writing "="
> for "==".

Fortran must have changed considerably since I last used it.

It was "=" to assign, and ".EQ." for equality.

I assume you mean another language. My normal one does use := and = like
that, and switching to/from C gives problems: you write = in C instead
of ==, and in mine I'd write = instead of :=. However:

a = b

was a no-op in my language (or rather, it compared then discarded the
result), leading to puzzling bugs. Now I usually detect such statements.

On 09/02/2024 17:38, Kaz Kylheku wrote:
> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> I suggest that the bug of using "=" where "==" was intended occurs
>> almost exclusively among inexperienced C programmers, particularly those
>> who are inexperienced with programming in general.
>
> Almost exclusively. I've had this sneak upon me maybe once or twice in
> the past 15 years. GCC warns well in most situations in which the typo
> is made, so it doesn't easily sneak through.
>
> This is in the bug category of "used to be menacing before we had better
> diagnostics", along with forgetting to include <stdlib.h> before using
> malloc.
>

How does gcc know whether 'if (a = b)' is meant to be an assignment or
comparison?

Simply warning on the possibility is not going to be helpful, because
you will be swamped with output that may hide more important matters.

bart <bc@freeuk.com> writes:
> On 09/02/2024 17:38, Kaz Kylheku wrote:
>> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> I suggest that the bug of using "=" where "==" was intended occurs
>>> almost exclusively among inexperienced C programmers, particularly those
>>> who are inexperienced with programming in general.
>> Almost exclusively. I've had this sneak upon me maybe once or twice
>> in the past 15 years. GCC warns well in most situations in which the
>> typo is made, so it doesn't easily sneak through. This is in the bug
>> category of "used to be menacing before we had better diagnostics",
>> along with forgetting to include <stdlib.h> before using malloc.
>
> How does gcc know whether 'if (a = b)' is meant to be an assignment or
> comparison?
>

It doesn't know. If you enable the warning (-Wparentheses, enabled by
-Wall), it assumes that an assignment at the top level of a condition
was probably meant to be a comparison, and warns about it. The warning
suggests adding parentheses, so `if ((a = b))` avoids the warning.

> Simply warning on the possibility is not going to be helpful, because
> you will be swamped with output that may hide more important matters.

Assignments in conditions are rare enough that you're not likely to be
swamped.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

bart wrote:
> On 09/02/2024 17:22, Malcolm McLean wrote:
>> On 09/02/2024 17:09, Keith Thompson wrote:
>>>
>>> (It's possible I'm overgeneralizing. For example, a programmer who
>>> commonly switches between C and other languages might still mix up "="
>>> and "==" occasionally.)
>>>
>>
>> I had do to my PhD in Fortran, for my sins. It's := for assignment and
>> = for comparison, and when I switched back to C, I was always writing
>> "=" for "==".
>
> Fortran must have changed considerably since I last used it.
>
> It was "=" to assign, and ".EQ." for equality.
>
> I assume you mean another language. My normal one does use := and = like
> that, and switching to/from C gives problems: you write = in C instead
> of ==, and in mine I'd write = instead of :=. However:
>
> a = b
>
> was a no-op in my language (or rather, it compared then discarded the
> result), leading to puzzling bugs. Now I usually detect such statements.

as some maybe know im from time to time write my compiler on c based
langage and also i hardly think how to simplify and expand syntax and
construction

as to this problem how ewentually replace = and == at present time i
just found this problem unresolvable :c

what i think = coud eventually stay though it also could have
alternative.. == is in turn clearly wrong but one would need unicode
sign for this i guess.. there is need for some sign like = with a small
"?" above it

≟ possibly

a≟b

On 2024-02-09, bart <bc@freeuk.com> wrote:
> On 09/02/2024 17:38, Kaz Kylheku wrote:
>> On 2024-02-09, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>>> I suggest that the bug of using "=" where "==" was intended occurs
>>> almost exclusively among inexperienced C programmers, particularly those
>>> who are inexperienced with programming in general.
>>
>> Almost exclusively. I've had this sneak upon me maybe once or twice in
>> the past 15 years. GCC warns well in most situations in which the typo
>> is made, so it doesn't easily sneak through.
>>
>> This is in the bug category of "used to be menacing before we had better
>> diagnostics", along with forgetting to include <stdlib.h> before using
>> malloc.
>>
>
> How does gcc know whether 'if (a = b)' is meant to be an assignment or
> comparison?

The point is that this is not knowable; it is ambiguous. (Perhaps
the current maintainer of the code doesn't even know).

That's why it deserves a diagnostic.

Someone will have to look at it and figure out whether it should
be the assignment or comparison.

> Simply warning on the possibility is not going to be helpful, because
> you will be swamped with output that may hide more important matters.

So you might suspect, but that turns out to be wrong.

GCC assumes that this is a mistake and warns about it, suggesting
that parentheses be put around the assignment if it is intended.

warning: suggest parentheses around assignment used as truth value
[-Wparentheses]

This -Wparentheses is included in -Wall. Thus:

if (a = b) // warns

if ((a = b)) // shuts up

this heuristic turns out to be good. The diagnostic rarely occurs in the
first place, and the fix is trivial.

Parentheses normally disambiguate associativity/precedence. So by a kind
of metaphor, here they are used to fix a psychological rather than
grammatical ambiguity.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 09/02/2024 18:09, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 09/02/2024 01:39, Lawrence D'Oliveiro wrote:
>>> If you want to make C a safer language, one obvious thing is to disallow
>>> using “=” in the middle of an expression. Instead of returning the value
>>> of the expression, have it return void. Or just disallow it syntactically
>>> altogether.
>>
>> I think that C would have been a safer language if assignment had been
>> a statement, not an expression (such as is the case in Pascal, for
>> example). But I don't think it is remotely feasible to change this in
>> C - you are fifty years too late.
>>
>> The nearest you can come to changes like this in C would be optional
>> warnings or checks in compilers and static analysers.
>
> I suggest that the bug of using "=" where "==" was intended occurs
> almost exclusively among inexperienced C programmers, particularly those
> who are inexperienced with programming in general.

It can also happen accidentally - even experienced programmers can make
typos which they don't spot immediately. But experienced programmers
will normally be using tools that will find such mistakes very quickly.

>
> It's a mistake that's made because the programmer assumes that "="
> is a comparison operator, as it is in mathematics and in some other
> programming languages. It's an easy and understandable mistake
> to make, but any reasonably experienced C programmer will have
> internalized the fact that "=" means assignment, not comparison.
> To a newbie, `if (x = y)` *looks like* a comparison. To an
> experienced C programmer it doesn't.
>
> (It's possible I'm overgeneralizing. For example, a programmer who
> commonly switches between C and other languages might still mix up "="
> and "==" occasionally.)
>
> If C had used ":=" for assignment and "=" for comparison (and "=="
> probably not used for anything), the problem would never have come up,
> because ":=" doesn't look like a comparison even to a newbie. But it's
> far too late to fix that in any language called "C".
>

Yes.

There are too many situations where assignment being an expression is a
useful facet of the language; i am not willing to sacrifice that for an
ill-defined ideal of “safety”.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site
It cost 53 million pounds just to cancel.