• 2 Posts
  • 28 Comments
Joined 1 year ago
cake
Cake day: June 30th, 2023

help-circle







  • volatile int blackhole;
    blackhole = 1;
    const int X = blackhole;
    const int Y = blackhole;
    

    Compiler is forbidden to assume that X == 1 would be true. It’s also forbidden to assume that X == Y. const just means the address and/or the data at the address is read only. const volatile int* const hwreg; -> “read only volatile value at read only address hwreg”. Compiler can assume the hwreg address won’t magically change, but can’t assume the value read from that address won’t.


  • JATtho@sopuli.xyztoProgrammer Humor@programming.devReview Please
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    7 months ago

    Please, no, I get flashbacks from my 6-month journey (still ongoing…) of the code review process I caused/did. Keeping PR scope contained and small is hard.

    From this experience, I wish GitLab had a “Draft of Draft” to tell the reviewer what the quality of the pushed code is at: “NAK”, “It maybe compiles”, “The logic is broken” and “Missing 50% of the code”, “This should be split into N PRs”. This would allow openly co-develop, discuss, and steer the design, before moving to nitpicking on the naming, formatting, and/or documentation details of the code, which is likely to drastically change. Drafts do work for this, but the discussions can get uncomfortably long and convolute the actual finishing of the review process.

    Once both reviewer(s) and the author agree on the code design, the “DraftDraft” could be collapsed into a link in an normal Draft to be mocked next. The scope of such draft would be limited by the earlier “DraftDraft”.










  • It happened to me when I was configuring IP geoblocking: Only whitelist IP ranges are allowed. That was fetched from a trusted URL. If the DNS provider just happened to not be on that list, the whitelist would become empty, blocking all IPs. Literally 100% proof firewall; not even a ping gets a pass.


  • Technical debt means how much work it takes to update legacy solution to a modern solution. E.g. each time a new C++ standard is used, all code written with the old standard should be checked. The work time needed to do this is paying up the technical dept.

    Now, if you are lazy, and didn’t clean up the code, used the easy and sloppy solution, next time you have twice the work to be done. So the dept gets worse, if you do nothing.