From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-93769-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 94425 invoked by alias); 28 Jun 2018 21:07:39 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 94164 invoked by uid 89); 28 Jun 2018 21:07:39 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=guidelines, harness
X-HELO: mx1.redhat.com
From: DJ Delorie <dj@redhat.com>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: RFC V3 [1/2] test-in-container
In-Reply-To: <dad0a2f1-1e9e-061d-47a4-7fe70f3a4327@redhat.com> (message from Florian Weimer on Tue, 26 Jun 2018 15:04:18 +0200)
Date: Thu, 28 Jun 2018 21:07:00 -0000
Message-ID: <xnin62hb6v.fsf@greed.delorie.com>
MIME-Version: 1.0
Content-Type: text/plain
X-SW-Source: 2018-06/txt/msg00923.txt.bz2


Florian Weimer <fweimer@redhat.com> writes:
> On 03/02/2018 12:05 AM, DJ Delorie wrote:
>> +  sfd = open (sname, O_RDONLY);
>> +  if (sfd < 0)
>> +      error (EXIT_UNSUPPORTED, errno,
>> +	     "unable to open %s for reading\n", sname);
>> +
>> +  if (stat (sname, &st) < 0)
>> +      error (EXIT_UNSUPPORTED, errno,
>> +	     "unable to stat %s\n", sname);
>
> Should this be fstat64?

Probably :-)

>> +  dfd = open (dname, O_WRONLY | O_TRUNC | O_CREAT, 0600);
>> +  if (dfd < 0)
>> +    error (EXIT_UNSUPPORTED, errno,
>> +	   "unable to open %s for writing\n", dname);
>
> EXIT_UNSUPPORTED does not appear to be correct here.  These should be 
> hard failures IMHO.

Are there good guidelines for dealing with failures in the test harness
itself, rather than errors resulting from the actual thing being tested?
Or do we lump them all as "fail" and let the developers sort it out?