mh7

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.