perl5.005_02: my_setenv() and Term::ReadLine::Gnu

[p5pRT]

Migrated from rt.perl.org#1789 (status was 'resolved')

Searchable as RT1789$

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

---

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

[p5pRT]

From [Unknown Contact. See original ticket]

On Wed, Nov 17, 1999 at 11​:59​:01PM +0100, Joerg Schumacher wrote​:

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()?

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, Nov 18, 1999 at 12​:24​:05AM +0100, Joerg Schumacher wrote​:

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

*What* it calls Safefree() on? How can it be that this is unallocated?
Judging by what you wrote, you are running some old version of Perl,
such as 5.005_03. 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.

I think you need to concentrate on these questions.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, Nov 18, 1999 at 01​:08​:34AM +0100, Joerg Schumacher wrote​:

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.

You look utterly confused. First you claim that this is not a problem
with several mismatched malloc()s, now you say that it is.

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.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Thu, Nov 18, 1999 at 01​:31​:11AM +0100, Joerg Schumacher wrote​:

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.

OK, now it is us who look utterly confused... I was pretty sure that
documentation of putenv() states that it free()s the old value, but
most probably it just leaks...

So your solution involves a static variable. Hmm... Since
environment coming from main() is a global property, it is probably
what should have been done.

But nevertheless, your solution is a leak, since the environment set
in the library will never be free()d. On the other hand, what else
can we say instead of "tough luck"​: the library might have put a
static string into environment too...

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

%% Ilya Zakharevich <ilya@​math.ohio-state.edu> writes​:

  iz> OK, now it is us who look utterly confused... I was pretty sure
  iz> that documentation of putenv() states that it free()s the old
  iz> value,

No, it doesn't. For one thing, there's no requirement that the memory
you pass to it be on the heap.

  iz> but most probably it just leaks...

If you pass it an alloc'ed block and don't save a pointer to it yourself
to free later, if you know when "later" is, yes, it does.

putenv() is a crappy function.

--

---

Paul D. Smith <psmith@​baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist

---

  These are my opinions---Nortel Networks takes no responsibility for them.

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

---

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 01​:37​:35AM +0100, Joerg Schumacher wrote​:

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.

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.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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,
Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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...

Ilya

[p5pRT]

From @ysth

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. (Yuck) It also warns against passing an
pointer to an auto since it could go out of scope leaving a bad
pointer in the environment.

Sad. Makes putenv extremely unattractive.

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

Yitzchak Scott-Thoennes <sthoenna@​efn.org> 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. (Yuck) It also warns against passing an
pointer to an auto since it could go out of scope leaving a bad
pointer in the environment.

Solaris7 still says that :

DESCRIPTION
  The putenv() function makes the value of the environment
  variable name equal to value by altering an existing vari-
  able or creating a new one. In either case, the string
  pointed to by string becomes part of the environment, so
  altering the string will change the environment.

Thus one must malloc the string.
However it is far from clear that the incoming environ has each string
malloc'ed individually. Nor can one be sure that some XS module has
not done :

static char *myvar = "HOME=/some/place";
putenv(myvar);

Thus as far as I can see unless we keep a hash of "things we malloc'ed"
and check for match we should not free() anything in environ.

--
Nick Ing-Simmons <nik@​tiuk.ti.com>
Via, but not speaking for​: Texas Instruments Ltd.

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

Nick Ing-Simmons <nik@​tiuk.ti.com> wrote

Thus as far as I can see unless we keep a hash of "things we malloc'ed"
and check for match we should not free() anything in environ.

Exactly. And therefore, since we don't want memory leaks, we must
keep a hash.

What would happen about changes to %ENV from XS code? Or would the magic
just "do the right thing"?

Mike Guy

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, 19 Nov 1999, M.J.T. Guy wrote​:

Nick Ing-Simmons <nik@​tiuk.ti.com> wrote

Thus as far as I can see unless we keep a hash of "things we malloc'ed"
and check for match we should not free() anything in environ.

Exactly. And therefore, since we don't want memory leaks, we must
keep a hash.

You just have to be careful about that when you're embedding perl in
another application that changes the environment. One problem is that
using perl malloc to create your hash will cause all sorts of bad things,
because the enviroment ends up being allocated by perl's malloc which
prevents the embedding application (which don't use perl malloc) to do any
further putenv's.

Another problem (which is biting me :-( is that the practice of assigning
a new value to __environ (which is what you do when you create your hash)
seems to break on IRIX 6.2 using SGI's newest compiler (7.3) :-(

Rasmus

---

Rasmus Tamstorf (tamstorf@​fa.disney.com) If you can dream it you can do it !
Walt Disney Feature Animation - Walt Disney

---

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 10​:14​:21AM +0100, Raphael Manfredi 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?...

Approximately​: "Do not finis me!" ;-)

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.

Yes. You cannot in Perl, since only 60% or so of operations are
documented (if you omit those things which are documented hopelessly
wrong :-(). Did you ever use

  $a = $b + $c;

?

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 10​:55​:04AM -0700, Tom Christiansen wrote​:

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.

What makes you expect this?

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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.

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 10​:57​:50AM -0700, Tom Christiansen wrote​:

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.

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?

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 11​:06​:19AM -0700, Tom Christiansen wrote​:

Please contribute.

Are you infering that I do not? And please explain how printf(3)
relates to Perl.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 01​:52​:57PM -0500, ajm6q@​virginia.edu wrote​:

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?
  ^^^^^^^^^^^^^^^^^

Do not suggest this. This road leads to hell even faster than our
current trajectory.

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.

Yes.

--
"Never ascribe to malice that which can be explained by stupidity."
  via, but not speaking for Deutsche Bank

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 01​:52​:57PM -0500, Aaron J Mackey wrote​:

Can't Tom and Ilya agree to disagree?

No, they're hashing out langauge features (or misfeatures).

Can't Ilya be ignored when it's worth ignoring?

"it"? But yes, anyone can be ignored.

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?

As *I* see it, Tom isn't "putting down" anyone's ideas as much as he's
elucidating what may not be apparent to the casual observer. He's
taking a proposed language feature and following it to it's logical or
illogical conclusions then telling us his results and his position on
the matter. We, of course, still get to choose, but now we have
perhaps more information with which to base our decision.

-Scott
--
Jonathan Scott Duff
duff@​cbi.tamucc.edu

[p5pRT]

From [Unknown Contact. See original ticket]

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

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 12​:16​:09PM -0700, Tom Christiansen wrote​:

Ilya was using "infer" in places that I was pretty sure he meant
"imply".

Correct. And thanks for your correction.

Ilya

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri, Nov 19, 1999 at 11​:41​:51AM -0700, Tom Christiansen wrote​:

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?

Hmm... Do you? If not, why? Apparently you subscribe to a
programming language's developer mailing list and bombast them with
myso-programmer tirades... 3/4 ;-)

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.

Nope. That's diagnosis, which is one of the necessary steps on the
way to recovery.

Even were it true -- and it is demonstrably a viscious
and seditious lie -- it has no business being said in that forum.

Please do not "it has no business being said" me. Thanks.

Ilya

[p5pRT]

From @gsar

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

[p5pRT]

From [Unknown Contact. See original ticket]

duff@​cbi.tamucc.edu​:

On Fri, Nov 19, 1999 at 01​:52​:57PM -0500, Aaron J Mackey wrote​:

Can't Tom and Ilya agree to disagree?
No, they're hashing out langauge features (or misfeatures).

I'd much prefer that these were Perl language features, not
English ones.

--
We come to bury DOS, not to praise it.
(Paul Vojta, vojta@​math.berkeley.edu, paraphrasing a quote of Shakespeare)

[p5pRT]

From [Unknown Contact. See original ticket]

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