On Sat, 29 Jun 2013 21:24:24 +0200 Irek Szczesniak wrote:
> On Sat, Jun 29, 2013 at 12:37 AM, Cedric Blancher
> <[email protected]> wrote:
> > 2013/6/28 Glenn Fowler <[email protected]>:
> >>
> >> the AT&T Software Technology ast alpha 2013-06-28 source release
> >> has been posted to the download site
> >> http://www.research.att.com/sw/download/alpha/
> >> the package names and md5 checksums are
> >> INIT eddbf89d061348519d86f2618b708a94
> >> ast-base a745a7d4ce6f53c2e4134af4cc835ff7
> >> ast-open fdb74839ff041e34c800c333188a050e
> >> ast-ksh 8f22428cf30af7146bd210664c2fd166
> >> the md5 sums should match the ones listed on the download page
> >
> > The release is unusable. The new "API" - if it can be called like that
> > - added wrappers to all syscalls via #define, which breaks down on
> > OpenBSD or other platforms which already use #defines for security
> > wrappers. It's also undebuggable by adding yet another layer of hidden
> > complexity. I wouldn't mind if if the code would call _ast_open() and
> > friends directly but hiding it via #define open _ast_open collides
> > with too many other things, including system libraries and the ability
> > of normal minds to grok it.
> >
> > So this won't fly.
> Well, I hope this is a one time experiment which is better not going
> to be repeated. The whole concept of the intercepts is utterly broken
> by design and can't even work in real life. I still having hiccups
> from this code:
> #define RESTART(r,f) \
> do { \
> uint32_t serial; \
> do \
> { \
> serial = asoget32(&GLOBAL(restart)); \
> } while ((r = f) == -1 && errno == EINTR && (serial ==
> AST_SERIAL_always || serial != asoget32(&GLOBAL(restart)))); \
> } while (0)
> Why? This is mixing process and thread semantics with signal restart
> functionality even for syscalls which never return EINTR. The code is
> prone to integer overflows, too.
granted the aso calls may be overkill but for *alpha* testing I wanted to make
sure that even in non-threaded apps a signal didn't catch the code mid-increment
I wish statements like "broken", "prone to" would be accompanied by code
in particular, where is this code prone to integer overflow?
> Another two 'gems':
> int
> ast_eaccess(const char* path, int mode)
> {
> int r;
> RESTART(r, faccessat(LOCAL(pwd), path, mode, AT_EACCESS));
> return r;
> }
> int
> ast_faccessat(int cwd, const char* path, mode_t mode, int flags)
> {
> int r;
> RESTART(r, faccessat(cwd, path, mode, flags));
> return r;
> }
> The first form (ast_eaccess) is redundant since faccessat() has become
> available and should be mapped via a macro to ast_faccessat().
> Otherwise you're producing code bloat.
ast provides eaccess() in its portability layer and will continue to do so
*at() are still not universal so we chose to uniformly intercept calls
if eaccess() becomes a problem in the future we can deal with it then
one of the goals of this release was to leverage a lot of debugging hooks
with minimal source code change -- it is most likely not in official final
release form
> Finally, cd(1) is broken for error cases and returns garbage.
this is probably due to missteps in the first release of *at() emulation
roland finds some of those problems in subsequent posts
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
