On 7/6/06, Graeme Geldenhuys <[EMAIL PROTECTED]> wrote:
On 7/6/06, Bisma Jayadi <[EMAIL PROTECTED]> wrote:
> As I said, the CSV parsing logic can be tuned. :) But, it must able to solve
all
> malformed format possibilities first (at least most of them). The actual
> behavior then can be set.
Thinking a bit more about it. I don't known if allowing malformed CSV
is a good idea. Where do you draw the line with what is acceptable?
Also, I can't think that you can create a parser that can handle all
forms of malformed CSV at the same time...
I don't think you should treat the symptom, but rather the underlying
cause of the problem. A better approach will be to let the parser
report on issues found and let the person/company who created the CSV
file know that their CSV generator is broken and should fix it.
That's how security vulnerabilities starts... When you do not have at
least a default way of handling stuff, and you just throw it all back
at the user ...
If you can't handle the file format, you can report it, but if you
don't have some type of balance, then something bad can happen (like I
will create on purpose a malformed CSV, and exploit the way you failed
to parse it).
Regards,
- Graeme -
Ido
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
