HN user
How would you make a mistake?
The only time signed vs unsigned matters is for comparisons and mul/div, and those have explicit names so you're never surprised that 0xFFFFFFFF is less than 0 when doing signed_less_than().
Bread takes hours to make and lasts for one day. So unless you wanna wake up at 3 am (or have a dedicated stay-at-home person making bread every day) it's not really a realistic option for many people.
Signed and unsigned should both go, there should only be wordN types (word8, word16, etc) with two's complement semantics.
Then you can have explicit functions for the operation you want: signed_mul(), signed_less_than(), unsigned_greater_than(), add_assume_no_overflow(), etc. (add your favorite syntactic sugar/operator symbols for these).
Assembly is more explicit and clearer to understand in this regard.
I asked for actual concrete evidence, not "can be used".
Is there an example of a program that was crap, implemented telemetry and then got better afterwards? (and of course controlled for factors that might have improved the program anyway)
I mean since telemetry advocates are so into how useful data is, surely they must have data on whether telemetry itself works?
Any evidence that telemetry actually works? (i.e makes the program better)
It's probably a case of me not knowing what I don't know, but I've never understood what the big deal with 'observation' is in QM. I dabble a lot in electronics and I'm painfully aware of how measurements affect a circuit - try to measure current and you introduce a voltage drop, stick a probe somewhere and you add an antenna, add capacitance, etc.
So to me when trying to measure anything it seems so blatantly obvious that it has to change the outcome - you will interact in some way with the system to get any information out, and this will change the tracejctory, energy, momentum or whatever of the particles.
I mean is that it? That's the mystery?
I don't see a way around that - Organs are inherently rare because of their size, cost, locations and maintenance requirements.
Unless someone finds a way of scaling up production and/or reducing the cost, you're not gonna see organs popping up everywhere, hence limited access.
No it is not reserved, it's just posix's personal style guides. There's just as much of a name clash possibility when not using _t because lots of other libraries and platforms uses some other convention.
Only ISO C can reserve things, no one else, and ISO C does not reserve the _t suffix.
The sad part is that this setup is probably slower and laggier running on top end machines of today than turbo c running on the actual legacy hardware back in the day.
Does zig plan on not supporting microcontrollers or not using "/" for integer division?
Because on your typical arm mcu, x/y is a function call to a definitively non-constant time function.
And lets not forget soft-fp. Every single floating point op is a function call...
There is no language called "C/C++".
Yes there is.
Take the union of C and C++ which is valid syntax (and same semantics) in both languages, voila; C/C++.
strlen() returns a size_t so you're already constrained to a maximum length of SIZE_MAX.
Re #3:
A big downside is that you you can't easily take ownership of an existing buffer and treat it as this string type.
string s;
char some_buf[];
string_take(&s, some_buf, some_capacity);
Also you would of course never dynamically allocate string structs, just the data member if needed.
It's reserved in the same sense that google's style guide 'reserves' struct names starting with a capital letter.
Only ISO C can officially reserve names, everyone else just has their personal code/naming style that you can chooseto follow or not.
These things require access to accurate and up-to-date road and traffic info
Which they will probably steal from the regular drivers, so you will be effectively paying for your own data.
Well not even Windows can manage to sleep a 'modern standby' laptop reliably these days.
I had to set hibernate on lid-close because Windows kept waking it up all the time even while closed.
Nope, not even formal proofs can save you, see WPA2/KRACK.
Using proofs just shifts the bugs into the assumptions/axioms (i.e you think your proof is proving X but it's actually proving Y)
equivalent windfarm (at $1.3M/MW)
Does that include storage costs?
Because a windfarm alone cannot replace a nuclear power plant no matter how cheaper or how much electricity the windturbines generate because on days without wind they generate zero Wh.
Nowadays, I don't want to fiddle with Windows (which insists on forcing updates when I do power my PC up to play with friends)
Unfortunately consoles have become normal PCs in this regard - if you wanna play online you'll be forced to update the console OS and applyvgame patches.
If LLVM were written in Rust it would have function level parallel compilation already
No one is stopping anyone from writing a compiler backend/optimizer in rust, yet it hasn't happened.
A real terminal or a fake one drawn ontop of a gui emulating deacades old cruft?
Complete madness and inefficiency.
You don't know what the function called "add" does either.
There's no reason for the name "+" to be anymore special than "add" - especially in any language supporting unicode identifiers which allows even more crazy names.
Grocery stores can ban me for life - which means I starve.
No, nothing breaks with unsigned integers.
Modular arithmetic makes it work. Try a few examples close to UINT_MAX if you want to convince yourself.
Why do so many people use the head==tail as full condition?
You can use the entire buffer and not waste one slot by doing:
push: buf[writeidx % bufsize] = x;
writeidx++;
pop: x = buf[readidx % bufsize];
readidx++;
Unsigned integers, you get size by doing: writeidx - readidx; Then you check size==0 or size==bufsize to detect empty/full.
rust doesn't offer much value for embedded (mcu, bare metal, tiny stuff) imo.
No allocation = no leaks, no use after free, no dangling pointers.
No multi core = no atomics or concurrency to worry about.
Ring buffers solve 99% of my interrupt data sharing = no need to worry about synchronization.
Bounds/safety checks? Need to run and test release builds most of the time because of space/memory constraints.
A classic example is when you're writing a custom allocator and need to align the address.
Another is storing pointers in a hash table - you need to do arithmetic on the pointer bits to compute the hash.
One can be fundamentally mistaken about what "it says on the box" See WPA2/KRACK for example.
It becomes an infinite recursion of "how do we know the proof of the proof of the..." is what we actually want?
Neither rust or go have a formally verified compiler, they cannot be used for security critical programming.
Net negative.
Gets us on the path to more worlds.