Hidden stopping-block (may bring a segfault) in read-table_lib

[willend]

Thanks to @Lomholy I have become aware of an issue in read-table_lib:

If an input file contains multiple data blocks, e.g.:

# Cu 111 
 2.087063  0.23391E+00 7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 200 
 1.80745  0.17544E+00  7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 220 
 1.27806  0.87718E-01  7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 311 
 1.089933  0.63795E-01 7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 400 
 0.903725  0.43859E-01 7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 331 
 0.829315  0.36934E-01 7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 420 
 0.808316  0.35087E-01 7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Cu 440 
 0.63903  0.21930E-01  7.485  2.094  0.55       11.81  63.54  315  12.00  0.30000E+00
# Ge 111 
 3.26665  0.87700E-01  8.42  1.216  0.18  22.63  72.6  290  9.0  0.15450E+00

• a natural way of loading such a file is via the function Table_Read_Array() which in turn calls Table_Read_Offset(). Each data block will result in a new "file" item being added to static t_Read_table_file_item read_table_file_list[1024];

For 20 component instances reading files of this type with 55 lines we are suddenly over 1024... And it seems there is apparently no check of this limit.

(Also, more on the level of an annoyance, we get a file-reading pr. data block ala Opening input file 'crystal_table.dat' (Table_Read_Offset) - this makes a lot...)

An improvement would be:

• static t_Read_table_file_item read_table_file_list[MAX_TABLE_FILES];
• A suitable define of MAX_TABLE_FILES (default 1024)
• A check of the boundary in the relevant place(s)
• Controlled termination with error message to increase MAX_TABLE_FILES
• A verbosity-switch to keep the number of Opening... lines under control