Re: Large file support available - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Large file support available
Date
Msg-id 200208212114.g7LLEr706369@candle.pha.pa.us
Whole thread Raw
In response to Re: Large file support available  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Large file support available  (Bruce Momjian <pgman@candle.pha.pa.us>)
List 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: @(#)Mordred Labs advisory 0x0003: Buffer overflow in
Next
From: ngpg@grymmjack.com
Date:
Subject: Re: [SECURITY] DoS attack on backend possible