On Tue, 13 Feb 2001, Brian Ingerson wrote:
> I prefer the following (syntax-wise):
>
> ----8<----
> package Apache::Segv;
> BEGIN {$VERSION = '0.01'}
> use strict;
>
> use Inline 'Untaint';
> use Inline 'C';
> 1;
>
> __DATA__
> __C__
> void segv(){
> int *p;
> p = NULL;
> printf("%d",*p); // cause a segfault
> }
> ----8<----
Ok, will use this one. thanks.
> > much simpler to show in the book, than writing and explaining all the XS
> > code :)
> >
> > Please tell me what will be the final syntax, so my book will have it
> > right when you release a next version. Is the one I've shown above is
> > fine?
>
> This will almost certainly be the final syntax. Remember though, Inline
> is still beta. You can read the mailing list archives for my future
> plans, but the basic major changes are:
>
> 1) Move the MD5 has keys out of the shared object name, and into a meta
> file.
> main_C_Foo_3ca433bcac47af48ef1a5479734b2ef3.so
> will become:
> Foo.so
> Foo.inline (contains 3ca433bcac47af48ef1a5479734b2ef3 and more)
very nice idea, current .so libs look ugly :)
> 2) Interactive debugging.
>
> 3) Add taint security ;)
:)
> I think your example is fine, but I still would be eager to review your
> final code, for both correctness and good examples of Inline.
OK, I'll send you the relevant code in private.
> > I'm also not clear about the SAFEMODE, does it mean that it uses Safe.pm?
> > Does it uses it during the build time only?
>
> SAFEMODE is runtime checking of parameters that are untainted to help
> prevent possible security flaws. UNTAINT just blindly turns off taint
> checking. That said, I still think Inline is fairly safe even with
> UNTAINT.
Oh, oh! So I must add it as well.
> Of course, SAFEMODE would not *guarantee* safety. It would do extra
> checking for known security risks. And yes, it would use Safe.pm for
> some of the testing.
Sure, we are mostly worried about run time problems in CGI code, not
install time, so no problem here.
> > I also was wondering about the overhead of runtime check. Writing in XS
> > might be a pain, but then you have no overhead at runtime. With Inline,
> > for each invocation there is MD5 compilation of the code and verification.
> > If I understand correctly, this happens at compile time, so if I preload
> > modules under mod_perl I get no run-time overhead. Is that correct?
>
> Inline, in principal, is optimized for speed. When code is precompiled,
> start up time should be minimal. When compilation is required, Inline
> uses as much time as it needs.
of course, I was talking about the case where there is no compilation
required.
> Older versions of Inline used Autoloading for quicker startup. I have
> temporarily abandoned Autoload until the major Inline development is
> complete. Then I will retune it for maximum performance. But Inline
> startup is still very fast. And, as you guessed, with mod_perl,
> everything happens at Perl compile time, so Inline is exactly as fast
> as XS.
great, that's what I wanted to know for sure :)
> In fact, Inline intends to fully replace XS for the general populace. I
> think that Inline can almost completely abstract XS. XS will become an
> implementation artifact (if I can help it :) And SWIG is not really much
> better than XS, at least for Perl only applications. So I would make the
> main emphasis be on Inline.
Wow! Gonna love it! Doug is using XS heavily to create mod_perl. Of course
one still have to learn perl API/macros to code extensions for perl. No
cheating here :(
> > Thank you again! Keep up on working on this great module!
>
> Yup. Thanks for putting it to good use.
Good and free things should get all the advertisement they can get :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
