thanks
I had already done this but did not post an update
(I'll make a note to myself to post new source packages
for all source affected by an api change)
I will post all new source packages tuesday
sorry you went through this when it was already done
next time send a note to the list first
our goal from this year on is to be forward+backward compatible
with all our library apis -- if that isn't the case we want to
know about it
packages may delay switching to new apis by adding
LIBRARY:YYYYMMDD to the :PACKAGE: assertion in the affected makefiles:
:PACKAGE: LIBRARY:YYYYMMDD
this freezes the LIBRARY api to YYYYMMDD
for the libast path*() set of changes this would preserve the previous api
:PACKAGE: ast:20100309
this is what ksh93u- has done -- it will change sometime this year, but not
just yet
the new libast path*() api adds a size_t arg for the char* buffer return value
the previous api assumes buffers are PATH_MAX (defined by ast if not defined in
the
standard headers)
also there's a subtle bug in your patch
cia coding style uses MAX_PATH, not PATH_MAX
On Sat, 4 Sep 2010 12:15:53 +0200 Philippe Bergheaud wrote:
> I have applied the following patch to compile ast-cql with the latest
> ast-base.
> You may want to update ast-cql for the next release.
> diff -ru old/src/cmd/cia/ciald.c new/src/cmd/cia/ciald.c
> --- old/src/cmd/cia/ciald.c 2009-04-22 11:37:19.000000000 +0200
> +++ new/src/cmd/cia/ciald.c 2010-09-04 11:40:20.000000000 +0200
> @@ -116,7 +116,7 @@
> {
> sfsprintf(newlib, MAX_ID, "lib%s.A",
> opt_info.arg);
> libpath=ciamalloc(MAX_PATH);
> - if (!pathaccess(libpath, libdirs, newlib,
> 0, PATH_READ))
> + if (!pathaccess(libpath, libdirs, newlib,
> 0, PATH_READ, PATH_MAX))
> error(ERROR_ERROR, "can't find
> library database %s", newlib);
> else
> insert_list(liblist, (VOID
> *)libpath);
_______________________________________________
ast-users mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-users
