unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Lars Ingebrigtsen <larsi@gnus.org>
To: Ivan Shmakov <ivan@siamics.net>
Cc: 18370@debbugs.gnu.org
Subject: bug#18370: insert-file-contents: forbids also beg, end for non-regular (special) files
Date: Wed, 11 May 2022 17:22:56 +0200	[thread overview]
Message-ID: <874k1w6qlr.fsf@gnus.org> (raw)
In-Reply-To: <87y4u4tp5a.fsf@violet.siamics.net> (Ivan Shmakov's message of "Sun, 31 Aug 2014 19:50:09 +0000")

Ivan Shmakov <ivan@siamics.net> writes:

> 	As currently implemented, insert-file-contents disallows not
> 	only (as per (elisp.info) Reading from Files) the case of either
> 	‘visit’ or ‘replace’ arguments being non-nil, but also when
> 	non-nil are either ‘beg’ or ‘end’ (or both):

[...]

> 	This, however, precludes the use of insert-file-contents not
> 	only on named pipes, but also on /dev/cdrom, /dev/random, and
> 	the like, – for (and especially in the case of the latter) the
> 	‘end’ argument gets rather essential here, as otherwise the
> 	function is likely to read much more than the caller will be
> 	able to handle at any single time.
>
> 	Instead, I’d suggest that ‘end’ is always allowed, and ‘beg’ is
> 	allowed when the file in question is /seekable/, – which, ISTR,
> 	is possible to check beforehand (lseek (fd, 0, SEEK_CUR) < 0?)
>
> 	From a glance over the code, this new behavior wouldn’t be all
> 	that hard to implement (some not_regular checks will have to be
> 	replaced with the ones against beg_offset, end_offset, etc.),
> 	but from what I read, – it’s already going to be more than I can
> 	test right now.  So no .diff this time, alas.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Simple test case:

(insert-file-contents "/dev/urandom" nil nil 10)

This still fails in Emacs 29, and it would indeed be nice if it worked.
I seem to remember this being discussed previously, and that...  er...
no, I can't really recall anything more than that.

Does anybody see any good reasons why we shouldn't allow this?  If not,
I can take a stab at implementing it...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no





  reply	other threads:[~2022-05-11 15:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-31 19:50 bug#18370: insert-file-contents: forbids also beg, end for non-regular (special) files Ivan Shmakov
2022-05-11 15:22 ` Lars Ingebrigtsen [this message]
2022-06-11 12:40   ` Lars Ingebrigtsen
2022-06-12  7:11     ` Juri Linkov
2022-06-12 10:19       ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874k1w6qlr.fsf@gnus.org \
    --to=larsi@gnus.org \
    --cc=18370@debbugs.gnu.org \
    --cc=ivan@siamics.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).