For typical C99 I think you are unlikely to notice ABI problems. The function call interface should be unchanged.
That said compiler built ins can cause problems and we know of bugs with C99 variable length arrays so we don't use them in the kernel. Pretty much then only C99 additions we use are variable placement flexibility and local scoped variables in for loops. These are not a problem. Sent from my iPhone > On Oct 7, 2013, at 10:45 AM, Brian Behlendorf <[email protected]> wrote: > >> On 10/05/13 17:54, Matthew Ahrens wrote: >> On Sat, Oct 5, 2013 at 5:29 PM, Richard Yao <[email protected] >> <mailto:[email protected]>> wrote: >> >> Brian was concerned that there could be subtle compatibility issues >> between the C89 kernel and a C99 kernel module (or a C89 module and a >> C99 userland), so he decided to make the entire project C89 to be safe.. >> >> >> The ABI (application binary interface) should be the same for C89 and >> C99. I.e. code written in one can call the other. So I would not >> expect there to be any compatibility issues. Do you (Brian) know of any >> specific problems? > > It's my understanding that the C ISO standard doesn't make any claims about > ABI compatibility between C89 and C99. That's something which has been left > to the compiler. In my experience gcc does generate compatible code, but it > wouldn't at all surprise me if there are subtle incompatibilies lurking. > > To be absolutely safe I removed the C99'isms from the ZFS code when porting > it to Linux. I didn't want to risk it causing any subtle issues while > porting the rest of the code base. Doing so was pretty easy becuase it turns > out ZFS makes relatively light use of the C99 linguistic extensions. And for > a freestanding C environment like a kernel there really should be minimal > assumptions made about library support. > > While I personally like C99 better I'd argue that using C89 is more portable > and the required style changes are minimal. That said, I think we should > explore building ZFS as C99 on the Linux side before deciding anything. > Hopefully my worries are unfounded! > > And since we're on the topic of portabity I think there's a bigger issue we > need to address. One of the major frustions I've seen when porting changes > is when a patch brings in a dependency on some additional kernel subsystem.. > When that happens we're forced to either add that subsystems functionality to > our compatibility layer, which can be a lot of work, or rewrite the original > patch to use a different approach. Agreeing on a common kABI would make > sharing patches much easier. > > Thanks, > Brian > _______________________________________________ > developer mailing list > [email protected] > http://lists.open-zfs.org/mailman/listinfo/developer _______________________________________________ developer mailing list [email protected] http://lists.open-zfs.org/mailman/listinfo/developer
