readerp: implement file expansion

[ourairquality]

Just a convenience.

[rtklibexplorer]

A few comments from Claude AI, your thoughts?

1. Return value when no files match. If expath() returns 0 (path doesn't match anything — e.g. a typo), the loop doesn't execute and the function returns 1 (success) with no data added. The old code returned 0 on fopen failure. This behavioral change silently swallows bad path configuration, which could cause hard-to-diagnose issues downstream when ERP corrections are silently missing.
2. Partial state on fopen failure mid-loop. If files 0..i-1 load successfully but fopen fails on file i, the function returns 0 but erp->data already contains records from the earlier files and isn't freed. The caller gets a return value of 0 (failure) but a partially populated erp struct. Cleaner would be to free erp->data and zero erp->n/erp->nmax before returning 0 in that path, for consistency.
3. Char *efiles[MAXEXFILE] on the stack is 8KB of pointers (MAXEXFILE=1024), plus MAXEXFILE×1024 bytes heap — so 1MB of heap just to hold the path list. That's fine for a desktop app but worth being aware of.

[ourairquality]

A few comments from Claude AI, your thoughts?

1. Return value when no files match. If expath() returns 0 (path doesn't match anything — e.g. a typo), the loop doesn't execute and the function returns 1 (success) with no data added. The old code returned 0 on fopen failure. This behavioral change silently swallows bad path configuration, which could cause hard-to-diagnose issues downstream when ERP corrections are silently missing.

Have adopted this, changing the return value to be the number of files from which data is read, so even reading an empty file would flag an issue.

2. Partial state on fopen failure mid-loop. If files 0..i-1 load successfully but fopen fails on file i, the function returns 0 but erp->data already contains records from the earlier files and isn't freed. The caller gets a return value of 0 (failure) but a partially populated erp struct. Cleaner would be to free erp->data and zero erp->n/erp->nmax before returning 0 in that path, for consistency.

Suggest keeping all the data read even if there is some issue, but it now only returns the count of files from which data is read so that if there is a file that can be opened but it fails to read the data from then that can flag an error. Have not added a warning output for each file that has not data read, but could trivially do that too.

3. Char *efiles[MAXEXFILE] on the stack is 8KB of pointers (MAXEXFILE=1024), plus MAXEXFILE×1024 bytes heap — so 1MB of heap just to hold the path list. That's fine for a desktop app but worth being aware of.

Can live with this. Once consider adopting a string library with memory management but gave up - this is C and it uses static memory allocation and it seems simplest this way. A higher level language would manage string allocation automatically.