help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Printf and quoting in general, SQL injection in particular [was: Ema


From: Eli Zaretskii
Subject: Re: Printf and quoting in general, SQL injection in particular [was: Emacs Modular Configuration: the preferable way]
Date: Tue, 22 Jun 2021 19:04:26 +0300

> Date: Tue, 22 Jun 2021 18:45:56 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2021-06-22 16:11]:
> > We _represent_ file names as strings, but they are not normal strings.
> > Just like characters are represented as integers, but they are not
> > just simple integers, they have additional special attributes and
> > behaviors.
> 
> I get your point, what I don't agree with is the Formulierung. It
> is for same reason as you mentioned it, people are reading our
> writings and our form or text should be possibly clear. If you
> wish to say they are not normal strings, demonstrate it. By
> demonstration below it shows to be of type string. What is else
> there?

What is there is that not every operation, which is valid and has
trivially-expected results with strings, is valid and has the same
trivial results with file names.  See the examples I presented.  And
there's more, for example, (concat "/foo/" "/bar") could be equivalent
to "/bar" when those are file names.  Likewise with characters: if c
is a valid character, (* 2 c) may not be a valid character, even if it
is a valid number.

> But subject was that we deal with strings in those functions. 

And my point is that it is dangerous (a.k.a. "wrong") using string
functions on file names when there are specially-designed file-name
functions for those use cases.  Because those special-purpose
functions are there for a reason, and disregarding those reasons is
asking for trouble.  Like using string comparison for comparing file
names: that was actually a reason for quite a few bugs in our code.
My point was trying to prevent people from making those same mistakes.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]