220 40197 article Path: news.gmane.org!.POSTED!not-for-mail From: Brian Bi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Should istream::read() be allowed to clobber the buffer beyond the file's size. Date: Wed, 19 Sep 2018 21:19:40 -0400 Lines: 115 Approved: news@gmane.org Message-ID: References: <21a506dd-40ae-4cae-986d-4f014de8d859@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000eaf06a057643516f" X-Trace: blaine.gmane.org 1537406267 16113 195.159.176.226 (20 Sep 2018 01:17:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 20 Sep 2018 01:17:47 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDS5ZX5VU4NBBOPLRPOQKGQEXSCRM3I@isocpp.org Thu Sep 20 03:17:43 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ed1-f70.google.com ([209.85.208.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g2nbD-00045f-LR for gclcip-std-proposals@m.gmane.org; Thu, 20 Sep 2018 03:17:43 +0200 Original-Received: by mail-ed1-f70.google.com with SMTP id g18-v6sf3410165edg.14 for ; Wed, 19 Sep 2018 18:19:54 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1537406394; cv=pass; d=google.com; s=arc-20160816; b=g5EtHvdu6z9DHvXsjwrk+s6gnYveBCr8X0zCWQlha1x0ige0J4XIBjI7WtRwpnbJDq 7XlczhtgQRh+5ohYC/AxZkW5RwQ8/1PaLp/tSRieAGMevhrtyhCywnrERvEjq2kv7f2I 0C6RPWAuQ3pBH8flGC1tuiDZr8730yrNJQIzi6cQ+lWYe7aj3VyqLEXXebmMzrBGFVoh 3ifnrR8HU3aQTDMyMCkQtrd8C22ZkxwMkJDdww+7UX3hMOeO2gDcllAOhOCdKw5io7+8 oZiiMjvdhZCSXj1AlXq9ZopISaTf/1mO2nbjKDEHFYhAKx7+2iXUYhra4aIKlkLk9OMH wMMg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=35T8QuiYrpIwMSnPxfcxOOKOS1Nfm84+LWhVeVYptck=; b=wApmUj2XTwMLuo6JraJH701P6F7PYqUhdRLLcHL4F/jDClAyOQVoXey1YeSuZvdBrY 1mXt3XzTdnUyaU77A8CsNQmHJwiwkrboeetnFWC010N7yIddOlpcgAGIkzKUgLM57IQK q8GNwhk4xWY7rZtTmF4HEUPXkb25nhRjOLb6tjbBgAlIZ7PnQJBkOk/RBM9Uiwx6Mf0C C0y1C/Da3JcEmf8II9E1Cv9rv8wEB2b6/ZIWeeXVAURNXqqUGYWCGMas/QqXeyVjsvH8 Z2IkkEhS1d/70CWZKsQtC+qSV4fFdSkO2UR7NhpyuJwVaS87HF796NWn2GD9tnySVXjJ sorQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Jkw67sQI; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=35T8QuiYrpIwMSnPxfcxOOKOS1Nfm84+LWhVeVYptck=; b=dCkxY6k0r3nHKwIWrUUae2nHpKibmEOzfSL3yliVC3A8S7akPaDEJ8pYPFqQQeIZhu 5MDi+yQxLNh5mfugaCyIz49CFDvnSAoDBpMcrbTOT8Y7E78CZrwaJ5Mc8RcX3ifvhux7 kauCqB5UHHwq2XDyLrmIIMJZPOh1N9kvivjN8LQ0UUsZwO7QsukifW7cBzRYNXWvHANk bbRZzmz7n/vATv6TyqA48aVI1EBPROp9DfhNnIE9zPv6bDhJuDAERbi3U4h8MsXZwHu4 QWW6pBrmGn52msHLCnKLa9biWr6XyoxgH58jAEWkDgBsEFl5QxDQXhzToF+50wG03xdl dKDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=35T8QuiYrpIwMSnPxfcxOOKOS1Nfm84+LWhVeVYptck=; b=onR03PHhx5UPTZHFMUxdXyxVldiqzZB7BsfK2PRQM0/S1W+utc74MCtPSfiUKkuveV tYWFGrnALXuI7J5qQVntnAqJA4Zwn0K+dRCYrjXKxOLCqr2g04uAKJHzsbSQ4VVhb35b SMrz2tS/gYMdqvug0Jq/3hBznV4UHWgfoF/FAI+5i/i/TaKAIiFWoRM1uVkD+fy4tM4h lPZjxdzHVGevVBcjGSncklkZopl4KWis/6xDXoYppfxPXMDJcFFoaXR/ZUYi5cXcu1L0 /pHOc/lSFCotDS7tOoFbUK695kTopTt5rL2hU12py9G4e24RtTNU6V+m/LlRcDz8vMv4 1Btw== X-Gm-Message-State: APzg51BaTyzrRGr2Rc7KRph1ZzqpI1Ac/4ECmkWu9ywCYMZENRqV6Oy4 JmsZx/lMoHVEXd6K2UpFuNVxUg== X-Google-Smtp-Source: ANB0VdbFdktIjSdC/DC+iFiUlTnYVPtjJAcdtn/BnNC+deD4n7boqiDl8Q5f8gcakP4egNn4i8I6Rg== X-Received: by 2002:a50:89ca:: with SMTP id h10-v6mr163053edh.11.1537406394415; Wed, 19 Sep 2018 18:19:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a50:ba7a:: with SMTP id 55-v6ls311727eds.6.gmail; Wed, 19 Sep 2018 18:19:53 -0700 (PDT) X-Received: by 2002:a50:b2a6:: with SMTP id p35-v6mr707974edd.215.1537406393344; Wed, 19 Sep 2018 18:19:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537406393; cv=none; d=google.com; s=arc-20160816; b=niHQN7UfrdD8to6puYBFsfsMoq1nJOa5qfPj+iDAUZ1Xd0Ar1KXcetw7r4PcHXK3eZ HsaIb6TZSkWDwitLJJgLq5PWCWsmz0CK0/DTSAjis7sPdPU9UYxHVauUbigCh1jEZmHS vAVhgsDm1Q/vNuRENRyayxLV8RQFM8NMzn/2KgI0MIJf+DgSj3pwYGFeOaratTW56bdR NIpZHm/aODdeP3hjfFHq0Ew2Y01PXTseqkVUhe74TCrhsZXU9caeVtYD+T62n5pPVOgm uYyejhnS5pbRqlPaSqeICFbK85DnymNACTJ82gqYobRm1+oactys4UTteXR7q3vVZAFQ UbJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=M7xv5apO29H6iGdlHM9ZEhWcQm6NtD9MKSfPs51h5b0=; b=mQtLYao+B1ifs6NHK7CE1fd/zeBTfMyOpUsbRgh1pqFQRjYHifqDvD/iTAnf6NzD1b S5lWGacObM5+pARe/v3RxEG2QwKXw5KRLtrSdBGtUXCj6twhRmbi+EWwHU7jfBzlfVVF vH3Mp5XnJ3g0pKSxPC4nQseBTuEQwJeVGJyUqshOKVC6JcJpDDPxmLlI0Ct2K1w0w/zC Ohp5PyzJbNlSBvkcpQ+Lenl6j4vtWDouKF+1Vc7yISeHl6rbZAFiLSvxrvg/5yQ/DQfq GQ0dKnAseZiw0qWmNEiOkX4M94DZBM72/JWBffGDNX+Gk6xpnx4CDrIEP8d1h/LodBWr nI9g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Jkw67sQI; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id f48-v6sor460643edf.14.2018.09.19.18.19.53 for (Google Transport Security); Wed, 19 Sep 2018 18:19:53 -0700 (PDT) Received-SPF: pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a50:8c98:: with SMTP id q24-v6mr868110edq.2.1537406392789; Wed, 19 Sep 2018 18:19:52 -0700 (PDT) In-Reply-To: <21a506dd-40ae-4cae-986d-4f014de8d859@isocpp.org> X-Original-Sender: bbi5291@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=Jkw67sQI; spf=pass (google.com: domain of bbi5291@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=bbi5291@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:40197 Archived-At: --000000000000eaf06a057643516f Content-Type: text/plain; charset="UTF-8" Can you provide an example of the code and the file that produce this behaviour? The C standard seems to allow some garbage to be written for the last object's value if the size of the file isn't a multiple of the object size, but I'm not sure if that's what you're talking about. (C11 7.21.8.1/2) .... If a partial element is read, its value is indeterminate. > On Wed, Sep 19, 2018 at 6:06 PM Bengt Gustafsson < bengt.gustafsson@beamways.com> wrote: > When you do a read on an istream with a buffer larger than the file (in > text mode) the MSVC was recently changed so that it may change bytes in the > buffer after the file length. The same goes for the C function fread(). > > I'm unsure if the standard actually allows this behaviour. Microsoft > recently changed the behaviour and it broke our test programs. > > Microsoft claims this is allowed, I think it is not logical to allow it. > > Is this behaviour allowed? If it is allowed, should it be? > > > -- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-4cae-986d-4f014de8d859%40isocpp.org > > . > -- *Brian Bi* -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOQo30FaJJfosjTbqroMf2yPO1%3DQZuq0GueJEiZX%2Bpjrw%40mail.gmail.com. --000000000000eaf06a057643516f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you provide an example of the co= de and the file that produce this behaviour? The C standard seems to allow = some garbage to be written for the last object's value if the size of t= he file isn't a multiple of the object size, but I'm not sure if th= at's what you're talking about.

(C11 <= a href=3D"http://7.21.8.1/2">7.21.8.1/2)

... If a partial element i= s read, its value is indeterminate.

<= div class=3D"gmail_quote">
On Wed, Sep 19, 2018 at 6:06 PM = Bengt Gustafsson <bengt= ..gustafsson@beamways.com> wrote:
When you do a read on an istream with a buffer larger= than the file (in text mode) the MSVC was recently changed so that it may = change bytes in the buffer after the file length. The same goes for the C f= unction fread().

I'm unsure if the standard actually= allows this behaviour. Microsoft recently changed the behaviour and it bro= ke our test programs.

Microsoft claims this is all= owed, I think it is not logical to allow it.

Is th= is behaviour allowed? If it is allowed, should it be?

<= div>

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/21a506dd-40ae-= 4cae-986d-4f014de8d859%40isocpp.org.


--
Brian Bi

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAMmfjbOQo30F= aJJfosjTbqroMf2yPO1%3DQZuq0GueJEiZX%2Bpjrw%40mail.gmail.com.
--000000000000eaf06a057643516f-- .