From patchwork Sat Dec 6 22:14:53 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 418416 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id D81ED140119 for ; Sun, 7 Dec 2014 09:15:08 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=Ww4StfYtHoGK6IN9UqBnX1oIXnc8rzCV0vax9mlenX6Q2q /Mrx5k0l3y6aAxN0/yxTTWOye0loPr0QOOOS4FuY9RFFFQowyb028YcB6+dJCsCA ToxmyMKq7fltUSuKwyd/WI3oTQBtZXwvH8z87kJ3rHrkqoKrsDpqirElX5/es= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=DkcgcddSSLTPgmIqAjV1T3Su4pI=; b=aVDo6FnOZJ2JllqhAurc wFYxdZCemjQJpL32rPZWF5ffX5/zXKH6UlpSv3B20/tHEAOX0JFgCE/o2fhi1llO IHaerPL2e71A4pXPy4NqiclGuR1H6Adj3GWJjb6nic+wSXqyOkgSQxZdzZN7F0Tl G5RZLfQXSnwrN/LZjz74Ck4= Received: (qmail 11286 invoked by alias); 6 Dec 2014 22:15:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 11269 invoked by uid 89); 6 Dec 2014 22:14:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx01.qsc.de Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sat, 06 Dec 2014 22:14:57 +0000 Received: from tux.net-b.de (port-92-194-114-130.dynamic.qsc.de [92.194.114.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPSA id 1431C3CE56; Sat, 6 Dec 2014 23:14:53 +0100 (CET) Message-ID: <54837FDD.8000107@net-b.de> Date: Sat, 06 Dec 2014 23:14:53 +0100 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: gcc-patches , gfortran , =?UTF-8?B?TWFudWVsIEzDs3Blei1JYsOhw7Fleg==?= , Dodji Seketeli Subject: [RFC] diagnostics.c: For terminals, restrict messages to terminal width? This patch fixes a Fortran diagnostic "regression". With the current common diagnostic, the width shown with caret diagnostic is determined by: case OPT_fmessage_length_: pp_set_line_maximum_length (dc->printer, value); diagnostic_set_caret_max_width (dc, value); plus diagnostic_set_caret_max_width (diagnostic_context *context, int value) { /* One minus to account for the leading empty space. */ value = value ? value - 1 : (isatty (fileno (pp_buffer (context->printer)->stream)) ? getenv_columns () - 1: INT_MAX); if (value <= 0) value = INT_MAX; context->caret_max_width = value; } where getenv_columns looks at the environment variable COLUMNS. Note that -fmessage-length= applies to the error message (wraps) _and_ the caret diagnostic (truncates) while the COLUMNS variable _only_ applies to the caret diagnostic. (BTW: The documentation currently does not mention COLUMNS.) On most terminals, which I tried, COLUMNS does not seem to be set. In Fortran, error.c's get_terminal_width has a similar check, but additionally it uses ioctl to determine the terminal width. I think with caret diagnostics, it is useful not to exceed the terminal width as having several "empty" lines before the "^" does not really improve the readability. Thus, I would propose to additionally use ioctl. Which rises two questions: (a) Should the COLUMNS environment variable or ioctl have a higher priority? [Fortran ranks ioctl higher; in the patch, for backward compatibilty, I rank COLUMNS higher.] (b) Should ioctl be always used or only for Fortran? Comments? Tobias diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c index 28ef81c..9a29300 100644 --- a/gcc/diagnostic.c +++ b/gcc/diagnostic.c @@ -82,18 +82,27 @@ file_name_as_prefix (diagnostic_context *context, const char *f) /* Return the value of the getenv("COLUMNS") as an integer. If the - value is not set to a positive integer, then return INT_MAX. */ + value is not set to a positive integer, use ioctl to get the + terminal width. If it fails, return INT_MAX. */ static int -getenv_columns (void) +getenv_columns_and_termwidth (void) { const char * s = getenv ("COLUMNS"); if (s != NULL) { int n = atoi (s); if (n > 0) return n; } + +#ifdef TIOCGWINSZ + struct winsize w; + w.ws_col = 0; + if (ioctl (0, TIOCGWINSZ, &w) == 0 && w.ws_col > 0) + return w.ws_col; +#endif + return INT_MAX; } /* Set caret_max_width to value. */ @@ -102,9 +111,9 @@ diagnostic_set_caret_max_width (diagnostic_context *context, int value) { /* One minus to account for the leading empty space. */ value = value ? value - 1 : (isatty (fileno (pp_buffer (context->printer)->stream)) - ? getenv_columns () - 1: INT_MAX); + ? getenv_columns_and_termwidth () - 1: INT_MAX); if (value <= 0) value = INT_MAX;