• 0 Posts
  • 152 Comments
Joined 10 个月前
cake
Cake day: 2025年3月12日

help-circle





  • The compiler should be able to optimize all of them to the same machine code.

    1. This is already good.
    2. Easily optimized by constant folding.
    3. This one depends on the semantics of signed underflow, so it may not do what you want.
    4. The loop can only exit if x==10, so as long as the nextInt() method doesn’t have side effects, the loop should be eliminated. But, again, language semantics can affect this.

    Edit: Very wrong for 3 & 4, see replies.










  • I mostly agree with you, but this is not quite true:

    XDG implementation (which is also only used as a fallback when the three DE-specific implementations fail, even though all of them actually support XDG so having separate implementations is pointless)

    Yes, the DE-specific implementations is pointless (as far as I know, I use a WM), but the XDG implementation is actually used first, and the function returns true if any impl returns true, like xdg() || gnome() || gnome_old() || kde().

    rework the code so that there is a difference between “this DE wants light mode” and “couldn’t figure out of this DE is in light or dark mode” - both of these are now represented by the “false” return value.

    This isn’t that bad? Yes, having an enum with three variants would be better and more readable, but the code just defaults to light mode if nothing wants dark mode, and prefers dark mode even if separate impls want both light and dark mode.

    With multiple impls, you have to resolve conflicts somehow. You could, for example, match on current DE/WM name, only using the current DE’s impl, defaulting to XDG, avoiding the problem entirely or just use first impl that doesn’t return “default” or “error”.

    I don’t like AI generated code, having reviewed some disgusting slop before. But it’s better to criticize the code’s actual faults, like the incorrect impls (which you listed) or failing the Linux CI.



  • Not quite sure if this answers your question, but at least on Linux, there is the x32 ABI, which uses most of the changes of x64 over x86, except that pointers are 32-bit. This allows programs to use more registers & other goodies from x64, while keeping pointers small.

    If your program doesn’t use over 4GiBs of memory, it can result in a smaller memory footprint (less space used for pointers) and better performance (smaller structs fit better in CPU cache).

    Also, there are people who run a 32-bit OS on a 64-bit CPU and don’t know better.




  • I meant the following:

    1. Find out the Debian package is too old
    2. Create Arch Live USB
    3. Boot Arch Live USB
    4. Copy GRUB config from the Debian install to the current Arch live system
    5. Install the up-to-date GRUB while in the Arch environment

    The bootloader installer package is distro dependent, the bootloader the package installs isn’t. You can boot Debian no matter if the GRUB is installed from Debian stable, Debian Sid, Arch, Fedora or even FreeBSD. Otherwise, dual booting wouldn’t work.

    Like I said, I’ve done that before, though with SystemD Boot instead of GRUB, which was a bit simpler due to how the bootloader is configured.