To me it makes sense. If you don't know what endianness is, it doesn't make sense that a program you write in one programming language works for one target but doesn't work for the other.
I think endianness is the footgun that Zig is solving, rather than Zig being the one introducing a footgun when you deal with endianness.
It is not feasible for someone to write endian portable code in a language like Zig without understanding what endianness is imo. Regardless of how they change @bitCast there will be other cases that break this like doing @ptrCast + @memcpy.
Also this breaks currently written code that is endian portable and uses @byteSwap like it is done in most other programming languages that do these things.
I think it's because if it was someone else (e.g. Epic), they would have locked down the hardware and sold it like a console or smartphone where you can only install things from their app store.
One thing I miss from Windows is the tablet driver GUI. "cinnamon-settings wacom" doesn't let me map buttons to keys (important for software like FireAlpaca, which pans with the space key instead of supporting the middle mouse button like everybody else in the planet), and it also doesn't let me remap the tablet area to arbitrary screen coordinates. These are things I could do on Windows that I can't do through the GUI.
I wrote a Python script to do it using xsetwacom, but I don't know if it would work for anybody else. I don't know if xsetwacom is only for wacom tablets, or if xsetwacom is only for X11 (I'm not on Wayland yet).
Chromium has around the same market share as Windows, so at this point I feel people are targeting it as a web application development platform just as people target Windows.
App developers will often choose not to sandbox their applications because it's a lot easier (and sometimes faster) do to all file management yourself, but the APIs are there and ready to be used.
Flatpak is probably the worst way to "have" this possible. It's completely opaque to both app and user. If you ever tried to run an .exe through flatpak'd bottles, you'll run into an issue where .dll's aren't found because you didn't install flatseal first to configure permissions. That's not operating-system level integration. That is actually very poor design that a user requires a separate app (flatseal) to configure how the sandbox works.
I was thinking about desktop OS's, actually.
You don't need to use that Windows API. You can just access any file you want. There is no reason a music player, for example, needs to access ~/Pictures. An arbitrary program requiring access to all your files is a huge red flag, but it's a red flag that users aren't allowed to see. Proper filesystem permissions would fix that.
I have always thought of this as a "broken superman." Superman has super-hearing that allows him to hear anyone asking for help anywhere in the world. Super-speed to get there in an instant. And super-strength to solve all the problems.
>The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately.
That isn't really a problem.
The problem with null-terminated strings is specifically what happens when you reach the end of the allocated array and there ISN'T a NULL character.
Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of the NULL character, he can exploit pretty much any standard string manipulation function being used elsewhere in the program to manipulate whatever memory comes AFTER the string data structure.
No other data structure works like this. You can't mess this up in an array, because no function that manipulates arrays is just going to keep going until there is a null. That would be stupid because it would require users of the function to add a NULL to the end of their arrays before passing it to the function, so instead we just pass the size of the array to everything. Strings are the only data structure that assume there will be a NULL at end.
By the way, I read once that if you use UTF-32 every code point will be 4 bytes, constantly, but even then a single code point isn't necessarily a single character. Text is just complicated.
In C most data structures work like this, you keep going until you find NUL (character) or NULL (pointer). E.g. Strings, array of pointers, linked lists, etc. Of course you can add length to most of those, but it isn't the canonical/traditional way of doing things.
That can't be true. If you have an array of pointers it can be terminated in NULL. But an array of integers can't have a NULL value, since NULL would probably be just 0 which is a normal integer.
The null in a linked list is the null in the .next field, right? That's the way you would implemented linked lists independent of language. It's not the .value that is null.
A string is an array of characters (well, for characters representable in one byte at least) that has a specific value to represent the end of string.
It would be like if Int::MAX was reduced by 1 to make space for an Int:NUL constant that represented the end of an integer array. Or if you were creating your own ENUM, let's say for NORTH, SOUTH, EAST, WEST, and you added a fifth enumeration called Direction.NUL for use in arrays.
With an variable length array of structs, you can set all the fields all to 0 at the cost of an extra member at the end. In the cases where this is, the structures are such that (either intentionally or by consequence) something with all fields zero is outside of the function's domain
> No other data structure works like this. You can't mess this up in an array, because no function that manipulates arrays is just going to keep going until there is a null.
This is patently false. Sentinel markers are used widely in array types. Consider GNU's getopt_long() function, a mainstay in GNU tools:
The argument longopts must be an array of [struct option] structures, one for each long option. Terminate the array with an element containing all zeros.
> Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of the NULL character,
What sort of situation are you envisioning where a hacker can remove the sentinel (in the case of nul-termination) but not modify the length bytes (in the case of fat pointers)?
A situation in which a string is manipulated with buggy code that can remove the sentinel, e.g. the program uses strncpy, there is a bug in how it uses it, the hacker exploits the bug.
By contrast it's pretty unlikely for buggy code to mess the length. Add an element? +1. Remove an element? -1. Number of elements larger than capacity? Allocate a new array. Not much room for error.
If I zero out the destination buffer of a strcpy, and the string is longer than the destination buffer I will run into a buffer overflow problem despite every byte being a zero byte. The absence or presence of the zero byte doesn't seem to be the deciding factor.
These people created a law that is catastrophic for privacy, so I don't believe they will be stopped from banning VPN's just because someone claims VPN's are good for privacy.
I think endianness is the footgun that Zig is solving, rather than Zig being the one introducing a footgun when you deal with endianness.