Thu Feb 3 17:28:51 CET 2005
In the same vein, when we started using Yaws in one of our services, we had
to change it so that headers received in HTTP requests were not converted to
atoms. If we hadn't done that, a rogue HTTP client could easily bring our
erlang node down.
> -----Original Message-----
> From: Ulf Wiger (AL/EAB) [mailto:]
> Sent: 03 February 2005 15:57
> Subject: RE: Concatenating atoms
> Joe wrote:
> > *Every* parser which accepts inputs from a communication
> > channel suffers from this
> > problem is the set of atoms that it can create is unbounded.
> > This gives us a number of design choices.
> > 1) Accept that I have incorrect implementation that
> > will one day crash
> > 2) Prove that the atom table cannot overflow because
> > the alphabet is
> > finite and will not overflow the atom table
> > 3) Uses strings instead of atoms
> This might be a good time to point out that xmerl
> converts element and attribute names to atoms.
> I've seen complaints on the list that xmerl is slow.
> All other things being equal, switching over to using
> strings instead would slow it down considerably
> (not that I've measured this).
NOTICE AND DISCLAIMER:
This email (including attachments) is confidential. If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents. We cannot accept liability for any breaches of
confidence arising through use of email. Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions. We will not accept responsibility for any commitments
made by our employees outside the scope of our business. We do not warrant
the accuracy or completeness of such information.
More information about the erlang-questions