[tor-dev] circuitmux_ewma.c

[Nick Mathewson]

On Thu, Nov 1, 2012 at 1:04 PM, Gisle Vanem <gvanem at broadpark.no> wrote:

> These gcc extensions:
>

Hi, Gisle!

I'm happy to open another ticket for these, but have you tried using the
bugtracker yourself? Is there some UI issue or something that prevents you
from opening tickets?  If so I'd be glad to try to help work around it, but
if not it's really more convenient to have bugtracker tickets to discuss
this stuff.

As for the patch, I don't think it's a good idea as-is, for two reasons:
  * First, the syntax there is *NOT* a GCC extension; it's a standard C99
feature.
  * Second, the workaround is error-prone.  If the fields in the structure
are ever designated in an order that doesn't match their declaration order
in the structure definition, we'll get a situation where C99-compliant
compilers generate the code as intended, but where non-C99-compliant
compilers fail, or worse-- generate different code.  To be concrete,
consider this example:

#include <stdio.h>

struct X {
  const char *important;
  const char *actor;
  const char *victim;
};

#if I_HAVE_C99
  #define STRUCT_INIT(member,val) member = val
#else
  #define STRUCT_INIT(member,val) val
#endif

int main(int argc, char **argv)
{
  struct X y = {
    STRUCT_INIT(.actor, "vendors"),
    STRUCT_INIT(.victim, "programmers"),
    STRUCT_INIT(.important, "Standards")
  };
  printf("%s are important.\n"
    "When %s support them, that makes life easier for %s.\n",
         y.important, y.actor, y.victim);
  return 0;
}

So I think the better fix there is probably to verify that the designated
initializers are indeed given in the structure declaration order, and then
to simply replace them with comments.  It's not as good as it would be if
we could rely on having a C99 compiler (in 2012), but it's better that
risking our code behaving differently on C99 and non-C99 compilers.

yrs,
-- 
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121101/c4219305/attachment.html>