Traffic Server
  1. Traffic Server
  2. TS-680

Make SDK opaque types use opaque struct's instead of void* ?

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.7
    • Component/s: TS API
    • Labels:
      None

      Description

      This could allow a compiler to warn on inappropriate parameters for example.

      The problem is that many API parameters are passed as (void*). This means that not only can they can unsafely interchanged (either passing the wrong parameter or passing them in the wrong order) but completely inappropriate (non-API) pointers can be passed as well, all without any warning from the compiler.

      This could be improved by declaring parameter types to be pointers to in name only types. This would make them non-trivially interchangeable with each other and non-API pointers. Although passing inappropriate parameters would still be possible it would be much harder to do by accident, in contrast to the current API in which it is very easy to do.

      1. prototypes.diff
        15 kB
        Leif Hedstrom

        Activity

        Hide
        Leif Hedstrom added a comment -

        Attached is an "example" of what it could take / look like if we did something simple like just an anonymous (opaque) struct pointer.

        Not being a C++ expert, the only way I could get it to compile was using reinterpret_cast (well, other than using C casts, and amc would kill me if I tried to use them).

        This is not a "patch" proposal, but to open up the discussion on some ideas around this.

        Show
        Leif Hedstrom added a comment - Attached is an "example" of what it could take / look like if we did something simple like just an anonymous (opaque) struct pointer. Not being a C++ expert, the only way I could get it to compile was using reinterpret_cast (well, other than using C casts, and amc would kill me if I tried to use them). This is not a "patch" proposal, but to open up the discussion on some ideas around this.
        Hide
        Alan M. Carroll added a comment -

        To pick a personal nit, non-member names starting with underscore are reserved for the implementation, so 'struct _tsmloc' is illegal. Unfortunately, because the API must be C compatible we can't use a namespace.

        Beyond being a lot of work for the TS team, it shouldn't have any negative impact on plugin developers as all of the API types affected are opaque. Overall it seems like a net positive.

        Show
        Alan M. Carroll added a comment - To pick a personal nit, non-member names starting with underscore are reserved for the implementation, so 'struct _tsmloc' is illegal. Unfortunately, because the API must be C compatible we can't use a namespace. Beyond being a lot of work for the TS team, it shouldn't have any negative impact on plugin developers as all of the API types affected are opaque. Overall it seems like a net positive.

          People

          • Assignee:
            Leif Hedstrom
            Reporter:
            Leif Hedstrom
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development