Re: 32 bits time_t and Y2038 issue

On 22/03/2025 00:00, Hans-Bernhard Bröker wrote:

Am 21.03.2025 um 16:45 schrieb David Brown:

On 21/03/2025 15:04, Waldek Hebisch wrote:

David Brown <david.brown@hesbynett.no> wrote:

 

In a project of over 500 files in 70 directories, it's a lot more work
than using wildcards and not keeping old unneeded files mixed in with
source files.

[...]
 This argument blindly assumes files matching the wildcard patterns must self-evidently be "old", and "still" in there.  That assumption can be _wildly_ wrong. 

Most assumptions can be wildly wrong at times :-)

People will sometimes make backup copies of source files in situ, e.g. for experimentation.  Source files can also get accidentally lost or moved.
 

Yes, people do all sorts of things - I was merely describing what I think is the best way to organise files, in most circumstances.
Sometimes you do want to make a backup copies of a source file before doing some odd changes, and you don't want to do it via your source code system (git, subversion, whatever).  This should be rare enough, and temporary enough, that you can usually put the copy in a completely separate directory without risking confusion.  Or you simply make your copy of "file.c"  as "file.c.old", "file.c.1", or similar - anything except "Copy of file.c".
And if you are losing or moving you files accidentally, you have bigger problems that can be solved by manual file lists!

Adding a source to the build on the sole justification that it exists, in a given place, IMHO undermines any remotely sane level of configuration management.  Skipping a file simply because it's been lost is even worse.

If I have a project, the files in the project are in the project directory.  Where else would they be?  And what other files would I have in the project directory than project files?  It makes no sense to me to have a random bunch of old, broken, lost or misplaced source files inside the source file directories of a project.  If I remove a file from a project, I remove it from the project - and if I want to see the old file some time in the future, I can see it in the source code revision system.
As regards "lost" files, I don't know where to being to follow your argument.  How do you "lose" files?  And having lost a file, how could your build do anything other than skip it?  Of course your build is likely to fail, at least during linking - regardless of whether you have manually-maintained file lists or automatic lists from wildcards.

 Hunting for what source file the undefined reference in the final link was supposed to have come from, but didn't, is rather less fun than a clear message from Make that it cannot build foo.o because its source is nowhere to be found.

How often have you "lost" a file accidentally?  At the risk of making an assumption, I bet it is a much rarer event than including a new file in a project and forgetting to add it to your manual makefile lists, and having to figure out what went wrong in /that/ build.
Or for even more fun, you refactor to move a function from an existing C file that has grown too big, and put it into a new file and expand the function.  But you've accidentally left the function in the old file, so your build works without complaint and yet no matter how many "printf" debug lines you add to the function, they never turn up in your testing - because your build is still using the old file and old function, and does not catch the duplication at link time.
The /real/ problem with a haphazard source file organisation is when someone else has to look at the project (perhaps that person being your future self in ten years time).  The new maintainer's task is to find all uses of the function "foo" and re-code them to use "bar" instead. They are faced with the fun of trying to figure out which of the 20 files that grep said used "foo" are actually relevant - which are part of the real build, which are part of experimental or alternative builds done sometimes, and which are junk leftover because a previous developer did no housekeeping.
Of course there are pros and cons to every way of organising files.  And sometimes you need a variation of a standard rule - you need /some/ flexibility to adapt to the needs of any given project.  But start with the rational setup of having files in the project source directory if and only if they are part of the project source.  Then you can have the convenience and reliability of wildcard rules in your build setup.  And /then/ you can add in exceptions if you have good reason for it - specify exceptions to the patterns, don't throw out the whole pattern.

  The opposite job of hunting down duplicate definitions introduced by spare source files might be easier --- but then again, it might not be.  Do you _always_ know, off the top of your head, whether the definition of function "get_bar" was supposed to be in dir1/dir2/baz.cpp or dir3/dir4/dir5/baz.cpp?
 

Generally, yes, I do - at least for my own code or code that I am working with heavily.  Amongst other things, I would avoid having two "baz.cpp" files.  (Sometimes files from different upstream sources might share a name by coincidence, so the build has to tackle that safely, but humans get these mixed up more easily than computers.)  And I have the directories and subdirectories named sensibly with files grouped appropriately, to make it easier to navigate.
But one thing I can be sure of with my system - "get_bar" is only defined in one place in one file.  With a less regular approach with manual file lists and old (or moved, or "lost") files hanging around, maybe "get_bar" is defined in /both/ versions of "baz.cpp" and it is far from clear which one is actually used in the project.

Compared to effort needed to create a file, adding entry to file list
is negligible.

>
That's true.
>
But compared to have a wildcard search to include all .c and .cpp files in the source directories, maintaining file lists is still more than nothing!

 Which IMHO actually is the best argument _not_ to do it every time you run the build.  And that includes not having make to do it for you, every time.  All that wildcard discovery adds work to every build while introducing unnecessary risk to the build's reproducibility.

There's no risk to build reproducibility.  Why would there be?  If you have the same files, you have the same wild-card generated lists.  If you have different files, you have different generated lists - but you don't expect the same build binary from two different sets of source files!

 Setting up file lists using wildcards is a type of job best done just once, so after you've verified and fine-tuned the result, you save it and only repeat the procedure on massive additions or structural changes.
 

It's the kind of job best done automatically, in a fraction of a millisecond, without risk of errors or getting out of date.

Keeping that list updated will also be less of a chore than enforcing a "thou shalt not put files in that folder lest they will be added to the build without your consent" policy.

I also insist on a policy of not letting my cat walk across my keyboard while the editor is in focus.  I don't consider that any more of a "chore" than a policy of putting the right files in the right place!