I still get core dumps even after including the shcmd header and SHLIB(ksh)per
your post today.
Perhaps you would be so good as to point out what I am doing wrong in this
simple ksh93 plugin which uses the libsum sha512sum routine. I must not
beunderstanding something.
--------------------------- code --------------------------------#include
<shell.h>#include <shcmd.h> // New#include <ctype.h>#include
<error.h>#include <sum.h>
#define SH_DICT "libhash" // NEW
static const char sha512_usage[] = "[-?\n@(#)$Id: sha512sum 2010-08-02 $\n]"
"[-author?James Joyce <joyceATulyssesDOTcom>]"
"[-licence?http://www.opensource.org/licenses/cpl1.0.txt]"; "[+NAME?sha512sum
- generate an SHA512 hash.]" "\n" "[+EXIT STATUS?] {" "[+0?Success.]"
"[+>0?An error occurred.]" "}";
SHLIB(ksh) // NEW
static intmakehash( int mode, const char* path){ Sfio_t* sp;
char* s; int r;
static Sum_t* sum = (Sum_t *)NULL;
switch (mode) { case 1: if ((sum = sumopen("sha1")) ==
NULL) error(3, "SHA1 initialization error"); break;
case 5: if ((sum = sumopen("md5")) == NULL)
error(3, "MD5 initialization error"); break; case 256:
if ((sum = sumopen("sha256")) == NULL) error(3, "SHA256
initialization error"); break; case 384: if
((sum = sumopen("sha384")) == NULL) error(3, "SHA384
initialization error"); break; case 512: if
((sum = sumopen("sha512")) == NULL) error(3, "SHA512
initialization error"); break; default: return
1; }
suminit(sum); if (!(sp = sfopen(NiL, path, "r"))) return 1;
while (s = (char*)sfreserve(sp, SF_UNBOUND, 0)) sumblock(sum, s,
sfvalue(sp)); r = !!sfvalue(sp); if (sfclose(sp) || r) return 1;
sumdone(sum); sumprint(sum, sfstdout, 0, 0); sumclose(sum);
return 0;}
intb_sha512sum(int argc, char *argv[], void *extra){ char* infile;
NoP(argc); error_info.id = "sha512sum";
for (;;) { switch (optget(argv, sha512_usage)) {
case '?': error(ERROR_USAGE|4, "%s", opt_info.arg);
continue; case ':': error(2, "%s", opt_info.arg);
continue; } break; }
argv += opt_info.index;
if (error_info.errors || !(infile = *argv++)) error(ERROR_USAGE|4,
"%s", optusage(NiL));
return makehash(512, infile);}
voidlib_init(int c, void *context){ sh_addbuiltin("sha512sum", b_sha512sum,
0);}------------------------------------- cut here
-------------------------------
Here is the build script:
gcc -fPIC -g -I /work/ast/arch/linux.i386-64/include/ast -c hash.cgcc -shared
-W1,-soname,libhash.so -o libhash.so hash.o
/work/ast/arch/linux.i386/lib/libsum.a
> Date: Mon, 2 Aug 2010 11:02:02 -0400
> From: [email protected]
> To: [email protected]; [email protected]; [email protected]
> Subject: Re: [ast-developers] ksh93 dynamic builtins
> CC: [email protected]
>
>
> we recently ran into some nasty backwards/forwards compatibility problems
> between ast executables and link-time-dlls and plugin-dlls
>
> first some background on ast plugins
> plugins are divided into domains
> plugin domains are named by the main executable or library for the domain
> ast currently has these plugin domains
>
> codex open/read/write/close data transform methods
> dss data stream scan { types schemas queries }
> ksh ksh builtins
> pax archive formats
> pz pzip methods
> sort sort methods
> vcodex buffer=>buffer data transform methods
>
> each plugin domain has one or more dll/so files that contain the plugins
> each dll/so file contains one or more plugins
>
> for plugins the main problems are:
>
> (a) new executable old plugin
> (b) old executable new plugin
>
> to solve the problem each plugin domain has a current YYYYMMDD version stamp
> this stamp is defined as a macro in the domain plugin header (e.g., shcmd.h
> for ksh)
> the plugin version stamp is compiled into both the executable and plugins
>
> executables load plugins by the ast -ldll function dllplugin()
> which takes the plugin domain version stamp as an argument
> dllplugin() does a PATH relative search to find the plugin dll/so
> only plugin dlls/sos with version stamp >= the caller version stamp are
> accepted
> the search continues until a suitable version stamp is hit or none are found
>
> each plugin dll/so must have a function
> unsigned long plugin_version(void)
> that returns the plugin version stamp for all of the plugins it contains
> each domain plugin header has a macro that encodes this function
> for ksh its
> SHLIB(ksh)
> (the ksh is currently ignored) which expands to
> unsigned long plugin_version(void) { return SH_PLUGIN_VERSION; }
>
> we modified our plugin builds to have a file lib.c that contains
> the plugin_version() definition
>
> now the plugin-version >= caller-version test only works if the plugins
> are coded to preserve backwards compatibility -- ast pretty much over
> the years has retained backwards compatibility, but with the last release
> we put build/coding mechanisms in place to solidify backward compatibility
> -- more on that in a future note
>
> we burned an afternoon discussing backwards compatibility implementations
> an alternative for plugin version stamps would be to put the version in
> the plugin dll/so name -- we concluded this would have led to a pile
> of bit-rotting plugin dll/so files that would be hard to maintain and
> garbage collect -- with backwards compatibility properly implemented
> it will be safe to replace plugin dll/so files with the latest release
> and still maintain compatibility with old executables that use the plugins
>
> a note on ast section 3 documentation: one of my goals for the remainder of
> the summer is to document all of the ast library public functions
> I'll start with dll(3)
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
