On Sun, May 21, 2017 at 4:11 AM, bartc <b...@freeuk.com> wrote: > On 20/05/2017 17:49, Chris Angelico wrote: >> >> On Sat, May 20, 2017 at 8:46 AM, Viktor Hagström >> <viktor.hagst...@outlook.com> wrote: >>> >>> I have followed this discussion since the beginning, and I have been >>> intrigued. I recently read a relevant blog post that I'd like to share. It >>> has arguments for both sides: http://nullprogram.com/blog/2017/03/30/. > > >> Truly portable code either targets the lowest common denominator, >> which means avoiding any sort of file system processing or any >> features not in C89, or has multiple branches. That's the only two >> ways to do it. > > > Why avoid file processing? Standard C has long had fopen and fclose, and a > handful of other functions (basically to read files and to write them). You > don't need much else.
What's a file name consist of? Is it: * A series of bytes, terminated by \x00? * A series of bytes that must be decodable as UTF-8? * A series of sixteen-bit units which may or may not be decodable as UTF-16? What byte values and what character values are legal? How do you describe a path, or can you only work in the current directory? What is a drive letter, can you use it, and what happens if you omit it? The answers to these questions are not the same on all of today's platforms - and that's even assuming that you can ignore older systems like the pre-BSD Mac OS, or the Amiga. You can *probably* restrict yourself to the current directory and to a limited set of safe file name characters (all of which are ASCII, but not all of ASCII is safe). Probably. But I wouldn't bet my life on even that. > ...Keep the build as simple as possible." > > (Which is exactly what I strive to do. Although my projects are small, they > could still involve dozens of source and support files, and require running > non-standard tools to build, which would then require other sets of sources > to built those. Dozens? Oh you poor wee lamb. rosuav@sikorsky:~/cpython$ find -name \*.c -or -name \*.h | wc -l 672 rosuav@sikorsky:~/pike$ find -name \*.c -or -name \*.h | wc -l 701 rosuav@sikorsky:~/wine$ find -name \*.c -or -name \*.h | wc -l 3981 rosuav@sikorsky:~/linux$ find -name \*.c -or -name \*.h | wc -l 44546 These repositories, by the way, correspond to git URLs https://github.com/python/cpython, git://pike-git.lysator.liu.se/pike.git, git://source.winehq.org/git/wine, and https://github.com/torvalds/linux respectively, if you want to check my numbers. Two language interpreters, a popular execution subsystem, and an OS kernel. I'd like to see you create a single-file version of the Linux kernel that compiles flawlessly on any modern compiler and has no configure script. > It still doesn't work though because you can get down to just a single file, > and people will still moan that it's too complex. You've reduced the job of > building a set of kitchen units to hammering in just one nail, but then find > that someone has never hammered a nail in before. > > I'm now investigating how to reduce a project to no files at all!) Good, you do that. That fits in the same sort of puzzle space as building a Turing tarpit. Meanwhile, the rest of us are actually doing useful things with our lives. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
