ruby-talk

Thank you one and all! You are wonderful, and it is a pleasure and a joy to be able to get questions answered quickly from many experts. Without resources like this, learning a new language would not be as quick or easy...

2 messages 2000/05/30

[#3049] Re: Problem with getc under UNIX with ruby 1.4.3 — matz@... (Yukihiro Matsumoto) 2000/05/31

Hi,

[#3046] Thread.new vs. Thread.start — Dave Thomas <Dave@...>

2 messages 2000/05/30

[#3050] Re: Thread.new vs. Thread.start — matz@... (Yukihiro Matsumoto) 2000/05/31

Hi,

[#3047] Re: Thread.new vs. Thread.start — "Dat Nguyen" <thucdat@...>

1 message 2000/05/30

[#3048] eruby security problem? — Andrew Hunt <Andy@...>

2 messages 2000/05/30

[#3051] Re: eruby security problem? — matz@... (Yukihiro Matsumoto) 2000/05/31

Hi,

[#3052] FYI: Python Development Team Moves to BeOpen.com — "Conrad Schneiker" <schneiker@...>

Hi,

3 messages 2000/05/31

[#3065] Re: FYI: Python Development Team Moves to BeOpen.com — "Conrad Schneiker" <schneiker@...> 2000/06/01

Hi,

[#3053] Re: FYI: Python Development Team Moves to BeOpen.com — matz@... (Yukihiro Matsumoto) 2000/05/31

Hi,

[#3054] Re: Final for World Series: Python vs Ruby — Aleksi Niemel<aleksi.niemela@...>

Matz:

1 message 2000/05/31

[#3055] Re: Problem with getc under UNIX with ruby 1.4.3 — Aleksi Niemel<aleksi.niemela@...>

> on 00/05/30, "David Douthitt" <DDouthitt@cuna.com> writes:

1 message 2000/05/31

[#3056] Bug in HTTP close — Andrew Hunt <Andy@...>

2 messages 2000/05/31

[#3066] Re: Bug in HTTP close — Minero Aoki <aamine@...> 2000/06/01

Hi,

[#3057] Re: dev.rubycentral.com — Aleksi Niemel<aleksi.niemela@...>

> From: Aleksi Niemel

2 messages 2000/05/31

[#3060] class variable (Re: Re: dev.rubycentral.com) — matz@... (Yukihiro Matsumoto) 2000/05/31

Hi,

[#3058] FailureClass? — Aleksi Niemel<aleksi.niemela@...>

Question arising from the FAQ:

7 messages 2000/05/31

[#3061] Re: FailureClass? — "Hal E. Fulton" <hfulton@...> 2000/06/01

This seems like a good idea to me...

[#3062] Re: FailureClass? — Dave Thomas <Dave@...> 2000/06/01

"Hal E. Fulton" <hfulton@austin.rr.com> writes:

[#3063] Re: FailureClass? — Quinn Dunkan <quinn@...> 2000/06/01

[#3064] Re: FailureClass? — Dave Thomas <Dave@...> 2000/06/01

Quinn Dunkan <quinn@envy.ugcs.caltech.edu> writes:

[#3077] Re: FailureClass? — Quinn Dunkan <quinn@...> 2000/06/01

[#3085] Re: FailureClass? — matz@... (Yukihiro Matsumoto) 2000/06/02

Hi,

[#3059] Thread priorities — Dave Thomas <Dave@...>

5 messages 2000/05/31

[#3084] Re: Thread priorities — Dave Thomas <Dave@...> 2000/06/02

matz@netlab.co.jp (Yukihiro Matsumoto) writes:

[#3088] Re: Thread priorities — matz@... (Yukihiro Matsumoto) 2000/06/02

Hi,

[#3083] Re: Thread priorities — matz@... (Yukihiro Matsumoto) 2000/06/01

Hi,

[#3089] Re: Thread priorities — Dave Thomas <Dave@...> 2000/06/02

matz@netlab.co.jp (Yukihiro Matsumoto) writes:

[ruby-talk:02629] Re: Requiring more flexible require

From: Aleksi Niemel<aleksi.niemela@...>

Date: 2000-05-08 09:37:14 UTC

List: ruby-talk #2629

>|I lost my 24h internet connection permanently, so sorry for the delay :).

>Is it you?  mrilu <mrilu@ale.cx>? 

Yup. For a while :).

>for OS/2 port of Ruby, dynamic loadables are not in shared library
>format.

I see, these issues about portability were something I was waiting for.
Thanks for clarification.

>|Can you imagine program barrel.c using some routines from foo_wrap.c
>|directly? Or how about embedded Ruby programs? Could they possess some
need
>|to 'ld -lfoo_wrap'?

>In that case, foo_wrap.o should be linked statically into an embedding
>program.  Although static linking facility for Ruby extension is far
>from perfect.

What is the reason demanding static linking. Big library means huge wrapper
(with SWIG), and with dozens of embedded programs you're really having some
use for cheap, big hard drives. Should you? Or should you be able to link
dynamically instead?

>|foo.so, thus being clear. We might get some clarity by making bigger
>|difference like naming the foo.so to Foo.rso (denoting Ruby shared Object)
>|or something.
>Dynamic loading facility provided by the OS may require the fixed
>extension for dynamic loadables (for example `.dll').

This is probably not an issue, but I'm interested in anyway. Is it possible
to come up with "standard" way to name Ruby extensions. If there's no
compelling reason not to create a naming policy, I would vote for it. We
could have standard for each platform. But by no means would I like to
enforce this in any way. It's just good to have such guideline around.

>|Secondly, I would like to note that this is patch for require 'lib'
>|'init_name' not for finding libraries with appended 'lib' as it's not yet
>|"accepted" feature.
>I don't think I'm going to merge your `lib' prefix and arbitrary
>`init_name' features.  The former is no chance to be incorporated.
>The latter requires more discussion.

Completely agreed. I threw it just for discussion.

I have to state again this patch just allowed to name Init-function, it
didn't do any 'lib'-prefix handling. I think we reached consensus about
'lib'-prefix already, not to incorporate it. 

I'm not voting for flexible require. I just want to raise discussion and
hear valuable comments from better developers. 

One good feature of more flexible require: being able to name init routine
could allow one to have multiple initialization functions, say for different
subsets of functionality. In perl world somehow related idea could be

  use strict qw(subs vars);

>|Then, I see this patch incorporated few waiting-to-be-handled-bugfixes. I
>Do you mean [ruby-talk:02624]?

Yes and no, actually I made a mess :). Here I meant that I think these are
bugs which should be handled. Some code should be added to the middle row of
three successive '+...' rows. [ruby-talk:02624] was related anyway and
properly handled. Thanks for it.

--- ruby\dln.c	Mon May 01 11:41:13 2000
+++ ruby.require\ruby\dln.c	Mon May 01 12:47:56 2000
@@ -98,7 +99,9 @@
 	if (*p == '/') slash = p;
 #endif
 
-    sprintf(buf, FUNCNAME_PATTERN, slash + 1);
+	if( snprintf(buf, maxlen, FUNCNAME_PATTERN, slash + 1) == -1 ){
+	  /* handle error: buffer size insufficient */
+	}
     for (p = buf; *p; p++) {         /* Delete suffix if it exists */
 	if (*p == '.') {
 	    *p = '\0'; break;
@@ -367,6 +383,9 @@
 	while (read(fd, p, 1) == 1) {
 	    if (*p == '\n' || *p == '\t' || *p == ' ') break;
 	    p++;
+	    if (p-buf >= MAXPATHLEN){
+	      /* some clever buffer overflow error handling */
+	    }
 	}
 	*p = '\0';



	- Aleksi

Thread

Prev Next

In This Thread

Prev Next