Update

c.md

@@ -98,7 +98,7 @@ Now let's admit that nothing is [perfect](perfect.md), not even C; it was one of
 - **Some things could be made simpler**, e.g. using [reverse polish](reverse_polish.md) notation for expressions, rather than expressions with brackets and operator precedence, would make implementations much simpler, increasing sucklessness (of course readability is an argument).
 - **Some things could be dropped entirely** ([enums](enum.md), [bitfields](bitfield.md), possibly also unions etc.), they can be done and imitated in other ways without much hassle.
 - **The preprocessor isn't exactly elegant**, it has completely different syntax and rules from the main language, not very suckless -- ideally preprocessor uses the same language as the base language.
-- **The syntax is sucky sometimes**, e.g. case with variable inside it HAS TO be enclosed in curly brackets but other ones don't, data type names may consist of multiple tokens (`long long int` etc.), multiplication uses the same symbol as pointer dereference (`*`), many preprocessor commands need to be on separate lines (makes some one liners impossible), also it's pretty weird that the condition after `if` has to be in brackets etc., it could all be designed better. Keywords also might be better being single chars, like `?` instead of `if` etc. (see [comun](comun.md)). A shorter source code that doesn't try to imitate English would be probably better.
+- **The syntax is sucky sometimes**, infamously e.g. division by pointer dereference can actually create a comment (like `myvalue /*myptr`), also multiplication and pointer dereference use the same symbol `*` while both operation can be used with a pointer -- that can create confusion. Also a case label with variables inside it HAS TO be enclosed in curly brackets but other ones don't, data type names may consist of multiple tokens (`long long int` etc.), many preprocessor commands need to be on separate lines (makes some one liners impossible), also it's pretty weird that the condition after `if` has to be in brackets etc., it could all be designed better. Keywords also might be better being single chars, like `?` instead of `if` etc. (see [comun](comun.md)). A shorter source code that doesn't try to imitate English would be probably better.
 - **Some undefined/unspecified behavior is probably unnecessary** -- undefined behavior isn't bad in general of course, it is what allows C to be so fast and efficient in the first place, but some of it has shown to be rather cumbersome; for example the unspecified representation of integers, their binary size and behavior of floats leads to a lot of trouble (unknown upper bounds, sizes, dangerous and unpredictable behavior of many operators, difficult testing etc.) while practically all computers have settled on using 8 bit bytes, [two's complement](twos_complement.md) and IEEE754 for [floats](float.md) -- this could easily be made a mandatory assumption which would simplify great many things without doing basically any harm. New versions of C actually already settle on two's complement. This doesn't mean C should be shaped to reflect the degenerate "[modern](modern.md)" trends in programming though!
 - Some basic things that are part of libraries or extensions, like fixed width types and binary literals and possibly very basic I/O (putchar/readchar), could be part of the language itself rather than provided by libraries.
 - All that stuff with *.c* and *.h* files is unnecessary, there should just be one file type probably.