Project

General

Profile

Actions
Copy link

Bug #2629

closed

Exclude: cannot decode ImplicitSha256DigestComponent

Added by Ilya Moiseenko over 9 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Ilya Moiseenko
Category:
Base
Target version:
v0.4
Start date:
03/09/2015
Due date:
% Done:

100%

Estimated time:
1.50 h

Description

Snippet to reproduce:

// g++ -std=c++0x x.cpp $(pkg-config --cflags --libs libndn-cxx)
#include <ndn-cxx/exclude.hpp>

using ndn::Exclude;
using ndn::Block;

int
main()
{
  uint8_t WIRE[] = {
    0x10, 0x22, // Exclude
          0x01, 0x20, // ImplicitSha256DigestComponent
                0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
                0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
                0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
                0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd
  };

  Block block(WIRE, sizeof(WIRE));

  Exclude exclude;
  exclude.wireDecode(block);

  return 0;
}

Expect: no error

Actual: Exclude::wireDecode throws ndn::Exclude::Error

Files

consumer-exclude.cpp (2.76 KB) consumer-exclude.cpp Ilya Moiseenko, 03/09/2015 05:22 PM
Actions
Copy link
 #1

Updated by Junxiao Shi over 9 years ago

  • Subject changed from Exclude with implicit digest to Exclude: cannot decode ImplicitSha256DigestComponent
  • Description updated (diff)
  • Category set to Base
  • Target version set to v0.4
  • Estimated time set to 1.50 h
Actions
Copy link
 #2

Updated by Ilya Moiseenko over 9 years ago

  • Assignee set to Ilya Moiseenko
Actions
Copy link
 #3

Updated by Ilya Moiseenko over 9 years ago

  • Status changed from New to Code review
  • % Done changed from 0 to 100
Actions
Copy link
 #4

Updated by Junxiao Shi over 9 years ago

The origin of this Bug is: a new name::Component type is introduced, but Exclude is hard-coded to recognize NameComponent type only.

The solution in commit:09392456c5213e0e1504b7f0c8165c3d5d014529 explicitly lists ImplicitSha256DigestComponent in Exclude element decode procedure.

This is a correct solution, but it cannot prevent same Bug to occur when another name::Component type is introduced (eg. #2012).

Suggested solution is:

  1. introduce bool isValidType(uint32_t type) predicate as a static method of name::Component class
  2. call this predicate in Exclude decode procedure, and other places where (a) testing for name::Component types is needed (b) logic does not differ by each type.
Actions
Copy link
 #5

Updated by Alex Afanasyev over 9 years ago

  • Status changed from Code review to Closed
Actions
Copy link

Also available in: Atom PDF