Results 1 to 3 of 3

Thread: Anyone interested in SAL annotations for their codec?

  1. #1
    Join Date
    Jul 2013
    United States
    Thanked 140 Times in 69 Posts

    Anyone interested in SAL annotations for their codec?

    TL;DR: if you have an open-source codec and are interested in me adding SAL annotations, let me know.

    Sorry, this is borderline off-topic, but I think (/ hope) people will be interested…

    Microsoft has something called Source-code Annotation Language, which is basically a set of annotations you add to an API to help their static analyzer figure out WTF the code is doing so they can do a better job of catching mistakes. It's not very commonly used (at least outside of Windows drivers), but I love the idea and it does catch bugs.

    One of the big problems with SAL, IMHO, has been that it doesn't work with other compilers. I don't just mean that the compiler doesn't know what they are and silently ignores them, but that the code simply doesn't build without a header which is only included on relatively recent versions of MSVC. A while back I put together a quick project (single header) called Salieri to make the annotations invisible to non-MSVC compilers so you can safely use them on portable projects, but I haven't really played with SAL since then… I'd like to change that.

    I figure if I'm going to add annotations to a project it may as well be one which is interested in integrating the changes into the official repo, so if that sounds like you please let me know. It would basically mean adding a single header file (salieri.h) to the project, and adding annotations to a bunch of functions. The SAL link above shows what those annotations look like (a bit ugly, yes, but IMHO well worth it). I'd also suggest an AppVeyor build with the /analyze flag.

    To be clear, SAL isn't only about catching bugs in the compression codec. If you export an API with SAL annototions, people using MSVC + /analyze may also be able to find errors in code which interacts with your API, so even if you have very well-tested and fuzzed code there is some benefit.

  2. #2
    Member jibz's Avatar
    Join Date
    Jan 2015
    Thanked 69 Times in 49 Posts
    Somewhat related, saw Puffs today, which is a DSL for writing safe data parsers that compiles down to C. One of their examples is a gif decoder.

  3. #3
    Member Alexander Rhatushnyak's Avatar
    Join Date
    Oct 2007
    Thanked 78 Times in 42 Posts
    Quote from Background of puffs' README:
    Parsing untrusted data, such as images downloaded from across the web, have a long history of security vulnerabilities. As of 2017, libpng is over 18 years old, and the PNG specification is dated 2003, but that well examined C library is still getting CVE's published in 2017.
    -- here CVE is Common Vulnerabilities and Exposures, a database of computer security vulnerabilities.

    Perhaps the following web service would be in demand:
    you send a small query with size, hash value and type of compressed file, i.e. zip/jpg/gif/png/etc, and you receive back yes, or no, or please upload.
    Yes would mean your file can be safely decompressed with standard tools,
    and no would mean it can't be safely decompressed with standard tools: it's either broken or maliciously crafted.

    This newsgroup is dedicated to image compression:

Similar Threads

  1. Replies: 2
    Last Post: 29th July 2014, 22:01
  2. For those interested in SPEED
    By gpnuma in forum Data Compression
    Replies: 0
    Last Post: 14th September 2013, 16:41
  3. plzma codec
    By Shelwien in forum Data Compression
    Replies: 30
    Last Post: 19th January 2013, 04:34
  4. Replies: 0
    Last Post: 30th August 2011, 16:47
  5. Interested in Google-Wave?
    By Vacon in forum The Off-Topic Lounge
    Replies: 2
    Last Post: 29th November 2009, 20:11

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts