[ID 19991116.002] perl5.005_02: my_setenv() and Term::ReadLine::Gnu

Hi!

I've had a problem with perl5.005_02 and Term::ReadLine::Gnu dumping
core on a solaris 5.5.1 box.  A little bit of debugging revealed that 
readline-4.0 calls putenv(3) for LINES and COLUMNS during initialization.  
If these vars weren't present in the environment the call to putenv() 
changes the value of char **environ.  my_setenv() tests this value to
decide wether to copy the environment.  In my case it didn't copy and
thus dumped core on Safefree() as result of an assignment to $ENV{PATH}.

Patch appended.

Kind regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556




--- perl5.005_02/util.c.orig	Wed Nov 17 00:21:06 1999
+++ perl5.005_02/util.c	Wed Nov 17 00:21:50 1999
@@ -1413,12 +1413,14 @@
 my_setenv(char *nam, char *val)
 {
     register I32 i=setenv_getix(nam);		/* where does it go? */
+    static int copyenv = 1;
 
-    if (environ == PL_origenviron) {	/* need we copy environment? */
+    if (copyenv) {	/* need we copy environment? */
 	I32 j;
 	I32 max;
 	char **tmpenv;
 
+	copyenv = 0;
 	/*SUPPRESS 530*/
 	for (max = i; environ[max]; max++) ;
 	New(901,tmpenv, max+2, char*);
0
schuma
11/16/1999 11:42:22 PM
perl.perl5.porters 47902 articles. 1 followers. Follow

38 Replies
341 Views

Similar Articles

[PageSpeed] 24

Joerg Schumacher writes:
> 
> Hi!
> 
> I've had a problem with perl5.005_02 and Term::ReadLine::Gnu dumping
> core on a solaris 5.5.1 box.  A little bit of debugging revealed that 
> readline-4.0 calls putenv(3) for LINES and COLUMNS during initialization.  
> If these vars weren't present in the environment the call to putenv() 
> changes the value of char **environ.  my_setenv() tests this value to
> decide wether to copy the environment.  In my case it didn't copy and
> thus dumped core on Safefree() as result of an assignment to $ENV{PATH}.
> 
> Patch appended.
> 
> Kind regards,
> Joerg 
> 
> -- 
>  Gaertner Datensysteme                         38114 Braunschweig 
>  Joerg Schumacher                              Hamburger Str. 273a
>  Tel: 0531-2335555          		       Fax: 0531-2335556
> 
> 
> 
> 
> --- perl5.005_02/util.c.orig	Wed Nov 17 00:21:06 1999
> +++ perl5.005_02/util.c	Wed Nov 17 00:21:50 1999
> @@ -1413,12 +1413,14 @@
>  my_setenv(char *nam, char *val)
>  {
>      register I32 i=setenv_getix(nam);		/* where does it go? */
> +    static int copyenv = 1;
>  
> -    if (environ == PL_origenviron) {	/* need we copy environment? */
> +    if (copyenv) {	/* need we copy environment? */
>  	I32 j;
>  	I32 max;
>  	char **tmpenv;
>  
> +	copyenv = 0;
>  	/*SUPPRESS 530*/
>  	for (max = i; environ[max]; max++) ;
>  	New(901,tmpenv, max+2, char*);

Without further explanation I hardly think this is a solution.  The
real problem is that putenv() of Term::ReadLine::Gnu is mentioning a
wrong malloc()  [though I have no idea how this might have happened -
but it does, at least on Solaris 2.7].

Note that malloc.c of 5.005_62 already includes Perl_putenv().  Since
the default now is to have backward compatibility (including
overriding malloc()), we may need to byte a bullet and make Perl by
default override putenv() too (same as it is done for calloc():

#if POLLUTE...
#  define Perl_calloc calloc
#  define Perl_putenv putenv
#endif

).  I think this (and possibly strdup(),
for which Perl_strdup() is already in place) will fix 95% of problems
with mismatched malloc()s.

Ilya
0
ilya
11/17/1999 12:01:49 AM
--------
Hello Joerg, and long time no seeing you, Ilya.


Ilya> Without further explanation I hardly think this is a solution.  The
Ilya> real problem is that putenv() of Term::ReadLine::Gnu is mentioning a
Ilya> wrong malloc()  [though I have no idea how this might have happened -
Ilya> but it does, at least on Solaris 2.7].

I agree with you.  Something wrong around malloc().

But I feel strange by seeing the patch.

>> --- perl5.005_02/util.c.orig	Wed Nov 17 00:21:06 1999
>> +++ perl5.005_02/util.c	Wed Nov 17 00:21:50 1999
>> @@ -1413,12 +1413,14 @@
>> my_setenv(char *nam, char *val)
>> {
>> register I32 i=setenv_getix(nam);		/* where does it go? */
>> +    static int copyenv = 1;
>> 
>> -    if (environ == PL_origenviron) {	/* need we copy environment? */
>> +    if (copyenv) {	/* need we copy environment? */
>> I32 j;
>> I32 max;
>> char **tmpenv;
>> 
>> +	copyenv = 0;
>> /*SUPPRESS 530*/
>> for (max = i; environ[max]; max++) ;
>> New(901,tmpenv, max+2, char*);

The orignal code assumes

>> -    if (environ == PL_origenviron) {	/* need we copy environment? */

is true, only when my_setenv() is called at the first time only.  And
Joerg's patch should work as same as original code.  I do not
understand why the patch works.

Thank you.
--------
Hiroo Hayashi
0
hiroo
11/17/1999 6:10:56 PM
Hi!

> Ilya> Without further explanation I hardly think this is a solution.  The
> Ilya> real problem is that putenv() of Term::ReadLine::Gnu is mentioning a
> Ilya> wrong malloc()  [though I have no idea how this might have happened -
> Ilya> but it does, at least on Solaris 2.7].
> 
> I agree with you.  Something wrong around malloc().

Nope.  It's completly related to free()ing memory which hasn't been
malloc()'ed before.  There can't be such a thing like the "wrong
malloc()" since my perl has been build with "usemymalloc=n".  I'll 
append the testcase and perl version info. The test

	if (environ == PL_origenviron)

in util.c:my_setenv() assumes that the char **environ will only be
modified by perl itself.  This assumption doesn't always hold true if 
some Perl XS module calls putenv(3) before the first call to my_setenv().

> But I feel strange by seeing the patch.
>[...]
> >> -    if (environ == PL_origenviron) {	/* need we copy environment? */
> 
> is true, only when my_setenv() is called at the first time only.  And
> Joerg's patch should work as same as original code.  I do not
> understand why the patch works.

The patch works because it makes sure that perl only free()'s memory
that has been allocated before.  The test via a static variable is
stronger than the comparison to the saved environ pointer.

A workaround only for Term::ReadLine::Gnu would be the appended
patch.  It makes sure that LINES and COLUMNS are defined in the
environment before initializing the GNU Readline Library, so that  
putenv() hopefully doesn't need to modify the char **environ.  
Please keep in mind that this patch is only a workaound for the weak 
assumption in my_setenv().


Kind regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556


----------------------------------------------------------------------

--- Term-ReadLine-Gnu-1.07/Gnu.pm.orig  Wed Nov 17 23:22:59 1999
+++ Term-ReadLine-Gnu-1.07/Gnu.pm       Wed Nov 17 23:28:26 1999
@@ -159,6 +159,11 @@
     # set rl_readline_name before .inputrc is read in rl_initialize()
     $Attribs{readline_name} = $name;
 
+    # make sure that LINES and COLUMNS are defined in the environment 
+    # before initializing the GNU Readline Library
+    $ENV{LINES} = 25 if !defined($ENV{LINES});
+    $ENV{COLUMNS} = 80 if !defined($ENV{COLUMNS});
+
     # initialize the GNU Readline Library and termcap library
     $self->initialize();
 
----------------------------------------------------------------------
#!/tmp/perl/bin/perl -w
# dumps core if LINES and COLUMNS aren't defined in the env
use Term::ReadLine;
$RL = new Term::ReadLine 'foo';

$ENV{PATH} ="foo";
use vars qw($RL);
----------------------------------------------------------------------
Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=solaris, osvers=2.5.1, archname=sun4-solaris
    uname='sunos aunt 5.5.1 generic_103640-24 sun4u sparc '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O', gccversion=2.7.2.1
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldb -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Built under solaris
  Compiled at Nov 17 1999 23:34:56
  @INC:
    /tmp/perl/lib/5.00503/sun4-solaris
    /tmp/perl/lib/5.00503
    /tmp/perl/lib/site_perl/5.005/sun4-solaris
    /tmp/perl/lib/site_perl/5.005
    .

0
schuma
11/17/1999 10:59:01 PM
Hi!

> > The test
> > 
> > 	if (environ == PL_origenviron)
> > 
> > in util.c:my_setenv() assumes that the char **environ will only be
> > modified by perl itself.
> 
> How does it assume it?  Do you try to imply that environ may be
> changed before a call to perl_parse()?

No, the scenario is as follows:

   1) perl_parse() saves the pointer to the environment in PL_origenviron
   2) some extension interface (here Term::ReadLine::Gnu) is called
      and does modify the pointer to the environment via putenv(3)
   3) the perlscript tries to assign a new value to an environment
      variable and perl therefore calls my_setenv()
   4) my_setenv() does check if it needs to copy the environment but
      the check returns false since (environ != PL_origenviron)
   5) my_setenv() calls Safefree() and free()s some unallocated memory


Kind Regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556
0
schuma
11/17/1999 11:24:05 PM
Hi!

> > No, the scenario is as follows:
> > 
> >    1) perl_parse() saves the pointer to the environment in PL_origenviron
> >    2) some extension interface (here Term::ReadLine::Gnu) is called
> >       and does modify the pointer to the environment via putenv(3)
> >    3) the perlscript tries to assign a new value to an environment
> >       variable and perl therefore calls my_setenv()
> >    4) my_setenv() does check if it needs to copy the environment but
> >       the check returns false since (environ != PL_origenviron)
> >    5) my_setenv() calls Safefree() and free()s some unallocated memory
> 
> *What* it calls Safefree() on?  

Well, the appended perl-script-testcase had four lines of code, one of them is 

   $ENV{PATH} ="foo";

so the Safefree() has been called on environ[i] with i pointing PATH.  
The testcase dumps only core if LINES and COLUMNS aren't defined in the 
env before starting the script so that the putenv() called by 
set_lines_and_columns() in readline-4.0:shell.c has to call malloc() and  
therefore modifies the global var char **environ.

> How can it be that this is unallocated?

Since it has never been malloc()ed by perl due to the weak test in 
my_setenv()?

> Judging by what you wrote, you are running some old version of Perl,
> such as 5.005_03.  

This is the stable version, can't be that old?

> In 5.005_50 I can see that the only Safefree() is
> done on environ[i].  Due to documentation of putenv() I can see,
> environ[i] *should be* malloced.

But the free() is called with the pointer to a memory block which has
never been malloc()'ed by perl.  

> I think you need to concentrate on these questions.

free()ing some memory which has never been malloc()ed is asking
for trouble.  IMHO this is out of question.

Kind regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556
0
schuma
11/18/1999 12:08:34 AM
Hi!

> > But the free() is called with the pointer to a memory block which has
> > never been malloc()'ed by perl.  
> 
> You look utterly confused.  First you claim that this is not a problem
> with several mismatched malloc()s, now you say that it is.

Nope.  All I say is that you MUST NOT free() memory which hasn't been
malloc()ed before.  The memory block which perl tries to free() in
Safefree() is the original block passed via exec(2).  This block
hasn't been malloc()ed and therefore perl must not free() it.

> Please decide which way you want to argue first.  All you write
> confirms what we were explaining you several times: your Perl is using
> Perl's malloc(), and your patch has no relationship to how things happen.

Diddn't you get the output of my "perl -V"?  It clearly states
"usemymalloc=n".

Regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556
0
schuma
11/18/1999 12:31:11 AM
Joerg Schumacher writes:
> 
> Hi!
> 
> > > But the free() is called with the pointer to a memory block which has
> > > never been malloc()'ed by perl.  
> > 
> > You look utterly confused.  First you claim that this is not a problem
> > with several mismatched malloc()s, now you say that it is.
> 
> Nope.  All I say is that you MUST NOT free() memory which hasn't been
> malloc()ed before.  The memory block which perl tries to free() in
> Safefree() is the original block passed via exec(2).  This block
> hasn't been malloc()ed and therefore perl must not free() it.

Let me restate things to syncronize our understanding:

a) Perl uses PL_origenviron variable to understand when environ is malloc()ed.

   You do not claim that this scheme is broken (though AFAICS, it will
   work correct only if perl_parse is called only once).

b) Perl thinks that if environ is malloc()ed, then environ[i] is malloc()ed;

   You claim that this assumption is unwarranted.  This claim looks correct.

However, in view of the above two statements your patch is still
broken, since AFAICS it does not address existence of two different
questions.

Ilya
0
ilya
11/18/1999 3:09:44 AM
Hi!

> [...]
> > Nope.  All I say is that you MUST NOT free() memory which hasn't been
> > malloc()ed before.  The memory block which perl tries to free() in
> > Safefree() is the original block passed via exec(2).  This block
> > hasn't been malloc()ed and therefore perl must not free() it.
> 
> Let me restate things to syncronize our understanding:
> 
> a) Perl uses PL_origenviron variable to understand when environ is malloc()ed.
> 
>    You do not claim that this scheme is broken (though AFAICS, it will
>    work correct only if perl_parse is called only once).

On the contrary: I do believe that the check 

	(environ == PL_origenviron) /* need we copy environment? */

is broken.  This test would only be OK if perl itself could guarantee
that no extension module modifies environ behind the scene.

> b) Perl thinks that if environ is malloc()ed, then environ[i] is malloc()ed;
> 
>    You claim that this assumption is unwarranted.  This claim looks correct.

See above.

> However, in view of the above two statements your patch is still
> broken, since AFAICS it does not address existence of two different
> questions.

My patch is definitely broken since mg.c:magic_clear_all_env() has to
be fixed also.  Since there are two different functions preformig the
"need we copy environment?" check, the IMHO correct fix would need 
a global variable which indicates wether perl has already copied
the environment.

The following two testcases show the bug on my Solaris 5.5.1 box with 
perl5.00503, Term-ReadLine-Gnu-1.07 and readline-4.0:

-----------------------------------------------------------------
#!/tmp/perl/bin/perl 
# dumps core if LINES and COLUMNS aren't defined in the env:
#0  0xef5cc5a0 in _free_unlocked ()
#1  0xef5cc560 in free ()
#2  0x507b8 in Perl_safefree (where=0xeffffa79) at util.c:173
#3  0x550f4 in Perl_magic_clear_all_env (sv=0x0, mg=0xc98e0) at mg.c:785
#....
use Term::ReadLine;
$RL = new Term::ReadLine 'foo';
undef %ENV;
-----------------------------------------------------------------
#!/tmp/perl/bin/perl 
# dumps core if LINES and COLUMNS aren't defined in the env:
#0  0xef5cc5a0 in _free_unlocked ()
#1  0xef5cc560 in free ()
#2  0x507b8 in Perl_safefree (where=0xeffffcff) at util.c:173
#3  0x52af8 in Perl_my_setenv (nam=0xd0128 "PATH", val=0xd1890 "/foobar")
#   at util.c:1443
#....
use Term::ReadLine;
$RL = new Term::ReadLine 'foo';
$ENV{PATH} = "/foobar";
-----------------------------------------------------------------


I'm not familiar with the perl source so I leave it up to you to
invent a correct patch.

Regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556
0
schuma
11/19/1999 12:37:35 AM
On Fri, 19 Nov 1999, Joerg Schumacher wrote:

<--- my_setenv() problem --->

Maybe I should have piped in before, but I think someone else has
mentioned it : The whole my_setenv / putenv setup was modified somewhat
between 5.00503 and the current devcut due to a bug I reported about a
year ago. Thus, you should do the bugreport, testing and patching against
the latest devcut. Not 5.00503.

Rasmus

> The following two testcases show the bug on my Solaris 5.5.1 box with 
> perl5.00503, Term-ReadLine-Gnu-1.07 and readline-4.0:
> 
> -----------------------------------------------------------------
> #!/tmp/perl/bin/perl 
> # dumps core if LINES and COLUMNS aren't defined in the env:
> #0  0xef5cc5a0 in _free_unlocked ()
> #1  0xef5cc560 in free ()
> #2  0x507b8 in Perl_safefree (where=0xeffffa79) at util.c:173
> #3  0x550f4 in Perl_magic_clear_all_env (sv=0x0, mg=0xc98e0) at mg.c:785
> #....
> use Term::ReadLine;
> $RL = new Term::ReadLine 'foo';
> undef %ENV;
> -----------------------------------------------------------------
> #!/tmp/perl/bin/perl 
> # dumps core if LINES and COLUMNS aren't defined in the env:
> #0  0xef5cc5a0 in _free_unlocked ()
> #1  0xef5cc560 in free ()
> #2  0x507b8 in Perl_safefree (where=0xeffffcff) at util.c:173
> #3  0x52af8 in Perl_my_setenv (nam=0xd0128 "PATH", val=0xd1890 "/foobar")
> #   at util.c:1443
> #....
> use Term::ReadLine;
> $RL = new Term::ReadLine 'foo';
> $ENV{PATH} = "/foobar";
> -----------------------------------------------------------------
> 
> 
> I'm not familiar with the perl source so I leave it up to you to
> invent a correct patch.
> 
> Regards,
> Joerg 
> 
> -- 
>  Gaertner Datensysteme                         38114 Braunschweig 
>  Joerg Schumacher                              Hamburger Str. 273a
>  Tel: 0531-2335555          		       Fax: 0531-2335556
> 

-----------------------------------------------------------------------------
Rasmus.Tamstorf@disney.com         "A problem worthy of attack, 
Walt Disney Feature Animation       proves its worth by hitting back" Kumbel
-----------------------------------------------------------------------------

0
Rasmus
11/19/1999 12:58:22 AM
>I do not believe this.  At least the documentation I see 

So what?  It's only documentation, "peppered with wishful thinking,
known errors, unreadable sections, political propaganda and whatnot -
if we forget about omissions."

--tom
0
tchrist
11/19/1999 2:14:08 AM
>On Thu, Nov 18, 1999 at 07:14:08PM -0700, Tom Christiansen wrote:
>> >I do not believe this.  At least the documentation I see 
>> 
>> So what?  It's only documentation, "peppered with wishful thinking,
>> known errors, unreadable sections, political propaganda and whatnot -
>> if we forget about omissions."

>It was C topic.  C is a programming language.  Programming languages
>have a reliable documentation - this is what makes them programming
>languages.

>Hope this helps,

Oh.  I didn't realize Perl wasn't a programming language.  I'm pretty
sure that's what you just said.  

--tom
0
tchrist
11/19/1999 2:34:36 AM
On Thu, 18 Nov 1999 22:22:57 -0500
    Ilya Zakharevich <ilya@math.ohio-state.edu> wrote
    using Mutt 1.0pre2i
  in <19991118222256.A16955@monk.mps.ohio-state.edu>:

>On Thu, Nov 18, 1999 at 07:34:36PM -0700, Tom Christiansen wrote:
>> Oh.  I didn't realize Perl wasn't a programming language.  I'm pretty
>> sure that's what you just said.  

>You know perfectly well that Perl is not up to this category yet.

I know absolutely no such thing, and I challenge you to spell out very
precisely what the muddy shell you are talking about right here where
everyone you insult with your denigrations can hear you quite clearly.

Perl is a programming language.  Finis.

--tom
0
tchrist
11/19/1999 3:24:29 AM
Yitzchak Scott-Thoennes writes:
> 
> In article <19991118210401.A16532@monk.mps.ohio-state.edu>,
> Ilya Zakharevich <ilya@math.ohio-state.edu> wrote:
> >On Fri, Nov 19, 1999 at 01:37:35AM +0100, Joerg Schumacher wrote:
> >
> >I do not believe this.  At least the documentation I see states that
> >putenv() will malloc() environ if it needs to modify it.  Thus with
> >usemymalloc=n the test is OK as is.
> 
> Single UNIX V2 seems to say otherwise.  In particular it states that
> if you call putenv(string) and then later change string, the
> environment will be changed.

We are not discussing environ[i] here, we are discussing environ
itself.  You know, one of type char**.  The container for environment
variables. ;-)

Ilya

0
ilya
11/19/1999 9:00:24 AM
Quoting ilya@math.ohio-state.edu:
:On Thu, Nov 18, 1999 at 08:24:29PM -0700, Tom Christiansen wrote:
:> Perl is a programming language.  Finis.
:
:Says the same guy who claims that calling shell has no significant
:speed penalty, hash access is only 20% slower than lexicals, etc etc etc.
:
:Yeah, right...

And your point is exactly?...

How do you define a "programming language"? For me, it's a language I
can program whith. Programming meaning laying out instructions and having
a Turing machine process them, in a predictable and repeatable way.

Up to now:

    for (my $i = 0; $i < 10; $i++) {
        print "i = $i\n";
    }

has never failed to produce its expected output. And that's only one
of the numerous programs I've ever been writing in Perl for almost
10 years. ;-)

Perl IS a programming language. Period!

The mere fact that we even NEED to ARGUE about this is a sure sign that
there is a great mis-communication problem between p5p people.

Raphael
0
Raphael
11/19/1999 9:14:21 AM
>On Thu, Nov 18, 1999 at 08:24:29PM -0700, Tom Christiansen wrote:
>> Perl is a programming language.  Finis.

>Says the same guy who claims that calling shell has no significant
>speed penalty, hash access is only 20% slower than lexicals, etc etc etc.

So what's this, a strawman combined with argument ad hominem?

You have boldly declared that Perl is not a programming language,
thereby needlessly and baselessly insulting virtually everyone who works
on perl or in Perl.  Why did you do this?  What do you hope to gain?
What point are you really trying to make?  Is there something that we
can do to address whatever problem you're imagining exists, or are you
simply firing destructive missiles because it makes you feel good to
put Perl down like this?

You have also claimed that Perl's documentation is "peppered with wishful
thinking, known errors, unreadable sections, political propaganda and
whatnot - if we forget about omissions."  Not only is this insulting in
the extreme to anyone who has worked on Perl, it is also ludicroulsy
hypocritical coming from you, considering it is you yourself who so
often exacerbate the situation of crappy or missing documentation.
That you then summon up the breathtaking chutzpah to complain about the
very mess that you yourself have made is nothing short of amazing.

Again, what's the underlying purpose here?  Are you intentially *trying*
to alienate people, or is this an accident?  Is this some overly subtle
ploy to get people to clean things up?  Where are *your* patches, Ilya, or
even suggestions about the matter?  What do you propose be done about it?

What's the path forward?

--tom
0
tchrist
11/19/1999 5:00:31 PM
>Yes.  You cannot in Perl, since only 60% or so of operations are
>documented 

You keep saying that.  Please back it up with exact cites.  It sounds
completely terrible.  

(if you omit those things which are documented hopelessly
>wrong :-().  

I for one am sick and tired of listening to you cast aspersions on the
documentation without lifting a finger to even IDENTIFY the issues you're
dreaming up, let alone offering a patch.

>Did you ever use
>  $a = $b + $c;

Why yes.  I did.  Assuming unoverloaded and numeric operands, I expect
that it will conform to C's well-defined notions on integer and real
arithmetic as respectively applicable.  I understand that you don't
care for this, and have been trying to change it, but that's certainly
my expectation.

--tom
0
tchrist
11/19/1999 5:55:04 PM
>> Why yes.  I did.  Assuming unoverloaded and numeric operands, I expect
>> that it will conform to C's well-defined notions on integer and real
>> arithmetic as respectively applicable.

>What makes you expect this?

History.  Culture.  Precedent.  Sanity.  
0
tchrist
11/19/1999 5:57:50 PM
Hi!

> > On the contrary: I do believe that the check 
> > 
> > 	(environ == PL_origenviron) /* need we copy environment? */
> > 
> > is broken.  This test would only be OK if perl itself could guarantee
> > that no extension module modifies environ behind the scene.
> 
> I do not believe this.  At least the documentation I see states that
> putenv() will malloc() environ if it needs to modify it.  Thus with
> usemymalloc=n the test is OK as is.

You do know the difference between 

	free(environ)

and 
	free(environ[i])

don't you?  While the former would be safe after a call to putenv()
assumed that putenv() had to expand the environment via malloc() the
latter is certainly not covered by the putenv() specs.

Sigh, I'll put together a perl extension module as smallest possible
testcase and send it in so you folks may finally bother to reproduce
the bug.  FWIW, I can reproduce the problem also on linux with libc5
and libc6.

Regards,
Joerg 

-- 
 Gaertner Datensysteme                         38114 Braunschweig 
 Joerg Schumacher                              Hamburger Str. 273a
 Tel: 0531-2335555          		       Fax: 0531-2335556
0
schuma
11/19/1999 6:04:33 PM
>I see.  Anything but not documentation.  ;-)  I would call it guesswork.

>Now please explain what your guesswork will do with "as respectively
>applicable".  Then do the same with |.  Then do the same with printf
>'%d'.  Then with printf '%u'.

>Got the trend?

No, I don't.  I want you to take the time to spell these things out.
That's your job as squeaky wheel.  I know how printf(3) works,
and can read its man page should I be so inclined, as can anyone.
As I said, your "I know something I won't tell" attitude, especially
about the documentation, is worse than useless.  It is destructive.
Please contribute.

--tom
0
tchrist
11/19/1999 6:06:19 PM
>On Fri, Nov 19, 1999 at 07:04:33PM +0100, Joerg Schumacher wrote:
>> You do know the difference between 
>> 	free(environ)
>> and 
>> 	free(environ[i])
>> don't you?

>Please read what I wrote.

That's exactly the problem, Ilya.  Don't be so smug about it.
Spell things out for people.  

--tom
0
tchrist
11/19/1999 6:08:12 PM
>>Please contribute.

>Are you infering that I do not?  

I infer nothing, and as to what I imply, I prefer not to do that
when a simple statement will suffice.  As to what you might be
inferring, I can hardly control or anticipate that.

I shall state it again plainly: At a bare minimum, stop insulting us by
saying Perl isn't a programming language, or that its documentation 
is a full of dung.  Instead, be silent on the former matter and 
offer patches on the second one.

>And please explain how printf(3)
>relates to Perl.

I believe that following in your footsteps, the expected response 
is "If you don't know, then I'm not going to bother to tell you."
If it's good enough for you to pitch at others, I do hope you
don't mind receiving it.   

Oh.  You do mind?  I don't blame you.  So do the rest of us.
Perhaps you'd like to stop that crap, too.

well.  The answer is that Perl's printf function is directly descended
from C's function by the same name, and whensoever this should not prove
onerous, behaviours should follow accordingly.

--tom
0
tchrist
11/19/1999 6:12:51 PM
>If not, let's give this the
>same treatment that we gave to ??.

I believe your suggestion of tabling a proposal essentially sight
unseen constitutes bad precedent.  It should be tabled if it is found
to be technically undesirable after careful analysis.  I've pointed out
some problems with it.  Do these problems matter, or would you have us
not pursue the matter merely to avoid hurting my feelings?  That would
be terrible.  Please don't do that.  We haven't heard from Sarathy on
this yet.  I really don't find it's something worth jumping up and down
about.  I am not committed to pushing through any particular agenda here,
or any precise implementation.  I do think there are concerns that should
be duly considered before any commitment is made.  I would be delighted
to hear that the things that appear worrisome are no grave matter.

--tom
0
tchrist
11/19/1999 6:17:37 PM
Tom Christiansen writes:
> >> You do know the difference between 
> >> 	free(environ)
> >> and 
> >> 	free(environ[i])
> >> don't you?
> 
> >Please read what I wrote.
> 
> That's exactly the problem, Ilya.  Don't be so smug about it.
> Spell things out for people.  

Do you propose to spell things out for people who did not read what I
spelled out for them?  ;-)

Ilya
0
ilya
11/19/1999 6:21:10 PM
>Do you propose to spell things out for people who did not read what I
>spelled out for them?  ;-)

Yup.  

Sometimes rephrasing, reminders, and even repetition is essential to
essential education and clear communication -- which, I believe, would
be the goal here.

Feel free to correct me if that assumption (clear communication) has
taken back seat to some other goal.  And if you'd be so kind, while
you're at it, do please reveal that higher goal.

--tom
0
tchrist
11/19/1999 6:23:05 PM
Tom Christiansen writes:
> I shall state it again plainly: At a bare minimum, stop insulting us by
> saying Perl isn't a programming language, or that its documentation 
> is a full of dung.  Instead, be silent on the former matter

Do not "be silent" me.

> and offer patches on the second one.

Are you infering that I do not?  And given the treatement my doc
patches get, whey should I?

> >And please explain how printf(3) relates to Perl.

> I believe that following in your footsteps, the expected response 
> is "If you don't know, then I'm not going to bother to tell you."

> well.  The answer is that Perl's printf function is directly descended
> >from C's function by the same name, and whensoever this should not prove
> onerous, behaviours should follow accordingly.

I see.  So one needs to apply guesswork to understand what "proves
onerous" and what not.

You see, all your answers show that Perl is a good scripting language,
which basically means that in simplest cases the guesswork will
provide a useful approximation.

Ilya
0
ilya
11/19/1999 6:27:26 PM
Tom Christiansen writes:

> >Do you propose to spell things out for people who did not read what I
> >spelled out for them?  ;-)
> 
> Yup.  
> 
> Sometimes rephrasing, reminders, and even repetition is essential to
> essential education and clear communication -- which, I believe, would
> be the goal here.

 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00678.html

Ilya
0
ilya
11/19/1999 6:33:44 PM
>> Sometimes rephrasing, reminders, and even repetition is essential to
>> essential education and clear communication -- which, I believe, would
>> be the goal here.

> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/1999-11/msg00678.html

Wrong answer.   I see no rephrasing.  I see no communiation.  Thank you
for making your position clear, that in fact, you don't care to 
communicate.

--tom
0
tchrist
11/19/1999 6:34:02 PM
>Do not "be silent" me.

Very well, then explain then what useful purpose is served by your
irrepressible desire to hurl insults at Perl as being
"not a real programming language".

>> and offer patches on the second one.

>Are you infering that I do not?  And given the treatement my doc
>patches get, whey should I?

(Note for non-native speaker: imply and infer, like teach and learn,
differ in their direction, and are never interchangeable.  You meant
implying, not inferring.)

I am implying nothing.  I am stating that your insults on the Perl
documentation lead to no positive effect.  

And frankly, I in complete honesty cannot recall a recent instance in
which you submitted a corrective or explanatory documentation patch
against existing material, particularly one that was rejected, let alone
one that was rejected without cause.  Maybe my memory is selective,
but perhaps you should try harder.  If you invested as much energy in
fixing instead of bitching, you'd put yourself out of the job of bitching.
Or do you really enjoy that job overmuch?

>> well.  The answer is that Perl's printf function is directly descended
>> >from C's function by the same name, and whensoever this should not prove
>> onerous, behaviours should follow accordingly.

>I see.  So one needs to apply guesswork to understand what "proves
>onerous" and what not.

This is going nowhere.  Is that your goal?  Congratulations, you're
succeeding.  I'll take a patch over a bitch any day of the week.  Feel
free to send us more mail about this as soon as you have a constructive
documentation patch to offer.  But before that, I can't see that you've
got much to add that's contributory rather than inflammatory.

>You see, all your answers show that Perl is a good scripting language,

There you go again with that "not a real programming language crap".
Do you also subscribe to women's rights mailing lists and bombast them
with mysogynist tirades?  That would go over about as well as showing
up to a programming language's developer mailing list and telling them
that they aren't even good enough to be called a programming language.
That's nonsense.  Even were it true -- and it is demonstrably a viscious
and seditious lie -- it has no business being said in that forum.

--tom
0
tchrist
11/19/1999 6:41:51 PM
On Fri, 19 Nov 1999, Tom Christiansen wrote:

> >What makes you expect this?
> 
> History.  Culture.  Precedent.  Sanity.  

Not documentation?

Can't Tom and Ilya agree to disagree?  Can't Ilya be ignored when it's
worth ignoring?  Why does Tom spend so much time and energy putting down
the irrational or hasty thoughts and ideas of others, when we can all
judge for ourselves what's good and what's crud?  Is Perl 100%
deterministic as Ilya seems to think all real programming languages are?
Nah, but who the hell cares?  Oh, I guess "real programmers".  I'm happy
not to be a "real programmer" then, or I guess only a "real programmer"
when I program in C.  And of course, Tom cares, because after all, Ilya
said something out loud.

-Aaron

0
ajm6q
11/19/1999 6:52:57 PM
On Fri, 19 Nov 1999, Tom Christiansen wrote:

> (Note for non-native speaker: imply and infer, like teach and learn,
> differ in their direction, and are never interchangeable.  You meant
> implying, not inferring.)

I know you're some kind of linguistic expert (or at least have had some
training in linguistics), but I wonder if your analogy is correct?  I may
imply something, or I may infer something.  I may teach and I may learn.
If I ask you, "Are you inferring that my big toe is smelly?", I am in fact
asking if you have made some inference about my toe, based on some data
beknownst to you.  Sure, I could also have asked you, "Are you implying
that my big toe is smelly?", in which case I'm wondering whether you meant
to directly say my big toe was smelly, but chose otherwise. Both sentences
are grammatically correct and convey accurate meaning. There is no
directionality that I can observe.

I'm sure you'll now tell me how I've used the word "beknownst"
inappropriately.  Thanks.

-Aaron

0
ajm6q
11/19/1999 7:04:25 PM
>I know you're some kind of linguistic expert (or at least have had some
>training in linguistics), 

Most of my formal training was in various discrete languages, with only a
couple odd classes in general linguistics.  Larry's was more the other way
around.  Polyglot != Linguist, but sometimes one can fake the other.  :-)

>but I wonder if your analogy is correct?  

Yes, you can both be the teacher and the learner, the implyer and the
inferrer.  But that doesn't mean they're interchangeable.  Ilya was using
"infer" in places that I was pretty sure he meant "imply".  I suppose
could have read him the wrong way.  Wouldn't be the first time.

>I'm sure you'll now tell me how I've used the word "beknownst"
>inappropriately.  Thanks.

Although I would have just used "known" in that case, at least in most
circumstances, your word is clearly a back-formation from the more
commonly heard "unbeknownst", but doesn't show up in my online word list:

    % grep 'beknow' /usr/dict/words
    beknow
    beknown
    unbeknown
    unbeknownst

And the 'nst$' pattern isn't very common either:

    % grep 'nst$' /usr/dict/words
    against
    anenst
    canst
    chanst
    dunst
    Ernst
    forgainst
    fornenst
    forninst
    gainst
    thereagainst
    unbeknownst
    unknownst
    yinst

But I'm not one to get pwittertated about inventful and amusing coinings,
because if I did, you'd scold me for the several um, innovations, I
placed in the "use foo if bar" analysis, over the querulous objections
of my online word list. :-)

--tom
0
tchrist
11/19/1999 7:16:09 PM
On Fri, 19 Nov 1999, Jarkko Hietaniemi wrote:

> Wow, like so :-(  I'm contemplating of writing a filter that would hide
> any thread from me which (1) lasts for more than 10 messages (2) has more
> than two replies from I to T or vice versa...

Put it on CPAN if you do - I'd like to get some of that!

P5P::Tom::V::Ilya::Filter?

-sam

0
sam
11/19/1999 7:31:28 PM
> >I'm sure you'll now tell me how I've used the word "beknownst"
> >inappropriately.  Thanks.
> 
> Although I would have just used "known" in that case, at least in most
> circumstances, your word is clearly a back-formation from the more
> commonly heard "unbeknownst", but doesn't show up in my online word list:


Could you please explain to a non-native the 'st' suffix meaning ?

Thank you,

Fran´┐Żois
0
desar
11/19/1999 7:50:39 PM
Hi!

> <--- my_setenv() problem --->
> 
> Maybe I should have piped in before, but I think someone else has
> mentioned it : The whole my_setenv / putenv setup was modified somewhat
> between 5.00503 and the current devcut due to a bug I reported about a
> year ago. Thus, you should do the bugreport, testing and patching against
> the latest devcut. Not 5.00503.

OK. I did the tests using the appended extension module against
perl5.00562 on a linux box with nearly same results:

        o Dumps core if perl has been compiled with usemymalloc=n
        o Warns about "Bad free() ignored" if perl has been compiled
          with usemymalloc=y
        o The tests on solaris 5.5.1 dump core with both settings.

Joerg


#!/bin/sh
# This is a shell archive (produced by GNU sharutils 4.2).
# To extract the files from this archive, save it to some FILE, remove
# everything before the `!/bin/sh' line above, then type `sh FILE'.
#
# Made on 1999-11-19 20:43 MET by <schuma@aunt>.
# Source directory was `/tmp/src/free-bug'.
#
# Existing files will *not* be overwritten unless `-c' is specified.
#
# This shar contains:
# length mode       name
# ------ ---------- ------------------------------------------
#   1445 -rw-rw-r-- environbug-0.01.tar.gz
#   1510 -rw-rw-r-- perl-conf-with-perlmalloc
#   1510 -rw-rw-r-- perl-conf-without-perlmalloc
#
save_IFS="${IFS}"
IFS="${IFS}:"
gettext_dir=FAILED
locale_dir=FAILED
first_param="$1"
for dir in $PATH
do
  if test "$gettext_dir" = FAILED && test -f $dir/gettext \
     && ($dir/gettext --version >/dev/null 2>&1)
  then
    set `$dir/gettext --version 2>&1`
    if test "$3" = GNU
    then
      gettext_dir=$dir
    fi
  fi
  if test "$locale_dir" = FAILED && test -f $dir/shar \
     && ($dir/shar --print-text-domain-dir >/dev/null 2>&1)
  then
    locale_dir=`$dir/shar --print-text-domain-dir`
  fi
done
IFS="$save_IFS"
if test "$locale_dir" = FAILED || test "$gettext_dir" = FAILED
then
  echo=echo
else
  TEXTDOMAINDIR=$locale_dir
  export TEXTDOMAINDIR
  TEXTDOMAIN=sharutils
  export TEXTDOMAIN
  echo="$gettext_dir/gettext -s"
fi
touch -am 1231235999 $$.touch >/dev/null 2>&1
if test ! -f 1231235999 && test -f $$.touch; then
  shar_touch=touch
else
  shar_touch=:
  echo
  $echo 'WARNING: not restoring timestamps.  Consider getting and'
  $echo "installing GNU \`touch', distributed in GNU File Utilities..."
  echo
fi
rm -f 1231235999 $$.touch
#
if mkdir _sh10058; then
  $echo 'x -' 'creating lock directory'
else
  $echo 'failed to create lock directory'
  exit 1
fi
# ============= environbug-0.01.tar.gz ==============
if test -f 'environbug-0.01.tar.gz' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'environbug-0.01.tar.gz' '(file already exists)'
else
  $echo 'x -' extracting 'environbug-0.01.tar.gz' '(binary)'
  sed 's/^X//' << 'SHAR_EOF' | uudecode &&
begin 600 environbug-0.01.tar.gz
M'XL("!*G-3@"`V5N=FER;VYB=6<M,"XP,2YT87(`[5AM;]LV$/97\U<<E&RV
MBTZQ_`HD2U<GT;I@B6.D2=H/!5Q9HFPA$JE25%PCRW_?G23'3M>UVY!X1:$#
MC$1WY/%X1]X]1RYN`B7%))W^U#2;UD[E"0@ZS7ZW"Q4`L'J=_&\G_UM0$Z#?
MM+KM5KO3:J&TU>[U*]"M;(#21#L*H)*XLS1ROC2.JZ3RW1'_)/ZK;_/C8VW7
M:C9[1;P_&_]NOU/$O]EJMKHH[;::S0HTR_@_.6T%OL=]&(_=.$P3^C'^47,E
MP#@TX)9M<>$%/ML*A!NF'@?#?GMAGP_-F;'&B[D*'W+>OKX\R#E_47^WU+D:
M_G.BO4":LQ=K+*Z4R%A$IV='ER<V[,/J>-[GCM'@\/?!JX="QFYDX+$\IN,X
MU2BJ-UCU\.S(W@5VRZKN#*/^S(WW&/X?X^3("4/IUO&L-O98-8E5(+0/=3=^
M#L;(/C^QAU<'EZ_V.RV#Y`&*"K5NW&@`>D!)53=R'@UAU5S%D@=)ZKH\2?PT
M?"=HP!W[%N__J7/-_2#DYNCDT=;XVOVW^D7^MS#[=WJ9U.J7]W\SV^=@?]27
M.@B3W5V*/OW4'MN^XFHB4;H/%I[F-RK0?'DXZJQ:&PY.[5JUNO\":JLS5'N.
MDBO[_/7QV7#\Z_G9:>V3`68<X1@\_962OLGZ?VX/CD[MQUWC*_??LJSVLOY;
M_>S^M]N=;GG_-T$7LR"!V'&OG2D'CT=2)%HYFB?@4%$+@4JMXB&R/-`2](PO
MZVS$A3;9!3+\5+@ZP*D0+<8)SZLM.,*#$:H81\XT<,=NR!TUQBH[SL61LP`7
M/X'YBG-D2`$1&J`6(*2&K!QGJ]X$SK(Z-TP`QC*;9TX<<UP1*W$B(YX;2]!%
M)`%IDEX:<G`5+S8C^'S=<';CJ,"9X!!2OT0(,)\%[@P"`3I5N$1"6T:H(-`Y
MM/-I*"=."/=S63X1K<J6]R0N1>-\B>;.`S'%R=R])BT>ND5%@>!D<:`SY4Z(
MYGD+8*Z,`_+O0^?N,I9=$`(;!1OV]V%T,I8JF!:<!MQ6=Y[A]G#^'#<LX\6Z
MCE\`GNT4+D-':/`=S/2XLI[)=#K+[29;R.>?-P-WAT%FJST5\9H'&#POC6*<
MI[A9IO3OK/^+HPWAOW9GF?\1`/;ZU/]9O1+_;826J7\5=P1[BG](`T7`,)9*
M$QI<<HX6PCF1CD<\@HZ8"1/X,*^_/'X]@)?VV]'9^05L%P@085[&WZ<12UUK
M*DA>3,F&%&D8&H0^<Q4H,.A<&FA5DDZ6(V[AQP>]'=PQ-I%24^V*'^S%*J'F
MO[K_^@E>`/_#^U^OW2K?__Z?^-]#.%-O"/^W^JU5_)O9^Y_5+M__-O/^!P?<
M1_@&[R-L[A'YHCO"L`;4%7"%DB@#A/B9N"J(-22(&T,/)AQ4*D2&@N>!GK&M
M0@.!S)H)`Y]R_:=*[Z?/I;H&1)WO,_Q)<\PXK#&V]7<$;SA0I'2V6@[Y)R$6
M+\BZ"T+8V7L;=1$$<5-"I&C480[>+=.TT&8$L#02OT(GT6-:=ZSE.)]IXO#Z
ML<X:DPEW:04,NI^&!,`)$V?X&3T1R9N\&3)W<$/IQ,/*Z&IL7,P&8P?VJ^,A
M%JCM/[*7D\(J@PQX)XP]K%3V\`AN"S:A;GD-)()4A#Q)8#NDXNCMW64%=KV6
M%9+\1:904$S>^Y+K;&S$I+_NKLPUQP*/M(:%Q%8GVYHK/5XXJ3[AF@*8]RK9
M6DF^6-L@-R'B5SR)I?"P(0@7JXVTC0:V.C'/!!0,<ESQ]$E&X"T3-`R5R#6O
MTM(-['=6V]W=739EN'%[>'4[&ES\=D=X8,>7TBC+^E/E_U1XW'^TW/^/\G_/
MNG__[?0H_R,*:)?YO\S_9?XO\S_F_RPEP0]8!<JT7U)))9544DF/0'\"::9"
%2``H```H
`
end
SHAR_EOF
  $shar_touch -am 1119203799 'environbug-0.01.tar.gz' &&
  chmod 0664 'environbug-0.01.tar.gz' ||
  $echo 'restore of' 'environbug-0.01.tar.gz' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'environbug-0.01.tar.gz:' 'MD5 check failed'
763ebe00fa7558086e7bad80a0fab41c  environbug-0.01.tar.gz
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'environbug-0.01.tar.gz'`"
    test 1445 -eq "$shar_count" ||
    $echo 'environbug-0.01.tar.gz:' 'original size' '1445,' 'current size' "$shar_count!"
  fi
fi
# ============= perl-conf-with-perlmalloc ==============
if test -f 'perl-conf-with-perlmalloc' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'perl-conf-with-perlmalloc' '(file already exists)'
else
  $echo 'x -' extracting 'perl-conf-with-perlmalloc' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'perl-conf-with-perlmalloc' &&
Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
X  Platform:
X    osname=linux, osvers=2.2.10, archname=i686-linux
X    uname='linux cretuer 2.2.10 #9 smp fri jul 23 12:24:43 mest 1999 i686 unknown '
X    config_args=''
X    hint=previous, useposix=true, d_sigaction=define
X    usethreads=undef useperlio=undef d_sfio=undef
X    use64bits=undef usemultiplicity=undef
X  Compiler:
X    cc='cc', optimize='-g -O2', gccversion=2.7.2.3
X    cppflags='-Dbool=char -DHAS_BOOL -DDEBUGGING -I/usr/local/include'
X    ccflags ='-Dbool=char -DHAS_BOOL -DDEBUGGING -I/usr/local/include'
X    stdchar='char', d_stdstdio=define, usevfork=false
X    intsize=4, longsize=4, ptrsize=4, doublesize=8
X    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
X    alignbytes=4, usemymalloc=y, prototype=define
X  Linker and Libraries:
X    ld='cc', ldflags =' -L/usr/local/lib'
X    libpth=/usr/local/lib /lib /usr/lib
X    libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
X    libc=/lib/libc-2.0.7.so, so=so, useshrplib=false, libperl=libperl.a
X  Dynamic Linking:
X    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
X    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
X
X
Characteristics of this binary (from libperl): 
X  Compile-time options: DEBUGGING
X  Built under linux
X  Compiled at Nov 19 1999 20:15:49
X  @INC:
X    /tmp/perl/lib/5.00562/i686-linux
X    /tmp/perl/lib/5.00562
X    /tmp/perl/lib/site_perl/5.00562/i686-linux
X    /tmp/perl/lib/site_perl
X    .
SHAR_EOF
  $shar_touch -am 1119204399 'perl-conf-with-perlmalloc' &&
  chmod 0664 'perl-conf-with-perlmalloc' ||
  $echo 'restore of' 'perl-conf-with-perlmalloc' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'perl-conf-with-perlmalloc:' 'MD5 check failed'
e31b6eff49803fd99487f5c817cf4efd  perl-conf-with-perlmalloc
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'perl-conf-with-perlmalloc'`"
    test 1510 -eq "$shar_count" ||
    $echo 'perl-conf-with-perlmalloc:' 'original size' '1510,' 'current size' "$shar_count!"
  fi
fi
# ============= perl-conf-without-perlmalloc ==============
if test -f 'perl-conf-without-perlmalloc' && test "$first_param" != -c; then
  $echo 'x -' SKIPPING 'perl-conf-without-perlmalloc' '(file already exists)'
else
  $echo 'x -' extracting 'perl-conf-without-perlmalloc' '(text)'
  sed 's/^X//' << 'SHAR_EOF' > 'perl-conf-without-perlmalloc' &&
Summary of my perl5 (revision 5.0 version 5 subversion 62) configuration:
X  Platform:
X    osname=linux, osvers=2.2.10, archname=i686-linux
X    uname='linux cretuer 2.2.10 #9 smp fri jul 23 12:24:43 mest 1999 i686 unknown '
X    config_args=''
X    hint=previous, useposix=true, d_sigaction=define
X    usethreads=undef useperlio=undef d_sfio=undef
X    use64bits=undef usemultiplicity=undef
X  Compiler:
X    cc='cc', optimize='-g -O2', gccversion=2.7.2.3
X    cppflags='-Dbool=char -DHAS_BOOL -DDEBUGGING -I/usr/local/include'
X    ccflags ='-Dbool=char -DHAS_BOOL -DDEBUGGING -I/usr/local/include'
X    stdchar='char', d_stdstdio=define, usevfork=false
X    intsize=4, longsize=4, ptrsize=4, doublesize=8
X    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
X    alignbytes=4, usemymalloc=y, prototype=define
X  Linker and Libraries:
X    ld='cc', ldflags =' -L/usr/local/lib'
X    libpth=/usr/local/lib /lib /usr/lib
X    libs=-lnsl -lndbm -lgdbm -ldbm -ldb -ldl -lm -lc -lposix -lcrypt
X    libc=/lib/libc-2.0.7.so, so=so, useshrplib=false, libperl=libperl.a
X  Dynamic Linking:
X    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
X    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
X
X
Characteristics of this binary (from libperl): 
X  Compile-time options: DEBUGGING
X  Built under linux
X  Compiled at Nov 19 1999 20:00:17
X  @INC:
X    /tmp/perl/lib/5.00562/i686-linux
X    /tmp/perl/lib/5.00562
X    /tmp/perl/lib/site_perl/5.00562/i686-linux
X    /tmp/perl/lib/site_perl
X    .
SHAR_EOF
  $shar_touch -am 1119204399 'perl-conf-without-perlmalloc' &&
  chmod 0664 'perl-conf-without-perlmalloc' ||
  $echo 'restore of' 'perl-conf-without-perlmalloc' 'failed'
  if ( md5sum --help 2>&1 | grep 'sage: md5sum \[' ) >/dev/null 2>&1 \
  && ( md5sum --version 2>&1 | grep -v 'textutils 1.12' ) >/dev/null; then
    md5sum -c << SHAR_EOF >/dev/null 2>&1 \
    || $echo 'perl-conf-without-perlmalloc:' 'MD5 check failed'
8cfe0408dae4a6c2245b64ea5bf7b5b8  perl-conf-without-perlmalloc
SHAR_EOF
  else
    shar_count="`LC_ALL= LC_CTYPE= LANG= wc -c < 'perl-conf-without-perlmalloc'`"
    test 1510 -eq "$shar_count" ||
    $echo 'perl-conf-without-perlmalloc:' 'original size' '1510,' 'current size' "$shar_count!"
  fi
fi
rm -fr _sh10058
exit 0
0
schuma
11/19/1999 8:22:50 PM
>Could you please explain to a non-native the 'st' suffix meaning ?
[in "unbeknownst"]

Hm... that's a good question.  

Certainly its most common modern usage is as part of the superlative
degree, "-(e)st", as in "least", "worst", "best", or "eldest".

It's also a marker for the preterite when "-ed" has gone to "t".
You'll sometimes see it in words whose infinitives ended in "-ess", as in
"did bless" => "blessed" => "blest".  There are a few of these in the
dictionary, but you don't hear many of them anymore (although without a
vowel shift, your ear wouldn't likely be able to tell the difference).
Like "dreamt", "slept", "spelt", "smelt", "burnt", and many other "ed"
=> "t" endings, these are largely disappearing, some faster than others.
They tend to persist longer as adjectives than as productive verb forms.
You can find a lot of examples of these with "-st" that people never ever
use any more, like "verst" (versed) or "drest" (dressed).  One that is
still used is "past" (passed), but only adjectivally.

Historically, (well, archaically or poetically; same diff :-), the
"-((e)s)t" suffix was also the 2nd person singular (thou) inflection
for verbs, as in "knowest", "thinkest", "runnest", and other similary
examples in the modal auxiliaries, like "canst", "didst", or "shouldst".
Note that this sometimes is spelt (:-)) "-est", other times "-st",
and other times simply "-t", as in "shalt" or "wilt".

But "unbeknownst" would not appear to be of any of those categories, and
there aren't really enough exemplars of its form for me, at least, to draw
many conclusions.  Perhaps it falls into the set of words like "whilst",
"against", "amidst", and "amongst", although I wouldn't want to swear
to that.  I do note, however, that as in other cases where an alternative
is available, these forms are mostly giving way to forms without the
"-st".  Everyone still says "against", and many people everywhere still
say "amongst" (especially when the next word begins with a vowel sound,
as in "amongst others" vs "among friends"), but "amidst" and "whilst"
are seldom heard anymore in the States.

To my ear, the "-st" up in "unbeknownst" lends an certain air of erudition
(sometimes in the dusty and over-the-hill sense) to one's turn of phrase.

--tom
0
tchrist
11/19/1999 8:23:09 PM
On Fri, 19 Nov 1999 13:52:57 EST, Aaron J Mackey wrote:
>Can't Tom and Ilya agree to disagree?  Can't Ilya be ignored when it's
>worth ignoring?  Why does Tom spend so much time and energy putting down
>the irrational or hasty thoughts and ideas of others, when we can all
>judge for ourselves what's good and what's crud?

Bad attitude is like a conspicuous fart.  The culprit can't help it,
those victims with a sense of propriety can't let it go, and others
with any sense of proportion just ignore it.

Deeds matter, words not.


Sarathy
gsar@ActiveState.com
0
gsar
11/19/1999 9:57:46 PM
[about 'st']
> It's also a marker for the preterite when "-ed" has gone to "t".

Same for past participles too, no ? 

> But "unbeknownst" would not appear to be of any of those categories, and

Couldn't it be that when 'unbeknowst' came out, the past participle of 'to know'
was 'knownst' before becoming 'known' ?

> To my ear, the "-st" up in "unbeknownst" lends an certain air of erudition
> (sometimes in the dusty and over-the-hill sense) to one's turn of phrase.

I see, it's like in french using archaic words such as 'moult', 'oncques' or
'honni(e)', although for us it would sound rather pendantic.

Fran´┐Żois
0
desar
11/21/1999 11:50:42 AM
Tom Christiansen <tchrist@jhereg.perl.com> writes:
>>Could you please explain to a non-native the 'st' suffix meaning ?
>[in "unbeknownst"]
>
>Hm... that's a good question.  

OED2 thinks so too:

"
unbe'knownst, a. or adv. Orig. colloq. and dial. Also unbeknowns, etc.
[f. prec. The analogy on which the -s or -st has been added is not clear: cf. the earlier unknownst.]
= unbeknown 2. Also, = unbeknown ppl. a. 1.
Now of much wider currency than in the 19th. cent.
"

OED2 does have 'beknownst' but has beknow as obsolete.

>
>To my ear, the "-st" up in "unbeknownst" lends an certain air of erudition
>(sometimes in the dusty and over-the-hill sense) to one's turn of phrase.

Sounds like fake "Olde Englishe" to me ;-)

-- 
Nick Ing-Simmons

0
nick
11/21/1999 9:08:24 PM
Reply: