7-zip and p7zip 4.13 - futur evolutions

my space
2004-12-17
2012-12-08
  • my space
    my space
    2004-12-17

    Thank you, Igor Pavlov, to make your code more portable with each of your version.

    p7zip 4.13 and 7-zip 4.13 have now a lot of common files.

    In order to minimize the number of different files,
    can you take a look at the code of p7zip 4.13 to import some minor fixes :
    CpioItem.h : IsDirectory()
    Console/MainAr.cpp : see the call of Main2
    Wildcard.cpp : need fixes to support filesystem with case-insensitive filename

    Because some fixes where done to please "valgrind", take a look at :
    DeflateEncoder.cpp

    7za/7z have a strange behaviour for an unix tool :
    The messages are always sent to stderr.

    On Unix, the archiver GUI are often frond-end to console tools
    and the GUI launches something like that : " cmd > mess 2>error"
    If the command do not return 0, the GUI can display the error
    from the "error" file.

    But, if "mess" and "error" are in the same stream, how to
    display the error message ?

    The messages should only be sent to stderr when the "-so" flag is used.

    There is no "-q" flag that disable messages (but not errors messages).

    So, I propose this :
    - all errors messages are sent to stderr
    - all other messages are sent to "StdMess".

    7za/7z parse the command arguments before using "StdMess".
    if "-q" flag is here => StdMess discard all messages
    else if "-so" is here => StdMess is stderr
    else StdMess is stdout.

    Then you can use "StdMess" to display banner and the result of the command.

    What do you think about this behaviour ?

    If you agreed, do you plan to include this evolution for the next version ?

    Another question : the file permissions (and links, uid, gid ...)
    If you make changes to support NTFS file permissions, please also think about
    Unix file permissions (see informations that can be found in the tar format).

     
    • Igor Pavlov
      Igor Pavlov
      2004-12-23

      > Because some fixes where done to please "valgrind", take a look at :
      DeflateEncoder.cpp

      Can you explain me it?

      1)
          Byte dummy = m_LastLevels[kDistTableStart + i];
          if (dummy != 0) // NEED FIXED (1) to avoid Conditional jump or move depends on uninitialised value(s)

      Why here?
      Why not 8 lines before:
          UInt32 slot = g_LenSlots[i];
          Byte dummy = m_LastLevels[kMatchNumber + slot];

      2)
        Byte newLevels[kMaxTableSize64 + 1]; // (+ 1) for guard

        memset(newLevels, 0, kMaxTableSize64); // FIXED (1)

        m_MainCoder.BuildTree(&newLevels[0]);

      BuildTree can fill this array.

       
      • my space
        my space
        2004-12-23

        > 1)
        >    Byte dummy = m_LastLevels[kDistTableStart + i];
        >    if (dummy != 0) // NEED FIXED (1) to avoid Conditional jump or move depends
        >on uninitialised value(s)

        >Why here?
        >Why not 8 lines before:
        >    UInt32 slot = g_LenSlots[i];
        >    Byte dummy = m_LastLevels[kMatchNumber + slot];

        I don't know :
        perharps (kMatchNumber + slot) is always inferior than (kDistTableStart + i) ?

        >2)
        >  Byte newLevels[kMaxTableSize64 + 1]; // (+ 1) for guard
        >  memset(newLevels, 0, kMaxTableSize64); // FIXED (1)
        >
        >  m_MainCoder.BuildTree(&newLevels[0]);

        > BuildTree can fill this array.

        Are you sure that "m_MainCoder.BuildTree" fills all the kMaxTableSize64 values of newLevels ?

        Valgrind seems to say that "m_LastLevels[kDistTableStart + i]" is not initialized by
        "m_MainCoder.BuildTree".
        But I do not know why ?

        Valgrind can also give false alert ?

        Sorry, I cannot help you because I do not really understand what BuildTree does ...

         
    • Igor Pavlov
      Igor Pavlov
      2004-12-24

      > On Unix, the archiver GUI are often frond-end to console tools
      and the GUI launches something like that : " cmd > mess 2>error"
      If the command do not return 0, the GUI can display the error
      from the "error" file.

      Are you sure? Please check gzip output.

      Why do you need 16 MB SFX supporting(OpenArchive.cpp::kMaxCheckStartPosition) ?
      Big value of kMaxCheckStartPosition will slow down archive type detection.

       
      • my space
        my space
        2004-12-26

        > and the GUI launches something like that : " cmd > mess 2>error"
        > If the command do not return 0, the GUI can display the error
        > from the "error" file.
        > Are you sure? Please check gzip output.
        I am really surprised but you are right :
        - gzip and bzip2 always use stderr (messages and errors)
        - zip and unzip always use stdout (messages and errors)

        but for GUI Front-end, 2 streams is easier than 1 stream.

        > Why do you need 16 MB SFX supporting(OpenArchive.cpp::kMaxCheckStartPosition) ?
        16MB SFX is needed to be able to debug SFX archive.
        The sfx program with debug information is more than 1MB !
        1MB is not enough when the sfx program is statically linked.
        On Fedora 2, statically linked 7zCon.sfx is 1 156 056 bytes.
        > Big value of kMaxCheckStartPosition will slow down archive type detection.
        I know.
        Perharps, 2 or 4 MB for SFX will be the best value to support :
        - statically linked sfx
        - all kind of architectures (are you sure that on risc CPU,
        SFX will be less than 1MB ?)

         
        • Virgo Pärna
          Virgo Pärna
          2004-12-28

          > I am really surprised but you are right :
          > - gzip and bzip2 always use stderr (messages and  errors)
          > - zip and unzip always use stdout (messages and errors)

             It's probably because in gzip and bzip2 you  can send compression/decompression output to stdout (stream compression). In this case sending messages to stndout is big NO-NO:) Since zip does not allow stream compression, it can send it's output to stdout. What is a behaviour of -si and -so switches of 7z?