5/10/2026 at 3:54:23 AM
- args->endp - args->begin_argv + consume);
+ args->endp - (args->begin_argv + consume));
I've seen so many mistakes from it, and seen people spend so much pointless and avoidable time deciphering and verifying it, it really doesn't seem worth it (in most code) for the extremely minor character savings.
by Groxx
5/10/2026 at 6:05:01 AM
I think I’d generalize that rule to require parentheses in any situation where adding parentheses could change the interpretation. I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses. a - b - c
by kstrauser
5/10/2026 at 6:43:38 AM
> I think that’d leave int addition and multiplication, and I don’t think there’s anything else offhand. Other than those, require parentheses.At this point you just require every compound infix expression to be parenthesised, the terseness isn't worth the inconsistency. Especially as, as others have noted, these operations are only associative when working in some classes (notably not necessarily when dealing with floats).
And then you do automatic parens insertion in the LSP, so you write
a - b - c
(a - b) - cby masklinn
5/10/2026 at 5:50:03 PM
I've also grown somewhat sensitive to duplication, maybe to a painful level. But, the memmove-call from the AI writeup has duplication in there: memmove(args->begin_argv + extend,
args->begin_argv + consume,
args->endp - args->begin_argv + consume); // ← bug
retained_tail_begin = args->begin_argv + consume
memmove(args->begin_argv + extend,
retained_tail_begin,
args->endp - retained_tail_begin);
space_to_replace_end = args->begin_argv + extend
retained_tail_begin = args->begin_argv + consume
memmove(space_to_replace_end,
retained_tail_begin,
args->endp - retained_tail_begin);
by tetha
5/10/2026 at 6:33:22 PM
Yeah - sharing a variable there is a pretty strong signal that they are the same concept and can't be allowed to be different, not just "maybe the same value". That's useful to know.If there's a ton of it in a dense bit of code, 1) it might be too complex, try making it clearer, and 2) it unfortunately makes for a lot of indirection and that can make it harder to follow, which is generally why I see people dislike it. In non-critical code I can kinda agree with inlining it. Pointer arithmetic is imo never non-trivial tho, paranoia is warranted. Especially in a kernel.
by Groxx
5/10/2026 at 4:07:31 AM
- and + operators have the same precedence. And a similar bug is possible if the operators were the same (both -). So I’m not sure it’s right to blame this on operator precedence or mixed operators. It’s just that, ultimately, the “consume” needs to be subtracted, not added.by om2
5/10/2026 at 4:13:07 AM
Non-mixed always goes strictly left to right, regardless of the operator, which I haven't seen anywhere near as much struggling with.But yes, I personally parenthesize `a-b-c` explicitly, because it's not worth it for me to read and wonder if parenthesizing order matters later. Costs less than a second to write, saves a second or ten each time I read it - that's an excellent tradeoff imo, and is a trivial pattern to follow.
(Associative operators are fine, obviously)
by Groxx
5/10/2026 at 4:39:43 AM
I agree with explicit parentheses but please be careful about assuming associativity! The risk when handling floating-point arithmetic in particular is that associativity breaks, and suddenly a + (b + c) does NOT equal (a + b) + c. Not only can these lead to unexpected and hard-to-trace failure patterns, but depending on the details, they also can introduce memory overflow/underflow vulnerabilities.by simonreiff
5/10/2026 at 2:25:04 PM
If you're going for bit-for-bit equivalence of float values, then even with a single operation you're relying on compiler flags, architecture, the phase of the moon... I'm hard-pressed to think of any memory safety issues though.by chuckadams
5/10/2026 at 5:04:40 PM
Yea, you're in a fairly special niche of programming if you're somewhere that truly matters, and you can't accept any valid order's output. In most general code, if that kind of precision matters, float is the wrong choice: use a bignum object and be exactly correct regardless of how you organized your code.Which is a niche that exists, obviously. So it is absolutely true for some cases. But I would hope that any code that requires this is extremely clear about requiring it.
by Groxx
5/10/2026 at 4:22:18 AM
Didn't you just suffer from the same trap the parent was trying to avoid?by genxy
5/10/2026 at 12:18:44 PM
I once had a job interview where they wanted to evaluate my C knowledge. They showed me a printout of some pointer arithmetic and said spot the bug. (It may actually have been the old puzzle where it turns out that /* is always a comment opener and never a division by the referent of a pointer).I said "well first, this is a mess, I'm putting parentheses here, here, here and here". They said "well you've fixed the bug but can you tell us where it was?"
I gave them a hypothesis but I said my "real answer" was that it's not worth our brain cycles to figure it out, you just shouldn't write code that requires knowing operator precedence. It's just such desperately boring information that I can't hold it in my head.
Interviewing such an insufferable smartarse was probably quite annoying but they did give me the job and I do stand by the underlying principle!
by bjackman
5/10/2026 at 4:35:31 PM
> I gave them a hypothesis but I said my "real answer" was that it's not worth our brain cycles to figure it out, you just shouldn't write code that requires knowing operator precedence. It's just such desperately boring information that I can't hold it in my head.this is exactly how I think. and it goes for a lot of stuff in general, we have limited bandwidth and wasting it on useless stuff like this has no real purpose.
yet sometimes I see people show off about how they know how to deal with it but I just don't see the point.
by r_lee
5/10/2026 at 9:22:38 PM
Your response was more correct in a professional sense than producing the piece of knowledge you've been asked for. I'd prefer to work with people who value everyone's time and write programs accordingly. If the interviewer was looking for a valuable expert, they were lucky to get you on board.by oleganza
5/10/2026 at 3:42:13 PM
I've never had to write or read code in an interview. I wonder how common that is?by SoftTalker
5/12/2026 at 8:37:07 AM
It's very common, I believe all the Big Tech firms have you write code.I think the example from my story was the only one I've had where I had to _read_ code. (I have heard of people doing "code review interviews" though).
I've also had a job interviews with no code though. For startups or non-FAANG type companies.
by bjackman
5/13/2026 at 2:56:56 AM
Literally all of them, for at least the past decade, afaik. Obviously it'll vary a lot outside those though, the field employs all kinds in all kinds of ways.by Groxx
5/10/2026 at 7:00:19 AM
Smalltalk didn't have math operator precedence, and I thought it was very annoying but I've come to believe it was a good idea.by riffraff
5/10/2026 at 1:56:39 PM
A much older language that does not have operator precedence is APL.This is the right choice for a language with a great number of operators.
In C they have tried to minimize the number of parentheses in expressions, but for this they have created far too many levels of precedence between operators, which had the opposite effect to that intended, since people now prefer to insert superfluous parentheses, to avoid having to remember all those levels of precedence.
by adrian_b
5/10/2026 at 9:15:32 AM
That's what pony did also. Operator preceding rules are too arcane, such as the need for manual memory management.by rurban
5/10/2026 at 10:14:21 AM
Nice: https://tutorial.ponylang.io/expressions/ops#precedenceYeah that's pretty much exactly what I do by hand. I should really give Pony a try some time... there's a lot of stuff in it that I like.
by Groxx
5/10/2026 at 7:43:35 AM
IIRC several industry and government coding standards don't permit evaluations in arguments to functions, as the compiler can end up doing wonky things, to say nothing of the likely human error. These are the kind of standards we should be adapting into a software building code to avoid security holes like this one.by 0xbadcafebee
5/10/2026 at 10:55:04 AM
These standards are that way because older languages (specifically C and C++) have unspecified evaluation orders for arguments, so multiple argument expressions with conflicting side-effects are non-portable.Here the expressions are pure, OooE has nothing whatsoever to do with the issue.
by masklinn
5/10/2026 at 12:43:05 PM
Or just use a language with a sane (read: defined) argument evaluation order, which is to say, every language that isn't C or C++.by kibwen