This is different than a privacy vs liability conflict, where a recording isn't going to provide a safety benefit, it'll just move liability around, where there's far more controversy over publishing any analysis of the recording, or even creating one in the first place.

The NTSB should never have published the unredacted spectrograph, as it is effectively a raw sound recording.

As someone that relies on third-party clients to get usable interfaces, if this gets widely adopted it would be great news. It would end the cat-and-mouse game from companies trying to force users onto first-party clients.

Now that you mention it, if the assignment had called for arguments, instead of files or pipes, argv points to a writable array, so the result could be written directly to it, negating any need to allocate memory, and any out-of-memory conditions from large input data would occur before the program is even called.

If it usually uses a file to store the numbers, the same could be done by writing the result back to the file, but that only works if it is passed as an argument, as piping it would throw a seek error. I wonder if the instructor would accept an interleaved little-endian input syntax, with a little-endian output; then the program could use pipes without a need to seek. An infinite series of '9' characters would output an '8', followed by one '9' per two input characters.

As dumb as he is:

    The driver was arrested and charged with operating a vehicle in a closed section of park/lake, having no valid boat registration, and numerous water safety equipment violations. As of today, the driver remains in jail.

    if(characters[i] <= '9' && characters[i] >= '0')
    {
      ret = ret * 10 + characters[i] - '0';
    }

I've never understood why the Zync CPU has to communicate with the rest of the FPGA over external busses. Why not connect a set of latches or LUTs to the instruction decoder and data bus, so you can create custom instructions?