Stas Bekman wrote:
> On Sun, 11 Feb 2001, Brian Ingerson wrote:
> > Let me know if that works. I'll keep working on the code.
> It works fine for me now. This is my little module that throws SIGSEGV :)
>
> package Apache::Segv;
>
> use strict;
> BEGIN {
> $Apache::Segv::VERSION = '0.01';
> }
>
> use Inline Config => UNTAINT => 1;
> use Inline C => <<'END_OF_C_CODE';
> void segv(){
> int *p;
> p = NULL;
> printf("%d",*p); // cause a segfault
> }
>
> END_OF_C_CODE
>
> 1;
Stas,
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<----
>
> 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)
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.
>
> 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.
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.
> 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.
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.
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.
>
> Thank you again! Keep up on working on this great module!
Yup. Thanks for putting it to good use.
Cheers, Brian
--
perl -le 'use Inline C=>q{SV*JAxH(char*x){return newSVpvf
("Just Another %s Hacker",x);}};print JAxH+Perl'
