1. 28 Mar, 2017 1 commit
  2. 24 Jun, 2015 1 commit
  3. 23 Jul, 2014 1 commit
  4. 17 May, 2014 1 commit
  5. 02 May, 2014 1 commit
  6. 04 Apr, 2014 1 commit
  7. 31 Mar, 2014 1 commit
  8. 31 Jan, 2014 2 commits
    • Philip Withnall's avatar
      stun: Add a fast version of stun_message_validate_buffer_length() · e9ebf991
      Philip Withnall authored
      stun_message_validate_buffer_length() is already fast, but requires the
      entire message to be in a single monolithic buffer. For introducing
      vectored I/O, this becomes impossible to guarantee.
      
      Rather than rewriting the STUN code to natively support vectors of
      buffers (which would be a huge undertaking, and would probably slow
      the code down considerably), implement a fast check of whether a message
      is likely to be a STUN packet which *does* support vectored I/O. This
      can then be used to determine whether to compact the vector of buffers
      to a single monolithic one in order to validate the message more
      thoroughly.
      e9ebf991
    • Philip Withnall's avatar
      stun: Fix potential zero-length memset() call · 649d8861
      Philip Withnall authored
      GCC warns about this. Might as well prevent the warning.
      649d8861
  9. 18 Dec, 2013 4 commits
    • Philip Withnall's avatar
      stun: Fix a use of a function with an aggregate return value · 3e29fec4
      Philip Withnall authored
      div() has an aggregate return, which GCC doesn’t like, although this
      seems like a pretty pointless warning because div_t is the same size as
      a pointer on 64-bit platforms (probably) and hardly going to cause
      performance problems by passing it by value.
      
      Anyway, it seems easier to simplify the code by using explicit / and %
      operators inline, than it does to add pragmas and shut the warning up.
      3e29fec4
    • Philip Withnall's avatar
      stun: Explicitly avoid a memcpy() from NULL · 869093b3
      Philip Withnall authored
      If stun_message_append_bytes() is called through
      stun_message_append_flag(), data will be NULL and len will be 0. This
      will result in a memcpy(ptr, NULL, 0) call. This probably won’t do any
      harm (since any reasonable memcpy() implementation will immediately
      return if (len == 0)), but the standard allows for memcpy() to explode
      if (data == NULL), regardless of the value of len.
      
      In order to be conformant, and to shut up the scan-build static analysis
      warning about it, only do the memcpy() if (len > 0).
      869093b3
    • Philip Withnall's avatar
      Fix strict aliasing of sockaddr structures · 63e74d8e
      Philip Withnall authored
      Casting from one struct sockaddr type to another breaks C’s strict
      aliasing rules (variables of different types cannot alias). Fix this
      cleanly by using unions of struct sockaddrs to convert between the
      types (i.e. type-punning).
      
      I wish sockaddr didn’t have to be this painful.
      
      See:
      http://gcc.gnu.org/onlinedocs/gcc-4.4.1/gcc/Optimize-Options.html#Type_002dpunning
      63e74d8e
    • Philip Withnall's avatar
      Add missing ‘default’ cases to switches · 71fa5bb8
      Philip Withnall authored
      This shuts GCC’s -Wswitch-default warning, and makes the code flow a
      little more explicit.
      
      This introduces no functional changes.
      71fa5bb8
  10. 24 Mar, 2011 1 commit
  11. 15 Dec, 2010 2 commits
  12. 01 Oct, 2010 1 commit
  13. 18 Mar, 2010 1 commit
  14. 16 Feb, 2010 1 commit
  15. 17 Jun, 2009 1 commit
  16. 05 Mar, 2009 2 commits
  17. 23 Feb, 2009 1 commit
  18. 16 Feb, 2009 2 commits
  19. 31 Jan, 2009 1 commit
  20. 03 Nov, 2008 2 commits
  21. 28 Oct, 2008 4 commits
  22. 17 Sep, 2008 1 commit
    • Youness Alaoui's avatar
      This is a VERY UGLY HACK! · a74ceec9
      Youness Alaoui authored
      A google/msn data indication is 0x0115 which is contrary to the rfc3489bis which states that 8th and 12th bits are for the class and that 0x01 is for indications...
      So 0x0115 is reported as a "connect error response", while it should be a data indication, which message type should actually be 0x0017
      This should fix the issue, and it's considered safe since the "connect" method doesn't exist anymore
      a74ceec9
  23. 31 Jul, 2008 1 commit
  24. 17 Jun, 2008 1 commit
  25. 13 Jun, 2008 1 commit
  26. 06 Jun, 2008 1 commit
  27. 04 Jun, 2008 1 commit