[Bf-committers] Support for 32-bit architectures

[Brecht Van Lommel]

For example in this specific case it's easy to either:
* Copy an implementation from another library known to work
* Switch to using <atomic>
* Tweak the code to not use 64 bit atomics

And if you implement an architecture independent fallback, you can test
that by disabling the architecture specific code temporarily.

Is that really too much to ask a developer?

If there are no means of reproducing, testing, and no alternative
implementation that sidesteps the problem, then sure. But that's rare.

On Tue, Nov 17, 2020, 09:53 Sybren A. Stüvel via Bf-committers <
bf-committers at blender.org> wrote:

> On Mon, 16 Nov 2020 at 17:58, Brecht Van Lommel via Bf-committers
> <bf-committers at blender.org> wrote:
> > The difference is between:
> > * Providing active support for a processor architecture
> > * Rejecting or fixing code that only builds on a specific processor
> > architecture
> >
> > Developers should not write code which e.g. relies on pointers being 64
> > bit, integers being little-endian, or adding an x86_64 intrinsic call
> > without the appropriate #ifdefs. That's not something you should wait on
> > the community to fix. It's a bug in your code, like a null pointer
> > dereference or invalid memory access.
>
> I agree that assumptions on pointer size and endianness are not good,
> and that this is something that's usually easily detected. What "the
> appropriate #ifdefs" are is already unclear to me, as I have no
> experience with intrinsic calls.
>
> To me the important thing here is that it's hard to write correct code
> in the first place. This is why we have automated tests and want to
> invest more in proper CI. Writing correct code for hardware you don't
> have (either directly or indirectly via a buildbot) is even harder. I
> think it's objectionable to ask developers to fix problems that they
> have no means of reproducing and that occur only on non-supported
> platforms. To make things worse, we don't build libraries for these
> platforms either, so even if you can tell your compiler to build for
> some architecture, you still can't easily attempt a build.
>
> Personally I'm absolutely in favour of something like this:
> - Blender-employed devs don't actively work on fixing issues with
> unsupported platforms, but also don't intentionally write code that
> would break these platforms either.
> - Patches are welcome, and testing on the problematic platform is the
> responsibility of the patch author. Of course tests are performed by
> the reviewer/committer to ensure they don't break supported platforms.
>
> Expressing an intent to not break unsupported platforms is fine, but
> asking developers to understand and recognize problems on platforms
> they don't have access to and cannot test on, for me that's a step too
> far. Again, certain cases are known "cross-platform breakers" and
> should be avoided. I'm trying to get the definition clear of where
> those cases end, and where "supporting unsupported platforms" begins.
>
> Sybren
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> https://lists.blender.org/mailman/listinfo/bf-committers
>