
I'm personally offended by curly-brackets (AKA "braces"), since in my eyes they have a nipple.
This is obviously mammal-centric, so it's no-wonder reptiles and fish don't program in C. Why is no-one considering diversity in programming.
11 publicly visible posts • joined 10 Oct 2019
master
with main
across its services
I started to learn Go, but then I found out that it forces you to put the "curly-bracket" on the *same line* as the function name (due to not needing as many semicolons supposedly).
As a victim of IBM's "Lines of code, per engineer, per month, metric" (as a junior engineer), I cannot put the "{" on the same line as the function name without PTSD-like issues, less someone line-counts my code and finds me under that magical 10,000-line bar.
So that, and the recent antics of google (yes I know Go is open source), prompted me to go learn something else.
I'm interested to know why you allow Google Analytics ? At best it's just a waste of bandwidth.
My setup sounds much the same as yours, except I keep google blocked since they're the primary armholes that initially weaponised the internet against us. Sometimes I need to allow the maps API to look something up, but then it's blocked again.
There used to be a version of a C compiler which would flag any use of a old-style C string function as a flaw / risk, even something like:
char block[20];
strcpy( block, "foo" ); /* safe because "foo" can always fit in 20 bytes */
Obviously "foo" can never be larger than the target buffer, so it's not possible to be a source of problems.
I wonder how much of their analysis simply counts these sorts of function calls in the code, without actually investigating whether it's a genuine problematic use or not.
The core of this problem, is that with floating point calculations precision is often lost.
Consider the case of summing a (metric) truckload of small values, they *may* eventually add to something significant.
But with the case of adding a tiny value to an existing large floating-point number, it can quite often be rounded-away to insignificance.
So the common solution is to perform your arithmetic on the "finer details" first.
Sure sorting the input-filenames gives you the same result (at least on systems using the same IEEE-754 floating point hardware), but what they should be striving for is the most accurate result. If the ordering of the input files has a significant effect on this, then this isn't happening.
We had a nice HP network-tethered scanner/printer/fax, and always used HP branded ink. I was quite happy with it. It was even well supported under Linux.
Then we moved hemispheres. Genuine HP ink purchased in Switzerland refused to work in a Genuine HP printer bought in Australia.
Sadly, both ink and printer were junked, but happily I have never since bought another HP product.