Skip site navigation (1) Skip section navigation (2)

Re: pg_dump return status..

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_dump return status..
Date: 2001-01-05 22:17:09
Message-ID: 20010105141709.E10336@store.zembu.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-hackers
On Fri, Jan 05, 2001 at 11:20:43AM -0500, Tom Lane wrote:
> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> > how do I
> > check for a failed write in a way that works on all Unixes? Is the
> > following OK:
> 
> > - fwrite: ok if return value equals item count
> > - fprintf: ok if return value > 0.
> > - fputc: ok if != EOF
> 
> Probably fprintf() >= 0 --- according to my specs, it returns the number
> of chars emitted, or a negative value on error.  The other two are
> correct.

An fprintf returning 0 is a suspicious event; it's easy to imagine 
cases where it makes sense, but I don't think I have ever coded one.
Probably >N (where N is the smallest reasonable output, defaulting 
to 1) may be a better test in real code.

As I recall, on SunOS 4 the printf()s don't return the number of 
characters written.  I don't recall what they do instead, and have
no access to such machines any more.

Other old BSD-derived systems are likely to have have wonky return 
values/types on the printf()s.  Looking at the list of supported 
platforms, none jump out as likely candidates, but in the "unsupported" 
list, Ultrix and NextStep do.  (Do we care?)

If SunOS 4 is to remain a supported platform, the printf checks may 
need to be special-cased for it.

Nathan Myers
ncm(at)zembu(dot)com

In response to

Responses

pgsql-hackers by date

Next:From: Ian Lance TaylorDate: 2001-01-05 22:26:13
Subject: Re: pg_dump return status..
Previous:From: Ian Lance TaylorDate: 2001-01-05 22:13:27
Subject: Re: Recursion and SPI

pgsql-general by date

Next:From: Uro GruberDate: 2001-01-05 22:17:29
Subject: PHP and PostgreSQL
Previous:From: The Hermit HackerDate: 2001-01-05 22:03:14
Subject: Re: mysql data to pgsql

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group