From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help 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 Message-ID: <83y2b1ubqt.fsf@gnu.org> References: <87pmwgdiyj.fsf@zoho.eu> <83y2b3tq07.fsf@gnu.org> <871r8vcrnm.fsf@posteo.net> <20210621141148.GA29347@tuxteam.de> <20210621211547.GA12274@tuxteam.de> <87pmwevjbs.fsf@zoho.eu> <83bl7yumh1.fsf@gnu.org> <8335taujt6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15987"; mail-complaints-to="usenet@ciao.gmane.io" To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jun 22 18:14:29 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lvj2h-0003sJ-7j for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 22 Jun 2021 18:14:27 +0200 Original-Received: from localhost ([::1]:38434 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvj2f-0001MW-Vf for geh-help-gnu-emacs@m.gmane-mx.org; Tue, 22 Jun 2021 12:14:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60790) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvitJ-0006Mz-C5 for help-gnu-emacs@gnu.org; Tue, 22 Jun 2021 12:04:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37066) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lvitJ-0006PH-3o for help-gnu-emacs@gnu.org; Tue, 22 Jun 2021 12:04:45 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4702 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lvitI-0002sC-Ms for help-gnu-emacs@gnu.org; Tue, 22 Jun 2021 12:04:45 -0400 In-Reply-To: (message from Jean Louis on Tue, 22 Jun 2021 18:45:56 +0300) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:131201 Archived-At: > Date: Tue, 22 Jun 2021 18:45:56 +0300 > From: Jean Louis > Cc: help-gnu-emacs@gnu.org > > * Eli Zaretskii [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.