Le 11/08/2024 à 15:38, Dan Purgert via Dng a écrit :
> On Aug 11, 2024, Didier Kryn wrote:
>> Le 11/08/2024 à 04:06, Steve Litt a écrit :
>>> I think it's a pretty darn good language. It makes sense, its syntax is
>>> pretty guessable (except for pointers to functions), and it's a small
>>> language that's easily learned.
>>>
>>     Yes, you think you learned it... but sometime you discover you missed
>> something. And there's a lot one can miss in C. There's a lot of subtelties,
>> like in automatic type promotion, for example, like the difference between
>> static and automatic variables, static constants and automatic constants,
>> embedded functions... And this horrible thing of using the equal sign for
>> assignment:
>>
>> When you write
>>
>> x = 1;
>>
>> ...
>>
>> x = 2;
>>
>>     Any one having a notion of mathematics will call you a liar. And it
>> forces you to use == to mean equality, which has been the source of zillions
>> of bugs, because, in C, an assignment is an expression.
> Why? You're reassigning the variable 'x' to the value 2 ...

    The thing is there is the "equal" sign, which has a universal
meaning and which is needed with this very meaning, in every computer
language, just to mean, as it stands "equal". It is just absurd to
change its meaning to "becomes" and invent "equal equal" to mean
"equal". FORTRAN use ".eq." IIRC, to mean "equal", which, at least,
makes errors detectable at compile time.

    I don't know if the invention comes from FORTRAN or BCPL, but, by
the time C was devised, ALGOL already had invented ":=" to mean
"becomes", while keeping to "=" its universal meaning.

    This, combined with the fact that, in C, an assignment is an
expression, which can be assigned in turn, is the main cause of bugs in
C programs. This is to the point that, at least GCC, emmits a warning
when such an assignment is present inside a conditional expression
without being tagged by surrounding it with parentheses.

>>     In any human language, people count things by giving number 1 to the
>> first and number n to the nth. In C the first has number 0 and the nth has
>> number n-1. Just for the sake of pointer arithmetics.
> ... and the languages that start at 1 provide nothing but off-by-one
> errors :P
    Dunno what you mean. Do you think C so much that you don't count
like humans? I've seen this already, you wouldn't be the zeroth (~:

>>      The enumerations share one single namespace, which is the same as the
>> variable names.
>>
>>      In C, INT_MAX+1 == -1   ( INT_MAX is defined in <limits.h>)
> Shouldn't that be "INT_MIN", when you overflow a signed integer?
>
> signed 8 bit INT_MAX is 0b01111111 (127)
>               INT_MAX+1 = 0b10000000 (-128)
>
> Should hold true for 16,32,64-bit (signed) integers ... or am I having
> problems doing math this morning? 🙂
>

  You're right, INT_MAX + 1 == INT_MIN, that is 2147483647 + 1 ==
-2147483648 on x86-64. In a better language, this would raise an
exception. The fact is that C assumes that integers wrap around, which
is consistent with the principle of K&R of "assume the programmer knows
what he's doing", and it is just one step above assemblers. And this is
back to what I was writing first: there are a lot of pitfalls in C. This
is just a spectacular example which is rarely a source of error given
that programs rarely use such large values or oversize the type.

--     Didier