older standard drafts for download?

Discussion in 'C Programming' started by Kevin Goodsell, Nov 22, 2003.

  1. Is there a place I can download the last public draft for C89? What
    about a draft for C95?

    What I really need is a list of all standard library functions, macros,
    types, etc. for a "keyword file", which is used for syntax highlighting.
    I want to create one for both major C standards, with the C89/90 version
    including the 1995 amendment. I already have n869 for C99.

    Thanks.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Nov 22, 2003
    #1
    1. Advertising

  2. Kevin Goodsell

    Simon Biber Guest

    "Kevin Goodsell" <> wrote:
    > Is there a place I can download the last public draft for C89?
    > What about a draft for C95?
    >
    > What I really need is a list of all standard library functions,
    > macros, types, etc. for a "keyword file", which is used for
    > syntax highlighting. I want to create one for both major C
    > standards, with the C89/90 version including the 1995 amendment.
    > I already have n869 for C99.


    Hmm, I have a copy of the C89 draft -- here it is on my website:
    http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
    That's a 496 kilobyte ASCII text file, compressed with BZip2 to
    95.5 kilobytes.

    --
    Simon.
     
    Simon Biber, Nov 22, 2003
    #2
    1. Advertising

  3. Simon Biber wrote:

    >
    > Hmm, I have a copy of the C89 draft -- here it is on my website:
    > http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
    > That's a 496 kilobyte ASCII text file, compressed with BZip2 to
    > 95.5 kilobytes.
    >


    Thank you very much, Simon. Do you happen to know if this was the last
    public draft, or something earlier?

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Nov 22, 2003
    #3
  4. Kevin Goodsell

    Dan Pop Guest

    In <%9Gvb.9372$> Kevin Goodsell <> writes:

    >Simon Biber wrote:
    >
    >> Hmm, I have a copy of the C89 draft -- here it is on my website:
    >> http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
    >> That's a 496 kilobyte ASCII text file, compressed with BZip2 to
    >> 95.5 kilobytes.

    >
    >Thank you very much, Simon. Do you happen to know if this was the last
    >public draft, or something earlier?


    The last public draft. It is the document on which the first printing
    of K&R2 was based.

    For C95, have a look at http://www.lysator.liu.se/c/na1.html

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 24, 2003
    #4
  5. Kevin Goodsell

    jtp Guest

    "Simon Biber" <> wrote in message news:<3fbece23$0$20496$>...
    > "Kevin Goodsell" <> wrote:
    > > Is there a place I can download the last public draft for C89?
    > > What about a draft for C95?
    > >
    > > What I really need is a list of all standard library functions,
    > > macros, types, etc. for a "keyword file", which is used for
    > > syntax highlighting. I want to create one for both major C
    > > standards, with the C89/90 version including the 1995 amendment.
    > > I already have n869 for C99.

    >
    > Hmm, I have a copy of the C89 draft -- here it is on my website:
    > http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
    > That's a 496 kilobyte ASCII text file, compressed with BZip2 to
    > 95.5 kilobytes.


    Is there any chance to get it compressed with WinZip. ;)
     
    jtp, Nov 25, 2003
    #5
  6. Kevin Goodsell

    Simon Biber Guest

    "jtp" <> wrote:
    > "Simon Biber" <> wrote:
    > > "Kevin Goodsell" <> wrote:
    > > > Is there a place I can download the last public draft for C89?
    > > > What about a draft for C95?
    > > >
    > > > What I really need is a list of all standard library functions,
    > > > macros, types, etc. for a "keyword file", which is used for
    > > > syntax highlighting. I want to create one for both major C
    > > > standards, with the C89/90 version including the 1995 amendment.
    > > > I already have n869 for C99.

    > >
    > > Hmm, I have a copy of the C89 draft -- here it is on my website:
    > > http://members.optushome.com.au/sbiber/stuff/ansic89.txt.bz2
    > > That's a 496 kilobyte ASCII text file, compressed with BZip2 to
    > > 95.5 kilobytes.

    >
    > Is there any chance to get it compressed with WinZip. ;)


    You could try to convince WinZip to support the BZip2 format first,
    they support its predecessor GZip. Or, move over to a better
    shell-integrated archive and compression program, PowerArchiver,
    which does support BZip2... http://www.powerarchiver.com/

    Or, you can download a small utility bzip2-102-x86-win32.exe (72 KB)
    from ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe

    --
    Simon.
     
    Simon Biber, Nov 25, 2003
    #6
  7. Kevin Goodsell

    CBFalconer Guest

    Simon Biber wrote:
    > "jtp" <> wrote:
    >

    .... snip ...
    > >
    > > Is there any chance to get it compressed with WinZip. ;)

    >
    > You could try to convince WinZip to support the BZip2 format first,
    > they support its predecessor GZip. Or, move over to a better
    > shell-integrated archive and compression program, PowerArchiver,
    > which does support BZip2... http://www.powerarchiver.com/
    >
    > Or, you can download a small utility bzip2-102-x86-win32.exe (72 KB)
    > from ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe


    The point is that bzip2 compresses significantly more than does
    zip, although it takes longer to do so. However decompression
    speed is comparable. So there is a significant gain in using
    bzip2 whenever files are to be downloaded, or when decompression
    is used more often than compression.

    jtp should have been looking into how to get the system on his
    machine, which Mr. Biber has made easy for him. I believe a
    google for bzip2 will turn up more.

    People posting such compressed files should ensure that their
    servers properly characterize the files as binary (the mime
    type). Failure to do so can fatally harm the transmission.

    --
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Nov 25, 2003
    #7
  8. Kevin Goodsell

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >Simon Biber wrote:
    >> "jtp" <> wrote:
    >>

    >... snip ...
    >> >
    >> > Is there any chance to get it compressed with WinZip. ;)

    >>
    >> You could try to convince WinZip to support the BZip2 format first,
    >> they support its predecessor GZip. Or, move over to a better
    >> shell-integrated archive and compression program, PowerArchiver,
    >> which does support BZip2... http://www.powerarchiver.com/
    >>
    >> Or, you can download a small utility bzip2-102-x86-win32.exe (72 KB)
    >> from ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe

    >
    >The point is that bzip2 compresses significantly more than does
    >zip, although it takes longer to do so. However decompression
    >speed is comparable. So there is a significant gain in using
    >bzip2 whenever files are to be downloaded, or when decompression
    >is used more often than compression.
    >
    >jtp should have been looking into how to get the system on his
    >machine, which Mr. Biber has made easy for him. I believe a
    >google for bzip2 will turn up more.
    >
    >People posting such compressed files should ensure that their
    >servers properly characterize the files as binary (the mime
    >type). Failure to do so can fatally harm the transmission.


    That's sheer hypocrisy! ;-) The very person claiming that plain text is
    the only truly portable file format is now arguing the merits of one
    binary file format over another.

    BTW, the document is still available in plain text format in the place it
    was originally posted... Don't ask me where, search the c.l.c archives.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 25, 2003
    #8
  9. Kevin Goodsell

    CBFalconer Guest

    Dan Pop wrote:
    > CBFalconer <> writes:
    > >Simon Biber wrote:
    > >>

    > >... snip ...
    > >>
    > >> Or, you can download a small utility bzip2-102-x86-win32.exe (72 KB)
    > >> from ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe

    > >
    > >The point is that bzip2 compresses significantly more than does
    > >zip, although it takes longer to do so. However decompression
    > >speed is comparable. So there is a significant gain in using
    > >bzip2 whenever files are to be downloaded, or when decompression
    > >is used more often than compression.
    > >
    > >jtp should have been looking into how to get the system on his
    > >machine, which Mr. Biber has made easy for him. I believe a
    > >google for bzip2 will turn up more.
    > >
    > >People posting such compressed files should ensure that their
    > >servers properly characterize the files as binary (the mime
    > >type). Failure to do so can fatally harm the transmission.

    >
    > That's sheer hypocrisy! ;-) The very person claiming that plain
    > text is the only truly portable file format is now arguing the
    > merits of one binary file format over another.


    You actually have a valid point there :) However you might do
    well to think of zip, bzip2, lhz, arj, arc, etc. more as means of
    packing for transmission (or storage), since in all cases the
    transition TEXT -> <bin> -> TEXT is lossless and well defined.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Nov 26, 2003
    #9
  10. Kevin Goodsell

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >Dan Pop wrote:
    >> CBFalconer <> writes:
    >> >Simon Biber wrote:
    >> >>
    >> >... snip ...
    >> >>
    >> >> Or, you can download a small utility bzip2-102-x86-win32.exe (72 KB)
    >> >> from ftp://sources.redhat.com/pub/bzip2/v102/bzip2-102-x86-win32.exe
    >> >
    >> >The point is that bzip2 compresses significantly more than does
    >> >zip, although it takes longer to do so. However decompression
    >> >speed is comparable. So there is a significant gain in using
    >> >bzip2 whenever files are to be downloaded, or when decompression
    >> >is used more often than compression.
    >> >
    >> >jtp should have been looking into how to get the system on his
    >> >machine, which Mr. Biber has made easy for him. I believe a
    >> >google for bzip2 will turn up more.
    >> >
    >> >People posting such compressed files should ensure that their
    >> >servers properly characterize the files as binary (the mime
    >> >type). Failure to do so can fatally harm the transmission.

    >>
    >> That's sheer hypocrisy! ;-) The very person claiming that plain
    >> text is the only truly portable file format is now arguing the
    >> merits of one binary file format over another.

    >
    >You actually have a valid point there :) However you might do
    >well to think of zip, bzip2, lhz, arj, arc, etc. more as means of
    >packing for transmission (or storage), since in all cases the

    ^^^^^^^^^^^^
    >transition TEXT -> <bin> -> TEXT is lossless and well defined.


    You're missing my point. The transition

    local.text -> local.bin -> remote.bin -> remote.text

    is not well defined at all, even if remote.bin can be decoded.
    The point is that the compressor treats local.text as a *binary* file
    completely ignoring its line structured format. When decoding it, you
    get the original bytes of the text file, but they may be completely
    meaningless as a text file on the remote host, if it uses an incompatible
    format for representing text files.

    OTOH, the transition local.text -> remote.text is (normally) aware of the
    text nature of the data being transferred and the information allowing to
    separate the data into lines of text is sent in a format understood by
    both parties, so the textual information is safely transferred.

    As a trivial example, take a text file on a Unix box, zip it, transfer the
    binary to a Windows box and unzip it. The result is not a valid Windows
    text file. The fix is trivial in such a case, but it's less trivial if
    you transfer the binary to an IBM mainframe instead of a Windows box.
    Even less trivial when dealing with record based text file formats...

    OTOH, any text file transfer protocol (e.g. FTP) will do the right thing
    when transfering text files in text mode, character set conversions
    included.

    On a related note, there is a subtle trap awaiting the unsuspecting Unix
    programmer. The Unix convention is that each line of text is terminated
    by an ASCII LF character, but most network protocols dealing with text
    data use the CR + LF pair as line terminator. So, our unsuspecting Unix
    programmer gets a line of text from a remote host using one such protocol,
    carefully strips the LF character at the end and then displays it
    like this:

    printf("line starts here -->%s<-- line ends here\n", line);

    and is completely baffled by the program's output ;-)

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 26, 2003
    #10
  11. Dan Pop wrote:
    >
    > You're missing my point. The transition
    >
    > local.text -> local.bin -> remote.bin -> remote.text
    >
    > is not well defined at all, even if remote.bin can be decoded.
    > The point is that the compressor treats local.text as a *binary* file
    > completely ignoring its line structured format. When decoding it, you
    > get the original bytes of the text file, but they may be completely
    > meaningless as a text file on the remote host, if it uses an incompatible
    > format for representing text files.


    Some decompressors will attempt to convert text files to the correct
    format. I had a problem with this recently that confused me for a while.
    I downloaded the JPEG library from the Independent JPEG Group, which is
    a tarred + gzipped archive and extracted it without incident using
    WinZip. The programs compiled just fine (I was a little surprised to
    find the source files in MS-DOS format, but the reason became clear later).

    The archive also contained some images for testing purposes. The tests
    included things like compressing a bitmap image and comparing it to a
    JPEG image, with the expectation that the file should be identical if
    the program compiled correctly. But some of the tests failed. The test
    images were a red rose, but one of the files (a .ppm file) showed a
    bright green rose instead. Obviously, when this green rose was
    compressed it was not identical to the compressed red rose.

    It turns out that WinZip attempts to "fix" text files when it extracts
    them from a tar archive. It incorrectly identified the .ppm file as
    text, and inserted some extra bytes. This offset the color channels,
    putting the red intensities into the green channel, and making the red
    rose turn green. Somehow the result was still close enough to a valid
    ..ppm that the programs I was using didn't complain.

    So WinZip tried to correct for the problem you described above, but
    corrected incorrectly (though it did the right thing with the source
    files). You can turn off this option in WinZip, by the way, and most
    people probably should do so.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Nov 26, 2003
    #11
  12. Kevin Goodsell

    CBFalconer Guest

    Kevin Goodsell wrote:
    > Dan Pop wrote:
    > >
    > > You're missing my point. The transition
    > >
    > > local.text -> local.bin -> remote.bin -> remote.text
    > >
    > > is not well defined at all, even if remote.bin can be decoded.
    > > The point is that the compressor treats local.text as a *binary*
    > > file completely ignoring its line structured format. When
    > > decoding it, you get the original bytes of the text file, but
    > > they may be completely meaningless as a text file on the remote
    > > host, if it uses an incompatible format for representing text
    > > files.

    >
    > Some decompressors will attempt to convert text files to the
    > correct format. I had a problem with this recently that confused
    > me for a while. I downloaded the JPEG library from the Independent
    > JPEG Group, which is a tarred + gzipped archive and extracted it
    > without incident using WinZip. The programs compiled just fine (I
    > was a little surprised to find the source files in MS-DOS format,
    > but the reason became clear later).
    >
    > The archive also contained some images for testing purposes. The
    > tests included things like compressing a bitmap image and
    > comparing it to a JPEG image, with the expectation that the file
    > should be identical if the program compiled correctly. But some
    > of the tests failed. The test images were a red rose, but one of
    > the files (a .ppm file) showed a bright green rose instead.
    > Obviously, when this green rose was compressed it was not
    > identical to the compressed red rose.
    >
    > It turns out that WinZip attempts to "fix" text files when it
    > extracts them from a tar archive. It incorrectly identified the
    > .ppm file as text, and inserted some extra bytes. This offset
    > the color channels, putting the red intensities into the green
    > channel, and making the red rose turn green. Somehow the result
    > was still close enough to a valid .ppm that the programs I was
    > using didn't complain.
    >
    > So WinZip tried to correct for the problem you described above,
    > but corrected incorrectly (though it did the right thing with
    > the source files). You can turn off this option in WinZip, by
    > the way, and most people probably should do so.


    To preserve my disgust with most things gui, I use zip and unzip
    (from Infozip), which are available for most platforms. The
    following is an excerpt from the unzip manual.

    -a convert text files. Ordinarily all files are
    extracted exactly as they are stored (as ``binary''
    files). The -a option causes files identified by
    zip as text files (those with the `t' label in zip-
    info listings, rather than `b') to be automatically
    extracted as such, converting line endings, end-of-
    file characters and the character set itself as
    necessary. (For example, Unix files use line feeds
    (LFs) for end-of-line (EOL) and have no end-of-file
    (EOF) marker; Macintoshes use carriage returns
    (CRs) for EOLs; and most PC operating systems use
    CR+LF for EOLs and control-Z for EOF. In addition,
    IBM mainframes and the Michigan Terminal System use
    EBCDIC rather than the more common ASCII character
    set, and NT supports Unicode.) Note that zip's
    identification of text files is by no means
    perfect; some ``text'' files may actually be binary
    and vice versa. unzip therefore prints ``[text]''
    or ``[binary]'' as a visual check for each file it
    extracts when using the -a option. The -aa option
    forces all files to be extracted as text, regard-
    less of the supposed file type.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Nov 27, 2003
    #12
  13. Kevin Goodsell

    Dan Pop Guest

    In <oB6xb.15794$> Kevin Goodsell <> writes:

    >Dan Pop wrote:
    >>
    >> You're missing my point. The transition
    >>
    >> local.text -> local.bin -> remote.bin -> remote.text
    >>
    >> is not well defined at all, even if remote.bin can be decoded.
    >> The point is that the compressor treats local.text as a *binary* file
    >> completely ignoring its line structured format. When decoding it, you
    >> get the original bytes of the text file, but they may be completely
    >> meaningless as a text file on the remote host, if it uses an incompatible
    >> format for representing text files.

    >
    >Some decompressors will attempt to convert text files to the correct
    >format. I had a problem with this recently that confused me for a while.
    >I downloaded the JPEG library from the Independent JPEG Group, which is
    >a tarred + gzipped archive and extracted it without incident using
    >WinZip. The programs compiled just fine (I was a little surprised to
    >find the source files in MS-DOS format, but the reason became clear later).
    >
    >The archive also contained some images for testing purposes. The tests
    >included things like compressing a bitmap image and comparing it to a
    >JPEG image, with the expectation that the file should be identical if
    >the program compiled correctly. But some of the tests failed. The test
    >images were a red rose, but one of the files (a .ppm file) showed a
    >bright green rose instead. Obviously, when this green rose was
    >compressed it was not identical to the compressed red rose.
    >
    >It turns out that WinZip attempts to "fix" text files when it extracts
    >them from a tar archive. It incorrectly identified the .ppm file as
    >text, and inserted some extra bytes. This offset the color channels,
    >putting the red intensities into the green channel, and making the red
    >rose turn green. Somehow the result was still close enough to a valid
    >.ppm that the programs I was using didn't complain.
    >
    >So WinZip tried to correct for the problem you described above, but
    >corrected incorrectly (though it did the right thing with the source
    >files). You can turn off this option in WinZip, by the way, and most
    >people probably should do so.


    Identifying the nature of a file from its extension is a brain dead idea.
    Different platforms use completely different conventions.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 27, 2003
    #13
  14. Kevin Goodsell

    Dan Pop Guest

    In <> CBFalconer <> writes:

    >To preserve my disgust with most things gui, I use zip and unzip
    >(from Infozip), which are available for most platforms. The
    >following is an excerpt from the unzip manual.
    >
    > -a convert text files. Ordinarily all files are
    > extracted exactly as they are stored (as ``binary''
    > files). The -a option causes files identified by
    > zip as text files (those with the `t' label in zip-
    > info listings, rather than `b') to be automatically
    > extracted as such, converting line endings, end-of-
    > file characters and the character set itself as
    > necessary. (For example, Unix files use line feeds
    > (LFs) for end-of-line (EOL) and have no end-of-file
    > (EOF) marker; Macintoshes use carriage returns
    > (CRs) for EOLs; and most PC operating systems use
    > CR+LF for EOLs and control-Z for EOF. In addition,
    > IBM mainframes and the Michigan Terminal System use
    > EBCDIC rather than the more common ASCII character
    > set, and NT supports Unicode.) Note that zip's
    > identification of text files is by no means
    > perfect; some ``text'' files may actually be binary
    > and vice versa. unzip therefore prints ``[text]''
    > or ``[binary]'' as a visual check for each file it
    > extracts when using the -a option. The -aa option
    > forces all files to be extracted as text, regard-
    > less of the supposed file type.


    It's not clear how it identifies the format of the original text file,
    in order to be able to convert it to the local format. E.g. how does it
    decide when to convert from EBCDIC to the local character set, or how
    it decides which ISO-8859 flavour was used by the original when converting
    to Unicode.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 27, 2003
    #14
  15. Dan Pop wrote:
    > In <oB6xb.15794$> Kevin Goodsell <> writes:
    >
    > Identifying the nature of a file from its extension is a brain dead idea.
    > Different platforms use completely different conventions.


    Agreed. Actually, WinZip examines the first N bytes (don't recall what N
    is exactly, but the help documents explain the method) and guesses based
    on that. Obviously, this method doesn't always work. I don't believe
    there is any general way to identify the nature of a file based only on
    the name and content.

    -Kevin
    --
    My email address is valid, but changes periodically.
    To contact me please use the address from a recent posting.
     
    Kevin Goodsell, Nov 27, 2003
    #15
  16. Dan Pop wrote:

    <snip>

    > Identifying the nature of a file from its extension is a brain dead idea.
    > Different platforms use completely different conventions.


    Hallelujah, amen, etc. It makes a pleasant change to agree with you.

    Semi-topical semi-relevant mini-saga follows. Switch off now if you aren't
    up for it.

    A few years ago, I was working on a (Windows) site where a considerable
    number of people used an application which named its files with a .pdf
    extension ("program description format" or something). Then someone had the
    bright idea of writing a project-wide information-sharing system (where you
    could find out things like pizza company phone numbers), and since they
    were doing a lot of Portable Document Format stuff for their PhD, they
    decided to use it here too. (You're all ahead of me, I know...)

    Of course, nobody consulted the existing .pdf users; the software was just
    installed on their machines without them even being told about it. So now,
    when they double-clicked their myprogramdescriptionformat.pdf files, the
    wrong application fired up and complained that their (perfectly correct)
    files contained errors.

    My suggested fix was to install Linux, of course, but since (for some
    reason) that wasn't considered acceptable, I ended up writing a program (in
    ISO C!!!) that would peek at the .pdf file and launch the appropriate
    application depending on the file *contents*. We simply slid this into the
    mix as an extra level of indirection, and everyone was happy.

    It was a bodge, of course, and it should not have been necessary. File
    associations are an unnecessary evil.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Nov 27, 2003
    #16
  17. Kevin Goodsell

    CBFalconer Guest

    Richard Heathfield wrote:
    >

    .... snip ...
    >
    > My suggested fix was to install Linux, of course, but since (for
    > some reason) that wasn't considered acceptable, I ended up writing
    > a program (in ISO C!!!) that would peek at the .pdf file and
    > launch the appropriate application depending on the file
    > *contents*. We simply slid this into the mix as an extra level of
    > indirection, and everyone was happy.
    >
    > It was a bodge, of course, and it should not have been necessary.
    > File associations are an unnecessary evil.


    Not too long ago under MsDos there were various decompressor
    handling programs that did exactly that. Some were even table
    driven, and could specify magic id phrases and where they were to
    be found. They also had provisions for translating command lines
    for the appropriate decompressor. SHEZ combined this with a
    windowed display.

    These systems were especially handy in decompressing and
    distributing FidoNet mail, and enabled easy installation of better
    compression methods.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Nov 28, 2003
    #17
  18. Kevin Goodsell

    Dan Pop Guest

    In <MCtxb.19654$> Kevin Goodsell <> writes:

    >Dan Pop wrote:
    >> In <oB6xb.15794$> Kevin Goodsell <> writes:
    >>
    >> Identifying the nature of a file from its extension is a brain dead idea.
    >> Different platforms use completely different conventions.

    >
    >Agreed. Actually, WinZip examines the first N bytes (don't recall what N
    >is exactly, but the help documents explain the method) and guesses based
    >on that. Obviously, this method doesn't always work. I don't believe
    >there is any general way to identify the nature of a file based only on
    >the name and content.


    It is possible to develop a set of platform specific rules that works
    with a probability close to 100% for each file larger than, say, 1K,
    but they would not be portable to another system. For example, on Unix
    systems, assuming only 8-bit characters (ISO-8859 character sets) it
    would look like that:

    Only a few control characters in the range 0-31 accepted.
    No characters in the range 128 - 159 accepted.
    No line larger than, say, 200 characters, accepted.

    Even ignoring Unicode files, this wouldn't work on Windows, because
    Microsoft has populated the range reserved to extended control characters
    (128 - 159) with printable characters.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Nov 28, 2003
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nikos Kostis
    Replies:
    0
    Views:
    1,095
    Nikos Kostis
    Jul 6, 2003
  2. Curt_C [MVP]

    Obtaining older versions of IE for testing

    Curt_C [MVP], Apr 16, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    1,267
    Guest
    Apr 16, 2004
  3. Dean R. Henderson
    Replies:
    1
    Views:
    375
    Dean R. Henderson
    Apr 25, 2005
  4. Darrel
    Replies:
    2
    Views:
    320
    darrel
    Mar 20, 2006
  5. Enrico `Trippo' Porreca

    C89 drafts

    Enrico `Trippo' Porreca, May 20, 2004, in forum: C Programming
    Replies:
    8
    Views:
    2,936
    trunsk14
    Mar 12, 2008
Loading...

Share This Page