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@&#8203;math\.ohio\-state\.edu wrote   using Mutt 1.0pre2i   in \19991118222256\.A16955@&#8203;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@&#8203;monk\.mps\.ohio\-state\.edu\, Ilya Zakharevich \ilya@&#8203;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@&#8203;monk\.mps\.ohio\-state\.edu\, Ilya Zakharevich \ilya@&#8203;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@&#8203;efn\.org writes​:

In article \19991118210401\.A16532@&#8203;monk\.mps\.ohio\-state\.edu\, Ilya Zakharevich \ilya@&#8203;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@&#8203;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@&#8203;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@&#8203;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@&#8203;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