why file descriptor an int - Unix

This is a discussion on why file descriptor an int - Unix ; while type "int" is system dependent...

+ Reply to Thread
Results 1 to 7 of 7

Thread: why file descriptor an int

  1. why file descriptor an int

    while type "int" is system dependent



  2. Re: why file descriptor an int

    "kkzhou" writes:

    >while type "int" is system dependent



    Does it matter? It simply says "you cannot have more filedescriptors
    than the natural integer type supports.

    As Unix did not have uint16_t etc defined, it was hard to do it in any other
    way; the meximum number of allowable files was "20" so "int" seemed
    as appropriate as anything.

    Casper
    --
    Expressed in this posting are my opinions. They are in no way related
    to opinions held by my employer, Sun Microsystems.
    Statements on Sun products included here are not gospel and may
    be fiction rather than truth.

  3. Re: why file descriptor an int

    oh, I meant that system calls such as "read(int filedes,..." have an int
    parameter which
    represents a system resource.
    In my opinion, "read( fd_t filedes,.." may be better as an interface defined
    by standard

    "Casper H.S. Dik" 写入消息新闻:47307fe8$0$238$e4fe514c@news.xs4all.n l...
    > "kkzhou" writes:
    >
    >>while type "int" is system dependent

    >
    >
    > Does it matter? It simply says "you cannot have more filedescriptors
    > than the natural integer type supports.
    >
    > As Unix did not have uint16_t etc defined, it was hard to do it in any
    > other
    > way; the meximum number of allowable files was "20" so "int" seemed
    > as appropriate as anything.
    >
    > Casper
    > --
    > Expressed in this posting are my opinions. They are in no way related
    > to opinions held by my employer, Sun Microsystems.
    > Statements on Sun products included here are not gospel and may
    > be fiction rather than truth.




  4. Re: why file descriptor an int

    In article ,
    "kkzhou" wrote:

    > oh, I meant that system calls such as "read(int filedes,..." have an int
    > parameter which
    > represents a system resource.
    > In my opinion, "read( fd_t filedes,.." may be better as an interface defined
    > by standard


    The convention of using typedefs like this is pretty recent, only about
    10 or so years old. The basic filesystem system calls are very old,
    going back over 30 years. Although some of the traditional APIs have
    been updated, file descriptors are often put in structures, so
    programmers would have to redefine all these structures to accomodate
    the change.

    So I guess they decided that forcing a change like this would be more
    trouble than it's worth.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  5. Re: why file descriptor an int

    Thanks.
    the specification things really interest me
    these days.

    "Barry Margolin" 写入消息新闻:barmar-1F4A78.01200207112007@comcast.dca.giganews.com...
    > In article ,
    > "kkzhou" wrote:
    >
    >> oh, I meant that system calls such as "read(int filedes,..." have an int
    >> parameter which
    >> represents a system resource.
    >> In my opinion, "read( fd_t filedes,.." may be better as an interface
    >> defined
    >> by standard

    >
    > The convention of using typedefs like this is pretty recent, only about
    > 10 or so years old. The basic filesystem system calls are very old,
    > going back over 30 years. Although some of the traditional APIs have
    > been updated, file descriptors are often put in structures, so
    > programmers would have to redefine all these structures to accomodate
    > the change.
    >
    > So I guess they decided that forcing a change like this would be more
    > trouble than it's worth.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***




  6. Re: why file descriptor an int

    Thanks.
    the specification things really interest me
    these days.

    "Barry Margolin" 写入消息新闻:barmar-1F4A78.01200207112007@comcast.dca.giganews.com...
    > In article ,
    > "kkzhou" wrote:
    >
    >> oh, I meant that system calls such as "read(int filedes,..." have an int
    >> parameter which
    >> represents a system resource.
    >> In my opinion, "read( fd_t filedes,.." may be better as an interface
    >> defined
    >> by standard

    >
    > The convention of using typedefs like this is pretty recent, only about
    > 10 or so years old. The basic filesystem system calls are very old,
    > going back over 30 years. Although some of the traditional APIs have
    > been updated, file descriptors are often put in structures, so
    > programmers would have to redefine all these structures to accomodate
    > the change.
    >
    > So I guess they decided that forcing a change like this would be more
    > trouble than it's worth.
    >
    > --
    > Barry Margolin, barmar@alum.mit.edu
    > Arlington, MA
    > *** PLEASE post questions in newsgroups, not directly to me ***
    > *** PLEASE don't copy me on replies, I'll read them in the group ***





  7. Re: why file descriptor an int

    "kkzhou" writes:

    >oh, I meant that system calls such as "read(int filedes,..." have an int
    >parameter which
    >represents a system resource.
    >In my opinion, "read( fd_t filedes,.." may be better as an interface defined
    >by standard


    I think you misunderstand how standards come into being; often in the
    POSIX/UNIX world they standardize what IS rather than would would
    be nice. Read existed and was standardized pretty much as is except
    there were changes were *required*. (The size_t argument n and the ssize_t
    return value which are pretty much requried changes for environments which
    get objects for which sizeof(x) > MAXINT)

    Casper

+ Reply to Thread