Project

General

Profile

Bug #13626

Hashed field names can conflict

Added by Richard Neswold over 4 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Low
Category:
Parser
Target version:
Start date:
08/23/2016
Due date:
% Done:

0%

Estimated time:
Duration:

Description

The protocol compiler's marshaled data format uses 16-bit integers as tags rather than strings. These tags are used as identifiers for message fields, request/reply message names, struct names, enum names, and enum values. The hashed value is obtained by computing the MD5 hash of an entity-specific string and taking the lowest 16 bits of the result.

  • The string for field names is the name of the field appended with the version string.
  • The string for the name of a request or reply message is the name prepended with "req" or "rpy", respectively, and then appended with the version string.
  • The string for the name of a struct is the name prepended with "str" and then appended with the version string.
  • The string for the name of an enum is the name prepended with "enu" and then appended with the version string.
  • The string for an enumeration value is the enumeration name appended with the version string.

If the protocol file doesn't have a version directive, then no version string is used in the hash calculation.

As more identifiers are used, the chance of colliding hashes increases (this has happened in one instance!) The protocol compiler should check whether there's a conflict and deterministically generate an alternate hash. It should be noted that the identifiers don't have to be globally unique; if a field name's hash in one structure is the same as a field in a different structure, it's not considered a collision because the name of the struct/request/reply has already determined the set of valid fields.

History

#1 Updated by Richard Neswold over 3 years ago

  • Category set to Parser
  • Target version set to Protocol Compiler v1.1

#2 Updated by Richard Neswold over 3 years ago

  • Description updated (diff)
  • Status changed from New to Assigned
  • Assignee set to Richard Neswold

Updated description to include target implementation.

#3 Updated by Charles King over 3 years ago

  • Priority changed from Normal to Low

This is very low priority due to the fact that it's only happened once so far, and that was a protocol with an unusual number of fields in a single message.

#4 Updated by Richard Neswold over 3 years ago

Although it's rare, I don't like having a condition in which the protocol compiler generates code that won't compile. I'm still wanting this fix to get in release 1.1.

#5 Updated by Richard Neswold over 2 years ago

  • Status changed from Assigned to Closed

Fixed: 483ef060

When the compiler detects a hash has already been used, it uses a deterministic method of generating a new hash.

Also available in: Atom PDF