@SuricrasiaOnline wow!!! there are things here i didn't know!!! thanks :D

@Dolly yeah people consistently knew about that. I ended up getting about 800 votes in the first one and 200 votes in the second

@SuricrasiaOnline Must be down to mastodon demographics being mostly nonbinary neurodivergent dorks like myself ♥

@Patashu fixed!

@monorail @SuricrasiaOnline i will prove that this ethernet cable will fry anything you plug into it, but in a way that doesn't let you know anything about it or replicate that proof to anyone else

@SuricrasiaOnline notable for not actually being a real analogy the author was making

@monorail @SuricrasiaOnline

Apparently, you can enrage a Haskell programmer by saying, "Monads are just a hack to get the compiler to run a bunch of instructions in order."

@clacke changed it to "numbers that start with zero are interpreted as octal"

@SuricrasiaOnline okay this is just my reading backlog now

@schratze @SuricrasiaOnline Here's the link to the code, lemme see where the discussion thread is: https://github.com/praat/praat/blob/master/melder/melder.h#L41

@schratze @SuricrasiaOnline containment breach happened here: https://cybre.space/@SuricrasiaOnline/106037754746783645

@Vierkantor @SuricrasiaOnline oh, thank you! I don't know enough about programming to understand why this is bad or weird practice. All I know scripting in praat is absolutely horrible. I broke my code a couple dozen times simply by inserting a space at the end of a line

@schratze @Vierkantor @SuricrasiaOnline I can attempt to explain if you’re interested?

@zwol @Vierkantor @SuricrasiaOnline Yes :)

@schratze @SuricrasiaOnline So, people have been doing things like this in C for as long as C has existed -- the very first example I know of is Steve Bourne's macros to make C look more like Algol [ https://research.swtch.com/shmacro ] -- and people have been arguing about whether it's good or bad style for just as long.

At heart, it's an argument about readability, and specifically about when it's okay to make up your own jargon.

@schratze @SuricrasiaOnline The people who like to write code like this think that project-specific jargon is a Good Thing because it makes it easier for the day-to-day maintainers of the code to read it.

You get used to seeing things like https://github.com/praat/praat/blob/9ada48d9055949e4e61d6d94b8513e8c969ab229/melder/MelderFile.cpp#L29 (first example I found of how these macros are _used_). It becomes quicker to read than the alternative with the macros all expanded. Code that _doesn't_ use the macros stands out as doing something special, demands more attention.

@schratze @SuricrasiaOnline On the other hand, the people who dislike code like this think project-specific jargon is a Bad Thing because it makes it harder for _new contributors_ to the code to read it.

Without these macros, anyone reasonably fluent in C would be able to jump in and make changes to the code, but with the macros, they first have to go find where the macros are defined and learn their meaning and their conventional usage. It's an extra obstacle if you just wanna fix one bug.

@schratze @SuricrasiaOnline This is a miniature version of a similar argument at the scale of entire programming languages.

You'll see people say that they prefer C++ to C because you can hide complicated processing behind simple notation, and you'll see people say that they prefer C to C++ because they don't want that to be possible, they always want it to be visible in the surface syntax when complicated things are happening.

@schratze @SuricrasiaOnline It's not just limited to the C family, either. Lisp also has really powerful "meta-programming" (capacity to define your own project-specific jargon and notation) and comes in for the exact same praise and criticism. Same for ML, Forth, ...

@zwol @SuricrasiaOnline ah, thanks for the in-depth explanation!

@aeonofdiscord the joke is the assertion that it's the only true bug

@SuricrasiaOnline oh of course sorry

@SuricrasiaOnline though of course moths are in the order lepidoptera rather than hemiptera, and thus not,, taxonomically,,, "true bugs",,,,,,,

@oakreef @SuricrasiaOnline

in C, array[i] and i[array] are equivalent. In the end of the day, it's just *(array+i).

Though I'm not sure how this is affected by element size...

@wolf480pl @oakreef @SuricrasiaOnline adding 1 to a pointer increments it to point to the next item. So on x86 (or most risc) given `u32 *p = ...; u32 *q =p +1;`, p and q will differ by 4 if you cast them to intptr_t.

(There are some obscure ISAs where this isn't true, but few people try to run off-the-shelf C code on those, these days. The ones I'm aware of are AS/400, Cray UNICOS, and the TI DSP families. Even on those, when they have a C compiler, the equivalency a[i] == i[a] still holds.)

@eqe @oakreef @SuricrasiaOnline hmm I guess if one of the things being added is an integer, there's no doubt whose element size should be taken. It's not like you're doing array1[array2]

@wolf480pl @oakreef @SuricrasiaOnline yep, exactly! Lots of things in C turn into integers automatically, but not pointers.

A partial list of things you can index into a C array with:

Characters, tbl['a']
booleans, tbl[x==3]
floating point I think? tbl[sin(x)]

And strings are also treated as pointers, so you can do
c = "abcde"[4]
Combining that with the original curséd syntax we have
c = 4["abcde"]

@eqe @wolf480pl @SuricrasiaOnline I'm afraid I'm not familiar with C so this is hard to parse for me. Most my coding experience is higher level stuff like C# and Python.

I know that an asterisk indicates that you're referencing a pointer. So given a pointer p that references 32 bit unsigned integer and another pointer q that references an integer one higher than q...

then you've lost me.

@oakreef @eqe @SuricrasiaOnline

ok, let's say you have a function like this:

```
void foo(uint8_t array[]) {
// ...
}
```

`array` here is actually a pointer to a chunk of memory with 8-bit unsigned ints, one after another.

`*array` dereferences array, and gives you the uint8_t that the pointer points to, i.e. 0-th element of the array

so `*array` is the same as `array[0]`

1/

@oakreef @eqe @SuricrasiaOnline

now, you can get a pointer to the 1-th element by just increasing `array` by one:
`ptr_to_1th = array + 1`
and dereference it:
`*ptr_to_1th`

or just: `*(array + 1)`

this is the same as `array[1]`.

Now, because C treats `a[b]` as just a syntactic sugar for `*(a + b)`, `1[array]` works equally well.

Now the surprising part is if you have array whose elements are bigger than 1-byte

2/

@oakreef @eqe @SuricrasiaOnline

btw. `uint8_t array[]`, when used in function arguments, is just syntactic sugar for:
`uint8_t* array`
i.e. a pointer to uint8_t.

Now if you have an array of uint32_t like:
`uint32_t array[]`
or
`uint32_t* array`

you'd still want `array[1]` to refer to the 1th element and not 3 bytes of 0th element and 1 byte of 1th element.

But C sees it as:
`*(array + 1)`
so here's the trick:

3/

@oakreef @eqe @SuricrasiaOnline

if array is of type uint32_t*,
then adding one to it advances it by sizeof(uint32_t), in this case 4.

so `array+1` is 4 bytes after `array`, and all is well.

Same for `1+array`.
Same for `1[array]`

I hope this helps.

4/4

@wolf480pl Thank you very much for taking the time to explain it to me!

@oakreef @SuricrasiaOnline array syntax in C is just pointer arithmetic:

array[i] is the same as *(array + i) is the same as i[array] (for certain types of array and i, I think?)