[SunHELP] Solaris 7 and FOPEN_MAX

[Nicholas Dronen]

On Fri, Jan 04, 2002 at 05:36:03PM +0000, Jarrett Carver wrote:

> Remedy has learned that the OS call we use to open files has a
> limitation. The call used is fopen or fdopen. Sun has indicated that
> these calls will work incorrectly if the file descriptor number is
> .255. If the file descriptor number is > 255 the ARERR 316 willoccur.
> This can be directly correlated to the Solaris limitation
> 
> This appears to be the problem, because when I truss I get:
> 
> #truss -o /tmp/remedy.truss -f -p 440
> [ Do some qureies that fail ]
> ^C
> #more /tmp/remedy.truss
> 440:    getpid()                                        = 440 [437]
> 440:    lstat64("/var/tmp/ARpenQSBi9fa3a", 0xFFBEF310)  Err#2 ENOENT
> 440:    open("/var/tmp/ARpenQSBi9fa3a", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 299
> 440:    close(299)
> 
> This seemed to be the answere, but then I read on the Solaris IAQ:

Correct.  This is because file descriptor member of the FILE
structure used with fopen is an unsigned char (see stdio_impl.h),
which can hold 0-255.  I think only Solaris and IRIX have this
problem.  Sun refused to fix it, perhaps for purposes of backward
compatibility.  It sure it a PITA for developers though.

> d. API limits (ref:Solaris Internals)
>        2. Solaris >= 7
>           a. stdio(3s) - 256 (32-bit) / 65536 (64-bit)
>           b. select(3c) - 1024 (32-bit) / 65536 (64-bit)
>              1. 65536 limit is attainable on 32-bit Solaris 7
>              2. #define FD_SETSIZE 65536   ; prior to includes

I believe the question is whether the nice folks who develop
Remedy compiled it with the preprocessor symbols ("defines")
required to get the 64-bit FILE structure.  If they didn't, 
I don't believe even a 128-bit kernel will do you much good.

Regards,

Nicholas Dronen