From owner-sc22wg14+sc22wg14-domo2=www.open-std.org@open-std.org Fri Sep 19 16:24:21 2025 Return-Path: X-Original-To: sc22wg14-domo2 Delivered-To: sc22wg14-domo2@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 1427D356C3F; Fri, 19 Sep 2025 16:24:21 +0200 (CEST) Delivered-To: sc22wg14@open-std.org Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) by www.open-std.org (Postfix) with ESMTP id C0CD6356689 for ; Fri, 19 Sep 2025 16:24:20 +0200 (CEST) Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-62f0702ef0dso6134488a12.1 for ; Fri, 19 Sep 2025 07:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758291860; x=1758896660; darn=open-std.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Zx20PXPhn1y6T52H3yUSsRvQBRqQIR9ylIqRCg4/aHw=; b=dNUw0SiUwx+Ypl3Mk8P3AN1FiQIWCqOPbKRm2V62mXL6nww39DfcM06p3PuevcuRbs x5xKcj+bs23ikNYSehgosBo17Rv6VaW3tOfqrVmJAKbAsGSnMUgtB9ViI54A9oLOYaIj Eqpv7rodQgPHfsYXHl+EmAOMD1zQEQcjLNc6cunHUAaqBQO3AWmc+qFJIVs7SQ8ujr2O 7p/d4gl7kavzyOo+EAsqplCVURKPRqejO1YeBqTHO9uQ7wcvoQpJBvwHgq90QTVqathL LBTpgpRrQYEAMZkAoGEV1G0uXtKie/VmshvXwsL9xEwDHiSee7DCM1sKx+hrR6dWOITo 2jgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758291860; x=1758896660; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Zx20PXPhn1y6T52H3yUSsRvQBRqQIR9ylIqRCg4/aHw=; b=b+Lr2vANpWFwcHVAsH9THNRE3p2ns8Vjj305AZ6kFGy8iNHdEjUo0UUTNEBuADg/KX ssXH0VkHYu+Az2BFzmgczga93q6yK/3kdWwjXkcM/h542CfcK+6PDaJ/FGZlaDB77QDB f8ylmT4xeDMyoFShfbd54Dzt1t9p6RxYi/oJ5ctYjcovlckfQ2BvzKdBg+WNV0Gy4LFf /i+bzc8AhCr1iHPPSgs827/o15t0q7I5Ba8+d11/yX0A/FKbbanLXpRWLi65F0uxHbPK Q8ZEpjFgL6H4C2RHgo7oDkHadZb03i58aheC789l4ggc099kqCvnsvFHR43UTFtU9M6V wTbw== X-Forwarded-Encrypted: i=1; AJvYcCXJOvL48g0vxvHy2Tm1gXsam85Kx1xiF2Ls7wJJpRs1uYXo+0EUYWUUMXlu0DEiG6yVA0TcIvKpsA==@open-std.org X-Gm-Message-State: AOJu0YxqvvSUNaEWaeBUKSkfVN3/P4odV1rptf8RvhoElyprEhXDTGBh gRKKqCJqqiyuz7/60hx6pixPGUbRdK1xjtxJHSNMptoeak/pTzRI5K6TFsE0OjYDlzZ5qzTEy78 oMApcMdQvMOM3ktALhUQe+rdHDkcT9Echg/nxw5U= X-Gm-Gg: ASbGnctAlut+O5UWPEA6xJvY6rUDr333KrXgZnHhq4SPaLAtZS6GZPeHF+ZoszPbweS kmuwOimGNq9gi/qT14DS7Y4Qn6jT/UyIpQD9fLQTUX+K2iy5ts/dc0fVo3fb0/KW/ezUzEjSLz1 eVI+DKUEQw4+JFHdpMfw7d0qFFFYNMEqnxbqhtXon83usMeKXCvZF/fJAvu6c189vrAJLrZFW6+ KGHv6jRYSTJLWdnETFEyHd7uylgk3fmrxH+q8A= X-Google-Smtp-Source: AGHT+IHa2VBia1C1H6I5O44FJTqx665mP5B5ppdmmdlpckfi4WhItvL/a41Ubi6gmhc+/mbWy9QaQKiHxBv7MHPvxec= X-Received: by 2002:a17:906:9fc5:b0:b19:f444:5bc8 with SMTP id a640c23a62f3a-b1faef71aa1mr913090266b.31.1758291859777; Fri, 19 Sep 2025 07:24:19 -0700 (PDT) MIME-Version: 1.0 References: <20250918211921.67BDE356C27@www.open-std.org> <20250918220231.0FD51356BCF@www.open-std.org> <20250919072944.D54AE356C44@www.open-std.org> <20250919075049.1DA19356C28@www.open-std.org> <20250919112332.959B2356C28@www.open-std.org> <20250919122830.E96A3356C3C@www.open-std.org> In-Reply-To: <20250919122830.E96A3356C3C@www.open-std.org> From: Corentin Date: Fri, 19 Sep 2025 16:24:02 +0200 X-Gm-Features: AS18NWBZitimtJI4PmtcsA8a7QN2cL-M3wbXOqQG6Orlg_3XoU7va6cgzZADl0g Message-ID: Subject: Re: [SC22WG14.34013] Missing newlines at end of file To: Alex Celeste Cc: Joseph Myers , =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= , sc22wg14@open-std.org Content-Type: multipart/alternative; boundary="000000000000b6b582063f2839c0" Sender: owner-sc22wg14@open-std.org Precedence: bulk --000000000000b6b582063f2839c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Sep 19, 2025 at 2:28=E2=80=AFPM Alex Celeste = wrote: > Can someone enumerate the implementation issues that would be caused > and/or solved by choosing any of the suggested paths forward here? > > As an implementer: > - I don't need the newline to exist in order to make sense of the file > (the virtual newline interpretation is adequate); > - the Standard doesn't place any requirements on a file _outputted_ by th= e > preprocessor (or require it to be a provided functionality), so as a matt= er > of QoI a considerate tool should format preprocessed output in accordance > with whatever the host system needs, but this is out of scope for the > document > +1 > > Are we suggesting that because _other_ parts of the ecosystem require thi= s > newline to exist, C should require it too? > That seems unnecessarily prescriptive, if we could just as easily be > flexible in what we accept. > > (like Aaron suggests, the most likely upshot either way is that tools > continue to emit a suppressable warning and then compile as though the > newline had been injected) > As an implementer, we have supported files that do not end with a new line for decades and do not intend to change. Clang does have -Wnewline-eof, but this is not enabled, even under -Wextra, and it's very unlikely that we would be willing to change that (GCC does not even have such warning) Here is the C++ wording. There is no motivation to differ here, https://eel.is/c++draft/lex#phases-1.2.sentence-5 > > Thanks, > > Alex > > On Fri, 19 Sept 2025 at 12:23, Joseph Myers wrote: > >> On Fri, 19 Sep 2025, J=E2=82=91=E2=82=99=E2=82=9B Gustedt wrote: >> >> > Hi, >> > >> > on Fri, 19 Sep 2025 09:29:41 +0200 you (Martin Uecker >> > ) wrote: >> > >> > > =E2=80=A6 >> > > A new-line character is added at the end of the file. >> > > --- >> > > >> > > Or could this have some effect when not not unconditionally? >> > >> > I think so, in some situations empty lines separate. >> > >> > For example a file that ends in a backslash followed by a newline is >> > currently invalid. That change would make that a valid input file. >> >> However, there would be the case of a file ending with a backslash and n= o >> newline, where this change introduces a single newline in phase 1, then >> it >> gets removed with the backslash, leaving a final line after phase 2 with >> no terminating newline. So to ensure there's always a newline at end of >> file after phase 2 (which is what I prefer, over any approach introducin= g >> a constraint here), maybe two newlines should be implicitly added at the >> end of phase 1. >> >> -- >> Joseph S. Myers >> josmyers@redhat.com > > --000000000000b6b582063f2839c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Sep 19,= 2025 at 2:28=E2=80=AFPM Alex Celeste <alexg.nvfp@gmail.com> wrote:
Can someone enumerate the = implementation issues that would be caused and/or solved by choosing any of= the suggested paths forward here?

As an implement= er:
- I don't need the newline to exist in order to make sens= e of the file (the virtual newline interpretation is adequate);
-= the Standard doesn't place any requirements on a file _outputted_ by t= he preprocessor (or require it to be a provided functionality), so as a mat= ter of QoI a considerate tool should format preprocessed output in accordan= ce with whatever the host system needs, but this is out of scope for the do= cument

+1=C2=A0

Are we suggesting that because _other_ parts of the ecosystem require thi= s newline to exist, C should require it too?
That seems unnecessa= rily prescriptive, if we could just as easily be flexible in what we accept= .

(like Aaron suggests, the most likely upshot eit= her way is that tools continue to emit a suppressable warning and then comp= ile as though the newline had been injected)

As an implementer, we have supported files that do not en= d with a new line for decades and do not intend to change.
Clang = does have=C2=A0-Wnewline-eof, but this is not enabled, even under -Wextra, = and it's very unlikely that we would be willing to change that (GCC doe= s not even have such warning)

Here is the C++= wording. There is no motivation to differ here,
=C2=A0

Thanks,

Alex

On Fri, 19 Sept 2025= at 12:23, Joseph Myers <josmyers@redhat.com> wrote:
On Fri, 19 Sep 2025, J=E2=82=91=E2=82=99= =E2=82=9B Gustedt wrote:

> Hi,
>
> on Fri, 19 Sep 2025 09:29:41 +0200 you (Martin Uecker
> <ma.uecker= @gmail.com>) wrote:
>
> > =E2=80=A6
> > A new-line character is added at the end of the file.
> > ---
> >
> > Or could this have some effect when not not unconditionally?
>
> I think so, in some situations empty lines separate.
>
> For example a file that ends in a backslash followed by a newline is > currently invalid. That change would make that a valid input file.

However, there would be the case of a file ending with a backslash and no <= br> newline, where this change introduces a single newline in phase 1, then it =
gets removed with the backslash, leaving a final line after phase 2 with no terminating newline.=C2=A0 So to ensure there's always a newline at = end of
file after phase 2 (which is what I prefer, over any approach introducing <= br> a constraint here), maybe two newlines should be implicitly added at the end of phase 1.

--
Joseph S. Myers
josmyers@redhat.co= m
--000000000000b6b582063f2839c0--