Re: Large file support available

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Large file support available
Date: 2002-08-21 21:14:53
Message-ID: 200208212114.g7LLEr706369@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Also, even with configure --disable-largefile, I find that pg_config.h
> > still contains
> >
> > /* Define to 1 to make fseeko visible on some hosts. */
> > #define _LARGEFILE_SOURCE 1
> >
> > /* Define to 1 if fseeko (and presumably ftello) exists and is declared. */
> > #define HAVE_FSEEKO 1
> >
> > This strikes me as probably Not a Good Thing, although I haven't dug to
> > see what the implications are.
>
> This is harmless (until proven otherwise). fseeko() is identical to
> fseek() except that the offset argument uses off_t, and _LARGEFILE_SOURCE
> makes fseeko() and friends visible in the headers. That's all. No large
> files involved.

I am confused. fseeko() doesn't look standard to me. I though
fgetpos/fsetpos() where the standard interfaces for large file support;
from BSD/OS:

The fgetpos(), fsetpos(), fseek(), ftell(), and rewind() functions con-
form to ANSI C X3.159-1989 (``ANSI C '').

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ngpg 2002-08-21 21:28:52 Re: [SECURITY] DoS attack on backend possible
Previous Message Bruce Momjian 2002-08-21 21:05:01 Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in