develooper Front page | perl.perl5.porters | Postings from September 2000 mail-blocking setup??

Thread Next
Marc Lehmann
September 15, 2000 08:20
Subject: mail-blocking setup??
Message ID:
20000915172035.E1232@cerebro.laendle seems to be a bit eager of keeping people out.
Abolishing the whole of uunet-germany is not really useful for the
discussion. And since these problems seem to be very intermittent (it
works most of the time) I guess the setup on is
not quite solid.

----- Forwarded message from Mail Delivery System <> -----

Subject: Mail delivery failed: returning message to sender
From: Mail Delivery System <>
Date: Fri, 15 Sep 2000 01:57:31 +0200

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. The following address(es) failed:
    SMTP error from remote mailer after RCPT TO:<>:
    host []:
    451 See <URL:>:
    retry timeout exceeded

------ This is a copy of the message, including all the headers. ------

Return-path: <>
Received: from [] (helo=cerebro)
	by doom with esmtp (Exim 3.15 #2)
	id 0LMBTC-0001c0-00; Tue, 01 Jan 1980 16:59:26 +0100
Received: from root by cerebro with local (Exim 3.15 #2)
	id 13ZbQ5-0000Yz-00; Thu, 14 Sep 2000 17:59:25 +0200
Date: Thu, 14 Sep 2000 17:59:25 +0200
From: Marc Lehmann <>
To: "Moore, Paul" <>
Subject: Re: unicode support and perl
Message-ID: <20000914175925.B1906@cerebro.laendle>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>; from on Thu, Sep 14, 2000 at 09:48:57AM +0100
X-Operating-System: Linux version 2.2.17 (root@cerebro) (gcc version pgcc-2.95.2 19991024 (release)) 
X-Copyright: copyright 2000 Marc Alexander Lehmann - all rights reserved

On Thu, Sep 14, 2000 at 09:48:57AM +0100, "Moore, Paul" <> wrote:
> >From my (uninformed) reading of the various Unicode discussions, it seems to
> me that there is a confusion over what a "Perl string" is supposed to be. To
> the best of my knowledge, the intention is that a string in Perl is simply a
> sequence of characters, where ord() of each character is *not* limited to
> 0..255. The internal representation is irrelevant, except to low-level
> "guts" type code.

This is a very wrong way to view this, as it throws perl direcly into the
same problem as tcl, nameyl the inability to handle binary data.

Being able to handle binary data transparently is a *must* for perl. As
soon as perl starts to convert my jpeg images or audio data into utf-8 I
will probably have to switch to a real computer language.

> guts" comment above, and is simply that the internal representation exposes
> itself at too high a level to be entirely comfortable - specifically, at the
> XS level, where most C functions do *not* expect UTF-8, so that XS interface

No. Pelr *must* support binary data *and* strings. At the moment, this
happens to be byte strings and utf8-strings, but this does not need to stay
that way.

Throwing away the ability to transparently handle binary data (even if it
can be extracted later on) is not a viable solution.

----- End forwarded message -----

      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ / |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About