# Weird bug in processing or linux?

**URL:** <https://discourse.processing.org/t/weird-bug-in-processing-or-linux/25981>\
**Category:** Processing\
**Created:** [December 5, 2020, 8:11pm UTC](https://discourse.processing.org/t/weird-bug-in-processing-or-linux/25981 "2020-12-05T20:11:30Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![GoToLoop](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/gotoloop/32/86_2.png) [@GoToLoop](https://discourse.processing.org/u/GoToLoop)\
**Post date:** [December 6, 2020, 7:31pm UTC](https://discourse.processing.org/t/weird-bug-in-processing-or-linux/25981/4 "2020-12-06T19:31:59Z")

</div>

> [@jay\_m](#):
>
> Maybe a [little endian / big endian](https://en.wikipedia.org/wiki/Endianness) challenge?

Hit F12 to open the browser’s console and paste the test below there:  
`new Uint8Array(Uint32Array.of(0x12345678).buffer)[0] === 0x78`

It must return `true` on the device it’s run if it’s little-endian.

Which it is so for almost all devices in the market.

For further details about endianness go to this forum thread:

> [@Is noise too much for mobile devices to handle in p5js?](https://discourse.processing.org/t/is-noise-too-much-for-mobile-devices-to-handle-in-p5js/23048/10):
>
> Just theoretically, b/c I’ve just read that we should expect that almost all mobile devices are configured to use little endian byte order: That utility function is just to make 100% sure our code is indeed running on a little endian device (which statistically should always be so): The datatype of pixels[] is Uint8ClampedArray: [p5js.org/reference/#/p5/pixels](http://p5js.org/reference/#/p5/pixels) And there are 11 Typed Array versions: As long as we’re using 1 of the 3 8-bit versions of Typed Arrays we can fully ignore …

---

_[View the full topic](https://discourse.processing.org/t/weird-bug-in-processing-or-linux/25981)._