>>>>> On Mon, 23 Sep 2002 13:01:21 -0700, >>>>> Michael Hunter <[EMAIL PROTECTED]> said:
>> Sorry, but I don't think we should incorporate this to the >> specification. If an application writer assumes the existence of >> ip6r0_addr, the source code will not compile with a compiler that >> does not support the flexible array member. However, I don't want to >> see conditional compilation tricks like this: >> >> struct ip6_rthdr0 *r; >> struct in6_addr *in6; >> >> #if __STDC_VERSION__ >= 199901L >> in6 = &r->ip6r0_addr[0]; >> #else >> in6 = (struct in6_addr *)(r + 1); >> #endif > I don't like conditional compilation either. Its a maintenance > headache. That said I think if you don't choose a easy way to access > the variable length array of addresses you will end up with > implementers choosing their own direction thus leading to conditional > compilation anyways. I don't think just choosing implementors' own direction leads to conditional compilation, but perhaps the difference of these views is not main point in this discussion. (So let's go ahead) > 1) Leave it as you currently do (KAME does this). I suspect everybody > will choose their own way to make this usable. If you are lucky there > are not so many implementations that this isn't a problem. Presonally > I prefer conditional compilation based on the c standard rev over that > based on the OS/stack flavor. > 2) Use a pre c99 length 1 array (2292, Solaris, and USAGI do this). > Realistically this is most likely to be implemented uniformly. Its in > 2292 so you should need strong reason to change it. It is a little bit > gross, but I don't think this is strong enough reason to break existing > applications. > 3) Use a FAM. Use a 2+ year old c standard to specify an emerging > API. Philosphically this seems like the cleanest thing to do. > 4) Use a combination of 2 & 3. People can then use sizeof() as a way > to determine how to allocate. This is probably too complex to be used > correctly by the masses and has the maintenace headaches of conditional > compilation. > I hope you will consider 2 or 3. I didn't remember the reason why the member name was removed, so I found it from the web. You'll get the answer from the discussion starting at the following URL: http://www.wcug.wwu.edu/lists/ipng/199908/msg00128.html According to the discussion, there seemed to be a clear consensus on the removal (though this may not be regarded as a "strong reason"). Another thought: most user applications are expected to use inet6_rth_xxx functions, instead of directly getting access to the address part following the rthdr[0] structure. Thus, either 1 nor 2 affects the typical user applications. In some limited usage, such as in kernel source, developers may want to choose their own way for their convenience like ip6r0_addr[0]. However, we do not expect portability in such limited environments, and I don't care about the possible differences as long as it is hidden from user applications. Having thought all of this, I still prefer the current 2292bis definition. (I personally could live with (2), but I prefer (1) over (2) because we had a clear consensus on this.) Can we agree on this, or do we need more discussion? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
