bigtrakzapzap

I'm sitting in Paradise, CA right now with only one neighbor's home left visible among dozens. There are about 1/3 as many tall trees (mostly pines 30m/100 ft tall) as before since the loggers have monetized them, P&GE didn't want to take any risks when rebuilding the power grid and the city/county/state motivation for future fire remediation. (IMO, the haphazard removal of trees is quite ugly and unnatural.) The policy of putting out all fires quickly set the stage for tragedy, leading to what was feared most. Living at the urban-wildlife interface needs resilient, prepared dwellers who safeguard their structures and allow fires to burn around without threatening lives or property.

These shouldn't be used either (_s are available in C11, _l tend to be locale-parameter thread-safety, and _r have sizes/state for bounds/thread-safety):

- strtok -> strtok_r / strtok_s

- asctime -> strtok_r / strtok_s

- gmtime -> gmtime_r / gmtime_s

- localtime -> localtime_r / localtime_s

- ctime -> ctime_r / ctime_s

- dirname -> dirname_r

- basename -> basename_r

- devname -> devname_r

- readdir -> readdir_r

- ttyname -> ttyname_r

- gamma -> gamma_r

- lgamma -> lgamma_r

- lgammaf -> lgammaf_r

- lgammal -> lgammal_r

- atoi -> atoi_l

- atof -> atof_l

- atol -> atol_l

- atoll -> atoll_l

- gets -> gets_s

- scanf -> scanf_l / scanf_s

- fscanf -> fscanf_l / fscanf_s

- sscanf -> sscanf_l / sscanf_s

- tmpfile -> tmpfile_s

- fopen -> fopen_s

- getenv -> getenv_s

- strdup -> strndup

- strcmp -> strncmp

- strlen -> strnlen

- (Multibyte/wide conversion functions without mbstate_t parameter)

- wcslen / wscnlen -> wcsnlen_s

- wcsncasecmp / wcscasecmp_l / wcsncasecmp -> wcsncasecmp_l

- strcasecmp / strcasecmp_l / strncasecmp -> strncasecmp_l

- bzero (use explicit_bzero, in some cases)

- calloc, realloc -> reallocarray (for arrays of non-byte items)

- memmove -> memmove_s

- strncat -> strncat_s

- strncpy -> strncpy_s

- srand / rand -> rand_r

There are others that are platform-specific. Thread-safety, internal mutable state (not thread-safe), and buffer-overflows are the primary concerns that aren't necessarily applicable in all situations.

War is a Racket - Smedley Butler (2x Medal of Honor, Marine General)

Isn't the biggest problem of HK people vs. PRC central govt is that the primary goal seems to be getting everyone in HK and the mainland to live by the same laws (regardless of transfer of sovereignty agreements between UK & PRC), and so allowing freedoms in HK would effectively mandate the same freedoms in the mainland as well?

I'd like to know how hard it is for other people starting out these days, what's worked for them. I'm not one to ask as I get hounded by Google/Alphabet recruiters every 3-6 months to co-design a role in entry-management/team-lead (SRM) or SWE/SA-SRE.

I'd suggest focusing on one of Go, Rust, Haskell, Elm or Elixir in addition to the customary C++17 or Java/Kotlin... and get some useful packages up on open repos.

No, that's your opinion, not mine. It's a flaw because it creates escaping magic, delimiters that are in-band (spaces) and every program has to know how to parse the output of every other program, wasting human time and processing time. Structured communication, say like an open standard for a schema-less, self-describing, flexible de/serialization like protobufs/msgpack, would be far superior, more usable, more efficient and simple but no too simple to process streams of data with structure and programmability already there.

Being able to dump structured information out of an exception directly into a log, and then from a log into a database, without any loss of information or extraneous log parsing, is a clear win. Or from a command as simple as listing files ("ls") into a database or into any other tool or program. Outputing only line-oriented strings is just throwing away type information, and creates more work for everyone else, even more so than continuing to stay with lines processing tools.

Wow. Impressive usability OOTB. Great job!

I remember having a SS 50, 100 & 200 back in the day. And filling up water balloons the old-fashioned way. Now kids have the automatic water balloon fillers and smart phones. Do most kids even still have water fights in the summer or do people get too offended or are too busy helicopter parenting to let kids have any fun?

The key flaw of UNIX philosophy is destructuring deserialization and reserialization based on lines, necessitating all manner of argument escaping and field delimiters, when pipelines should be streams of typed messages that encapsulate data in typed fields. Logs especially (logging to files is a terrible idea, because it creates log rotation headaches and each program requires a log parser because of the loss of structured information) also. Line-oriented pipeline processing is fundamentally too simple. Settling on a common data simple/universal format robust enough for all purposes, including very large data sets, to exchange between programs and is just complicated enough to eliminate escapement and delimiter headaches without throwing away flexibility (by a new/refined set of processing tools/commands) is key.

Basically, every kernel needs an explicit_bzero() system call because it's very difficult to assure data flow properties of de/initialization without something the compiler cannot optimize away.