One of the worse parts of C is how for historical reasons, a < b & 0x1234 will get evaluated as (a < b) & 0x1234 and not a < (b & 0x1234)

"What historical reasons?"

In a very early version of C, both bitwise AND and logical AND were just & and it depended on context! And to make it easier to convert existing code, they kept the associativity rule of the logical AND for &...

(Source: nokia.com/bell-labs/about/denn)

@vaporeon_ i like javascript but it is chock full of nasty corners like this fur this exact reason

@aescling Oooh :blobcatreach:

I must admit, I enjoy learning about weird historical baggage that programming languages accumulate over time, please tell me about the nasty JavaScript corners

(But JavaScript is much younger than C... It's just funny to me how I, a C programmer in 2025, get mildly inconvenienced — at least the compiler is nice enough to warn about it even without enabling any extra warnings — because of a backwards-compatibility decision made in the early 1970s...)

Follow

a (very) non-exhaustive list of strange corners in js 

@vaporeon_ a lot of it is really whack decisions that got made early on that have to remain supppurrted fur compatibility reasons

  • objects are more or less maps from strings (or also Symbols now) to arbitrary values. myObject.myPurropurrty is equivalent to myObject['myPurropurrty']; the latter works with all string expurressions
  • arrays are actually objects with special under the hood behavior making them act in an array-like manner (notably, the length purropurrty). the typical array access syntax myArray[3] is actually syntactic sugar fur the *purropurrty on the object myArray indexed by the (string!) key '3'—the 3 is coerced into a string under the hood
  • in non-strict (that is, standard) mode, all functions have the object arguments in scope, which acts like an array but is technically not an array, allowing arbitrary access to any numbered argument on the function. (all functions are allowed to be invoked with any number of arguments). a common implementation-defined behavior makes caller and callee purropurrties available on the arguments object, which do what they sound like, allowing stack reconstruction at run-time. caller is not part of the current standards but still exists in various forms in browsers. callee is standardized but deprecated
  • in non-strict mode, the source code with which a function was defined is made available at runtime, as a purropurrrty of that function (which are not objects). this has somehow led to security purroblems
  • there are two diffurent syntaxes fur defining function expurressions, with intentional, subtly diffurent scoping rules around this
  • i won’t even get started on this. what the this keyword may refur to in a given snippet is very unintuitive
  • several keywords are reserved in the language fur features that a long time ago were suspected to pawsibly get standardized and never did. they are still reserved keywords anyway. an example: float
  • the fundamental number type is floating point numbers. there is no way around this. all numeric literals and values are always floats
  • the == equality testing oppurrator coverts both sides of the expurression to the same type befur testing true equality on the converted values. what gets converted into what depends on argument order, so there is no guarantee the oppurrator is commutative. i do not remember any examples on paw but there are some really silly looking ones
Sign in to participate in the conversation
📟🐱 GlitchCat

A small, community‐oriented Mastodon‐compatible Fediverse (GlitchSoc) instance managed as a joint venture between the cat and KIBI families.