[Bug-apl] Quad_SVx.cc some border line condition.
Hello Juergen,
in Quad_SVx.cc around line 570:
char filename[APL_PATH_MAX + 1];
int slen = snprintf(filename, APL_PATH_MAX, "%s/%s",
dirname, entry->d_name);
if (slen >= APL_PATH_MAX) filename[APL_PATH_MAX] = 0;
filename will be returned at most APL_PATH_MAX chars long including
\0-termination.
So line -3- will do nothing as filename[APL_PATH_MAX-1] is already '\0'
dirname is defined as char dirname[APL_PATH_MAX + 1];
Just as a sidestep: If dirname was set to APL_PATH_MAX characters +
final \0, then
the resulting filename will be filled with a truncated path (one char
less ),
the following '/' and d_name are being discarded, resulting in an
invalid filename .
Here is my take:
dirname is 4096+1 chars long
entry->d_name is 256 chars long
So the max length of filename could then be APL_PATH_MAX(%s)+ 1 (/) +
255 (%s) +1 (\0). -> 4353 bytes long.
snprintf strips the trailing \0s from the input and adds one.
// PATH + / + NAME + \0
enum { FN_MAX_LENGTH=APL_PATH_MAX +1 +255 +1};
char filename[FN_MAX_LENGTH ];
snprintf(filename,FN_MAX_LENGTH , "%s/%s", dirname,
entry->d_name);
Again, I did not dig deeper into the code/spec to find out whether the
maximum filename length
should be 4096+1 bytes, then dirname has to be 4k-256byte long ,
or whether the maximum filename length should be 4353 bytes.
Best regards
Hans-Peter
Re: [Bug-apl] Issues building with GCC 8.1.1
Hi Fred,
thanks, that explains it.
Fixed in SVN 1052.
Best regards,
/// Jürgen Sauermann
On 05/24/2018 09:18 PM, Fred Weigel
wrote:
Juergen
Thanks! All worked, except (as you suspected) Svar_record. Here is the
error message from GCC 8.1.1:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -Wall -I sql -Wold-
style-cast -Werror -I/usr/include -I/usr/include -rdynamic -O3 -MT
libapl_la-Archive.lo -MD -MP -MF .deps/libapl_la-Archive.Tpo -c
Archive.cc -fPIC -DPIC -o .libs/libapl_la-Archive.o
In file included from Svar_DB.hh:32,
from Symbol.hh:30,
from SystemVariable.hh:26,
from Quad_RL.hh:24,
from Workspace.hh:32,
from Archive.hh:28,
from Archive.cc:29:
Svar_record.hh: In member function 'void Svar_record::clear()':
Svar_record.hh:183:56: error: 'void* memset(void*, int, size_t)'
clearing an object of non-trivial type 'struct Svar_record'; use
assignment or value-initialization instead [-Werror=class-memaccess]
void clear() { memset(this, 0, sizeof(Svar_record)); }
^
Svar_record.hh:174:8: note: 'struct Svar_record' declared here
struct Svar_record
^~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1176: libapl_la-Archive.lo] Error 1
Fred Weigel
On Thu, 2018-05-24 at 13:53 +0200, Juergen Sauermann wrote:
Hi Fred,
thanks, hopefully fixed in SVN 1051.
The -Wclass-memaccess warning is not documented in the gcc 8,1
manual, therefore
the warnings in Svar_record.cc and/or Svar_record.hh may have
survived my attempt
to fix them. If so, then please send me the complete warning output
(containing the
source line number) so that I can give it another try.
Best regards,
/// Jürgen
On 05/23/2018 09:45 PM, Fred Weigel wrote:
I just updated to Fedora 28. Had some issues compiling GNU APL
__ _ __ __ _____ __
/ // | / // / / / / | / __ \ / /
/ / __ / |/ // / / / / /| | / /_/ // /
/ /_/ // /| // /_/ / / ___ | / // /___
\//_/ |_/ \/ /_/ |_|/_//_/
Welcome to GNU APL version 1.7 local / 1050M
Copyright (C) 2008-2016 Dr. Jürgen Sauermann
Banner by FIGlet: www.figlet.org
This program comes with ABSOLUTELY NO WARRANTY;
for details run: apl --gpl.
This program is free software, and you are welcome to
redistribute
it
according to the GNU Public License (GPL) version 3 or
later.
DUMPED 2017-08-06 18:41:50 (GMT-4)
Note that this has some local changes (memory mapping support, and
somea
other minor changes), thus the designation "1.7 local".
But, these notes apply to the unaltered version 1050 as well (and
the
pragma notes apply to 1047).
c++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying
conditions. There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
This version of GCC is more stringent. The following pragmas can be
added to successfully compile:
LibPaths.cc:#pragma GCC diagnostic ignored "-Wstringop-truncation"
Quad_SVx.cc:#pragma GCC diagnostic ignored "-Wformat-truncation"
Svar_DB.cc:#pragma GCC diagnostic ignored "-Wformat-truncation"
Svar_record.cc:#pragma GCC diagnostic ignored "-Wformat-truncation"
Svar_record.hh:#pragma GCC diagnostic ignored "-Wclass-memaccess"
If RATIONAL_NUMBERS_DEFINED is defined:
FloatCell.cc line 527
const FloatCell inv_B(denom, numer);
should be
const FloatCell inv_B(B_denom, B_numer);
IntCell.cc line 533
const APL_Integer b = get_int_value();
should be
APL_Integer b = get_int_value();
and
const APL_Integer a = A->get_int_value();
should be
APL_Integer a = A->get_int_value();
(these, because of a = -a and b = -b)
Fred Weigel
signature.asc
Description: OpenPGP digital signature
Re: [Bug-apl] libapl load problem....UPDATE 3
Hi Peter, I am not familiar with the details of all file types, but it seems like your understanding is correct. I should have added some more details in my last email: Say you have an application APP (your main() program) and a library LIB (in our case libapl). If you link APP and LIB (at compile time) then the undefined symbols in APP are matched against the symbols defined in LIB and the undefined symbols in LIB are matched against the symbols defined in APP. There are two possible outcomes of the linking: 1. there are still undefined symbols left in either APP or in LIB, 2. all symbols that were undefined before the linking are now resolved. Case 1 produces a linker error unless you tell the linker that you expect remaining undefined symbols (a so-called incremental link). An incremental link is kind of an intermediate result that requires more files to be linked to the intermediate result. Case 2 is the final result of zero or more incremental links. An executable must not have undefined symbols, so if a linker result is (supposed to be) an executable the the linker will report an error. This is what happened in you example: your APP has an undefined symbol init_libapl. This symbol is undefined in APP and defined in LIB. However, the fact that it is defined in LIB does not help you because you only dlopen() LIB in APP (which happens later at runtime) but you did not link LIB and APP. But the linker was not even able to produce APP and therefor the fact that LIB contains the undefined symbol (at runtime) does not satisfy the linker at runtime. What you need to get your example running is the linker option -lapl. -lapl is equivalent to -l apl and also to its easier to understand long form --library=apl. It tells (by convention) the linker to include the files libapl.a or libapl.so (if present) in the linking of the object files given to the linker. If you link with -lapl, then the linker will resolve the undefined symbol init_libapl at compile time (more precisely: at link time) and dlopen()ing libapl does not do any good because we are in case 2 already. Best regards, /// Jürgen On 05/24/2018 11:00 PM, Peter Teeson wrote: Although I've lived in the Apple Xcode world for the last many years, I am not afraid of the command line. So I’m trying to learn more about the way GNU APL is built from the command line using the autotools suite. In particular building GNU APL as a library using the —with-libapl configures option. I’ve run into some new file extensions in examining things and I would like confirmation that my understanding of their meaning: Difference Between PIC, .o, .a, .lo, .so, .po (Po), .tpo (.TPo), .plo (Plo), (.TPlo). Executive Summary PIC is position independent code .o is typically a non-PIC object file emitted by the compiler (before linker stage) When linked with an exe, the code will be included in the executable -- we bind at link time. .a is typically an archive library containing one or more .o files [non-PIC]. When linked with an exe, the particular "*.o" files in the archive will be inserted into the executable. .lo is generally a "library object" that contains PIC code whether manually compiled with gcc -fPIC or using libtool. .so files are "shared object" files. They contain PIC objects. .po (.Po) text files describing object files .tpo (.TPo) temporary text files describing object files .plo (.Plo) text file describing library object file .tplo (.TPlo) text file describing temporary library object Am I correct? Thanks & respect… Peter On May 20, 2018, at 4:59 PM, Dirk Laurie wrote: 2018-05-20 21:44 GMT+02:00 Juergen Sauermann : As far as I understand, there are two ways to link libapl with your application: 1. link it at compile time (with the -lapl linker option) or 2. dlopen() it at runtime (your approach). In case 2. the symbol init_libapl is NOT resolved by dlopen() but has to be resolved via dlsym() and then called with the return value of dlsym(). There might also exist some (usually platform specific) linker options that cause dlopen() to resolve all symbols provided in a shared library automatically, but I don't know. I should mention that libapl is mainly a work of Dirk Laurie, I suppose he does not use dlopen(), but uses approach 1. Maybe Dirk can give you some more hints
Re: [Bug-apl] Quad_SVx.cc some border line condition.
Hi Hans-Peter,
these changes were introduced recently and only to suppress newly
introduced warnings in gcc 8.1.
So, yes, line 3 does nothing, but in order to suppress the
warnings one has
to use the return value of snprintf somehow.
The way I read
https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html#Warning-Options
seems to suggest that somehow means to set the
terminating 0 of the snprintf() result
buffer with the return value of snprintf().
The background of APL_PATH_MAX = 4096 is that unfortunately
various #include
files under /usr/include (even on the same platform) define
PATH_MAX differently,
ranging from 128 to 4096. Therefore, even though the theoretical
path length can
become > 4096 the underlying file system will not be able to deal
with it and then
it makes no difference if a file system call fails due the path
being truncated or too long.
Best Regards,
/// Jürgen
On 05/25/2018 12:00 PM, Hans-Peter
Sorge wrote:
Hello Juergen,
in Quad_SVx.cc around line 570:
char filename[APL_PATH_MAX + 1];
int slen = snprintf(filename, APL_PATH_MAX, "%s/%s",
dirname, entry->d_name);
if (slen >= APL_PATH_MAX) filename[APL_PATH_MAX] = 0;
filename will be returned at most APL_PATH_MAX chars long including
\0-termination.
So line -3- will do nothing as filename[APL_PATH_MAX-1] is already '\0'
dirname is defined as char dirname[APL_PATH_MAX + 1];
Just as a sidestep: If dirname was set to APL_PATH_MAX characters +
final \0, then
the resulting filename will be filled with a truncated path (one char
less ),
the following '/' and d_name are being discarded, resulting in an
invalid filename .
Here is my take:
dirname is 4096+1 chars long
entry->d_name is 256 chars long
So the max length of filename could then be APL_PATH_MAX(%s)+ 1 (/) +
255 (%s) +1 (\0). -> 4353 bytes long.
snprintf strips the trailing \0s from the input and adds one.
// PATH + / + NAME + \0
enum { FN_MAX_LENGTH=APL_PATH_MAX +1 +255 +1};
char filename[FN_MAX_LENGTH ];
snprintf(filename,FN_MAX_LENGTH , "%s/%s", dirname,
entry->d_name);
Again, I did not dig deeper into the code/spec to find out whether the
maximum filename length
should be 4096+1 bytes, then dirname has to be 4k-256byte long ,
or whether the maximum filename length should be 4353 bytes.
Best regards
Hans-Peter
signature.asc
Description: OpenPGP digital signature
Re: [Bug-apl] libapl load problem....UPDATE 3
Hi Jürgen: Thank you for the additional information. I am doing a deep dive into a few things on macOS. (1) How to statically link libapl.so (2) How to link libapl.so so that addresses are resolved at load time - (dlopen and friends) (3) How to link libapl.so at run time (passing environment variable at execute time) Why bother? Because there is insufficient documentation for GNU APL with examples. If I manage to complete these tasks then I can document them for posterity. I also have a few ideas for having a user interface other than Terminal (a.k.a. Command Line). Also I will try to understand if I need to change the file extension from .so to .dylib. That’s Apple’s dynamic library extension — typical Apple arrogance…. IMHO it should not be necessary…. the Unix linker is capable of sorting things out. Flashback: The last time I worked at this low a level was when I hacked mainframe IBM 360 OS’ and coded in Assembly and had to understand //DD… commands — back in the 60’s. Never needed to for Macintosh….or anyUnix for that matter. respect Peter On May 25, 2018, at 8:48 AM, Juergen Sauermann wrote: > > Hi Peter, > > I am not familiar with the details of all file types, but it seems like your > understanding is correct. > > I should have added some more details in my last email: > > Say you have an application APP (your main() program) and a library LIB (in > our case libapl). > > If you link APP and LIB (at compile time) then the undefined symbols in APP > are matched against > the symbols defined in LIB and the undefined symbols in LIB are matched > against the symbols defined in APP. > There are two possible outcomes of the linking: > > 1. there are still undefined symbols left in either APP or in LIB, > 2. all symbols that were undefined before the linking are now resolved. > > Case 1 produces a linker error unless you tell the linker that you expect > remaining undefined symbols > (a so-called incremental link). An incremental link is kind of an > intermediate result that requires more files > to be linked to the intermediate result. > > Case 2 is the final result of zero or more incremental links. An executable > must not have undefined symbols, > so if a linker result is (supposed to be) an executable the the linker will > report an error. This is what happened > in you example: your APP has an undefined symbol init_libapl. This symbol is > undefined in APP and defined in LIB. > However, the fact that it is defined in LIB does not help you because you > only dlopen() LIB in APP (which happens later > at runtime) but you did not link LIB and APP. But the linker was not even > able to produce APP and therefor the fact > that LIB contains the undefined symbol (at runtime) does not satisfy the > linker at runtime. > > What you need to get your example running is the linker option -lapl. -lapl > is equivalent to -l apl and also to > its easier to understand long form --library=apl. It tells (by convention) > the linker to include the files libapl.a or > libapl.so (if present) in the linking of the object files given to the linker. > > If you link with -lapl, then the linker will resolve the undefined symbol > init_libapl at compile time (more precisely: at link > time) and dlopen()ing libapl does not do any good because we are in case 2 > already. > > Best regards, > /// Jürgen > > > On 05/24/2018 11:00 PM, Peter Teeson wrote: >> Although I've lived in the Apple Xcode world for the last many years, I am >> not afraid of the command line. >> So I’m trying to learn more about the way GNU APL is built from the command >> line using the autotools suite. >> In particular building GNU APL as a library using the —with-libapl >> configures option. >> >> I’ve run into some new file extensions in examining things and I would like >> confirmation that my understanding of their meaning: >> >> Difference Between PIC, .o, .a, .lo, .so, .po (Po), .tpo (.TPo), .plo (Plo), >> (.TPlo). >> Executive Summary >> PIC is position independent code >> .o is typically a non-PIC object file emitted by the compiler (before >> linker stage) >> When linked with an exe, the code will be included in the executable -- >> we bind at link time. >> .a is typically an archive library containing one or more .o files >> [non-PIC]. >> When linked with an exe, the particular "*.o" files in the archive will >> be inserted into the executable. >> .lo is generally a "library object" that contains PIC code whether >> manually compiled with gcc -fPIC or using libtool. >> .so files are "shared object" files. They contain PIC objects. >> .po (.Po) text files describing object files >> .tpo (.TPo) temporary text files describing object files >> .plo (.Plo) text file describing library object file >> .tplo (.TPlo) text file describing temporary library object >> >> Am I correct? >> >> Thanks & respect… >> >> Peter >> >>> On May 20, 2018, at 4:59
