fseek

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Chris Torek

    #61
    Re: fseek

    In article <XPEsb.134993$m Z5.932687@attbi _s54>
    Glen Herrmannsfeldt <gah@ugcs.calte ch.edu> writes:[color=blue]
    >There could be systems that keep text and binary files completely
    >separate, such that no operations are allowed on the wrong type.
    >I don't know of any, though.[/color]

    VMS does something arguably more useful than that. In VMS, files
    have a great deal of structure, which is normally managed by RMS
    (the "record management system" -- code that, as Ken Thompson wrote
    so long ago, "fills a much-needed gap" :-) ). If you have a file
    with (say) variable-length records, and open it as a fixed-length
    record file, RMS will pad and (I presume) truncate records as
    required to fit the data into the Procrustean bed. Similarly, if
    you open a variable-length record file as text, RMS (or the C
    runtime library -- pre-VMS-5.0 and Stream-LF files, I imagine it
    was done outside RMS proper) can break up the records with
    artificially-inserted newlines.

    In any case, if one has ever actually used these operating systems
    that fail to provide the much-needed gap -- i.e., the ones that
    have a plethora of forcibly-imposed file formats -- one should
    begin to understand the strong constraints put on the C programmer
    by the C standards.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.

    Comment

    • glen herrmannsfeldt

      #62
      Re: fseek

      Chris Torek wrote:
      [color=blue]
      > In article <XPEsb.134993$m Z5.932687@attbi _s54>
      > Glen Herrmannsfeldt <gah@ugcs.calte ch.edu> writes:
      >[color=green]
      >>There could be systems that keep text and binary files completely
      >>separate, such that no operations are allowed on the wrong type.
      >>I don't know of any, though.[/color]
      >
      > VMS does something arguably more useful than that. In VMS, files
      > have a great deal of structure, which is normally managed by RMS
      > (the "record management system" -- code that, as Ken Thompson wrote
      > so long ago, "fills a much-needed gap" :-) ). If you have a file
      > with (say) variable-length records, and open it as a fixed-length
      > record file, RMS will pad and (I presume) truncate records as
      > required to fit the data into the Procrustean bed. Similarly, if
      > you open a variable-length record file as text, RMS (or the C
      > runtime library -- pre-VMS-5.0 and Stream-LF files, I imagine it
      > was done outside RMS proper) can break up the records with
      > artificially-inserted newlines.[/color]

      (snip)

      That sounds somewhat more useful than what I believe some IBM OS's do.
      If you open a file, coding fixed instead of variable, or the other way
      around, it will change the DSCB (file system file descriptor) but not
      change the data.

      -- glen

      Comment

      • Alan Balmer

        #63
        Re: fseek

        On Thu, 13 Nov 2003 23:13:02 GMT, lawrence.jones@ eds.com wrote:
        [color=blue]
        >Alan Balmer <albalmer@att.n et> wrote [re 7.19.5.3]:[color=green]
        >>
        >> This paragraph only describes the mode that the stream is opened in,
        >> saying nothing about the files themselves.[/color]
        >
        >On the contrary, it specifically says that modes containing "b" open
        >binary files and modes without "b" open text files. It does not say
        >what happens if the named file is not of the correct type, so you get
        >undefined behavior if you use the return stream (if there is one).
        >[/color]
        Right. I hadn't noticed that (or it didn't register at the time),
        being in the comments on the mode strings rather than in the function
        description. I do think that the standard is unclear on this - given
        the fuzziness of other relevant passages (including what Dan Pop
        describes as a bug in the standard) and given the fact that other
        behavior is explicitly identified as undefined, in the same paragraph.
        Writing standards in English is non-trivial :-)

        (Late response - I took a day off from c.l.c to get some work done,
        and came back to 400-odd messages, which is why I don't look at c.l.c
        when I have a deadline <g>.)

        --
        Al Balmer
        Balmer Consulting
        removebalmercon sultingthis@att .net

        Comment

        Working...