If you put both handlers in the same 256 byte page you can get away with only updating the low byte of the address.

Because I felt like it :) Also works for multiple versions/patchlevels.

But yeah, with the info provided it should be patchable. It's a `push esi` though, where esi has to stay 0 for a few further usages, so it's a bit more than a one-byte patch. It also wouldn't fully resolve the OOB write in the rare case where you _do_ have 9+ game controllers connected.

I feel like this is a cleaner solution. As a user you don't have to faff around running a whole application just to change 3 bytes. Just drop this file in and go.

I find that this can reduce overall complexity. It makes it possible to use objects that can not be copied (such as a file descriptor wrapper) and moving can in most cases not fail. Without move semantics you'd have to use smart pointers to get similar results but with extra overhead.

I find the short type names for integers and float hard to read. Somehow the size of the type is more important than if it is a signed integer, unsigned integer or a floating point number.

Using Vec for arrays is also annoying, repeating the mistake from C++.

> Using Vec for arrays is also annoying, repeating the mistake from C++.

Neither Rust nor C++ uses vectors as array, they're distinct things.

An array is a fixed-size object, which never allocates and its elements thus always retain their memory address. In Rust they're `[T; N]`, in C++ `T[N]` or more recently `std::array<T, N>`.

A vector on the other hand is dynamically sized object, that may (re)allocate to accomodate new elements, and the address of their elements can change. In Rust they're `Vec<T>`; in C++ `std::vector<T>`.

I'm aware of how they are used, but fundamentally there is nothing with the words "array" and "vector" that says that one has a fixed size and the other has a dynamic size. If anything, it should be the other way around. Using the name vector for dynamic arrays is annoying when doing any kind of math coding. Even the designer of STL says the name was a mistake.

I genuinely don't understand how you can find the type names for numbers hard to read, nor how you can say the size is treated as more important. The first thing in the type is what kind of number it is!

RobWords made a video about it a few weeks ago! https://youtu.be/UAT-eOzeY4M

That's a different type of overhead than having unwind tables. With exceptions you wouldn't need a branch after each function call at all.

But a branch that is (almost) never taken has an overhead close to the overhead of a NOP instruction, which may be negligible on modern architectures.

The CPU can not remember an infinite number of branches. Also, many branches will increase code size. With exceptions the unwind tables and unwind code can be placed elsewhere and not take up valuable L1 cache.

> The CPU can not remember an infinite number of branches.

I suspect a modern CPU has a branch instruction saying "This branch will never be taken except in exceptions, so assume this branch is not taken". But I must admit I haven't seriously looked at assembly language for some time.

(EDIT: yes, modern CPUs including x86 and ARM allow the programmer/compiler to hint if a branch is expected to be taken).

> Also, many branches will increase code size.

I'd like to see some data on that. Of course branches take code size, but how much is that percentage-wise? I suspect not much.

You should take a look at the presentation I mentioned elsewhere in this thread. You also have to keep in mind that it's not only the branches that use space, but also the error handling code. Code which must be duplicated for every single call to a particular function.

Ok, thanks. But that code needs to be loaded into memory only if the branch takes place. Which, for exceptions, will be not often. The main assumption is: optimize for the common case, where exceptions are not the common case.

There was an interesting talk about C++ exceptions in smaller firmware at CppCon last year: https://youtu.be/bY2FlayomlE

Basically, the overhead of exceptions is probably less than handling the same errors manually in any non-trivial program.

Also, it's not like these table doesn't exist in other languages. Both Rust and Go have to unwind.

I'm not sure about other compilers, but compiling C code as C++ with MSVC ends up with pretty much the exact same code, instruction by instruction. C++ is a bit more strict though especially with casting, so a lot of code won't compile out of the box.

C++ code compiles to a different function names in object file (name mangling). You probably need to put a lot of ugly `#ifdef __cplusplus extern "C" {` boilerplate in your headers, otherwise C and C++ files will not compile together.

Don't forget the infamous pattern used in some C projects too:

  struct foo decl = {
    .member = /* ... */
    .next = &(struct nested_pointer) {
        .nested_member = /* ... */,
    },
    .array = (struct nested_array[]) {
      [0] = { /* ... */ },
    }
  };

This pattern does not work in C++ as the nested declarations become temporaries.

I've been using the OSSC to upscale a 50 Hz RGB signal (SCART) to 1024x1024 (256 lines duplicated 4x). Both my HDMI capture cards happily accept that resolution with the right software.

I haven't tried the OSSC Pro, but the Retrotink 4k should probably also work fine and is really easy to use. A bit on the expensive side though...

I already wouldn't touch the retrotink simply because it isn't open hardware, but it also is not anywhere as configurable; It's meant for non-techie people who want to be abstracted from the details.

Definitely easier to use, but nowhere as flexible.

I do not find the Retrotink 4k any less configurable than the OSSC (non-pro, I haven't tried the pro). Note that the 4k is nothing like the 5X-Pro which is more plug and play.

Which ironically describes them evolving into software driven gateways.