bart <
bc@freeuk.com> wrote:
On 19/04/2025 20:22, James Kuyper wrote:
On 4/19/25 12:36, Kaz Kylheku wrote:
On 2025-04-19, Scott Lurndal <scott@slp53.sl.home> wrote:
bart <bc@freeuk.com> writes:
On 18/04/2025 19:10, James Kuyper wrote:
...
If all you can do is "hope for the best", you're doing it wrong. It's
your job to ensure that they are not arbitrary unrelated expressions,
but correctly related expressions, and that's no different from your
responsibility for all of the other expressions that make up your
program.
>
>
>
If you find that problematic, you shouldn't be programming in
any language, but certainly not in C.
>
I see it didn't take you long to get to the personal insult. What is it
with this group?
>
It's not an insult, it is a simple fact.
>
It's not a fact that someone who finds tools problematic shouldn't
be using them.
I wasn't talking about him finding the tools problematic. I was talking
aobut him find it difficult to ensure that the expressions are not
arbitrary unrelated expressions, but are in fact correctly related
expressions. If you cannot ensure that A, B, and C have the correct
relationship to make for(A; B; C) work as needed, then you also lack to
ability to make sure that the expressions in {A; B; C:} work together as
needed, and that ability is fundamental to computer programming.
In other words, the feature is dumb.
The compiler cannot do any checking: for (i=0; i<n; ++n) is fine.
Even in BASIC, if I do this:
for i=1 to n
next n
it will say that n does not match. And here it is optional; in C that
part is necessary.
So, BASIC's for-loop is less dumb that C's.
But, you have a bizarre take on this: if somebody calls it out, then
rather than agree with them, you will personally insult the person who
said it, and suggest that if they are incapable of such a simple check,
then they shouldn't be coding.
The fact is that people make typos (obviously, not you or JP or SL or
KT!), and here you would really prefer that the compiler could report
them, but with this feature, it often can't.
There is low probablity of writing standard loop wrong and most
people are not bothered that some errors are not detected at
compile time. If you are trouble by this, solution is simple:
do not write 'for' loops different than the simple one:
for(int i = 0; i < B; ++i)
or maybe a slightly more general form:
for(int i = A; i < B; ++i)
This restricition is easily checkable in mechanical way, checking
it is a very small addition to C parser. You can modify your C
compiler so that is will flag any "non simple" 'for' loop as an
error. So, this is really non-issue for anybody who wants to
use C, but is bothered by errors that you mention.
If you are bothered that other people do not think that C
flexibility is a problem, then you would need _much_ stronger
argument, starting with some real data. And even then do not
think that you will "win" the argument. Ada folks had strong
arguments, namely there was a company having mixed codebase,
partially in C, partially in Ada, with both parts of comparable
size. They had various statistics inluding defects, showing
that Ada was about twice time as productive as C, that is they
were able to get the same functionality with significantly
smaller (IIRC more than two times smaller) number of defects
and at lower developement cost. Popularity of Ada should
tell you how C programmers reacted to this data.
Note: one can question validity of the Ada versus C data, in
particular if it generalizes to other settings. However, this
data is the best comparative data that I am aware of and I have
little hope to see better comparison. There are also data
about actual failures in C code. Here top issue was
confusion between '=' and '==' in conditionals (this probably
motivated warnings in gcc and clang about using naked assignment
in comparisons). Guessing or hand picked examples are
not a substitute for serious research. In particular, some
potential issues seem to be no problem in practice, that
is did not lead to known failure in a largish collection
of C programs.
BTW: In modern software number of defects due to issues that
you discuss seem to be much lower than in the past, partially
due to warnings from C compilers. OTOH memory errors seem to
dominate and AFAICS you have nothing better than C have
concering memory safety. In fact, one of most effective
ways to improve memory safety of C programs is to use
accessor macros or functions to check every array access.
But this has acceptable cost only when one uses highly
optimizing compiler.
-- Waldek Hebisch
do { quit; } else { }
Re: do { quit; } else { }