[Pvfs2-developers] -ansi with mpicc now

[Sam Lang]

On Sep 13, 2006, at 8:23 AM, Pete Wyckoff wrote:

> slang at mcs.anl.gov wrote on Wed, 13 Sep 2006 01:21 -0500:
>> I get the following error when building the test dir from trunk, and
>> with mpich2 from cvs (recent).  It looks like mpich2's mpicc adds -
>> ansi to the gcc compile line now (you can't see it in the below
>> output, but I verified that its there, and the error goes away if I
>> remove it).  Not sure why they added it, but its hard to argue that
>> our exported headers don't need to conform to ansi C.  The problem is
>> that there are a number of function definitions in pvfs2-util.h that
>> are inline static.  We do this I think because those functions are
>> used both by the kernel module and the user space pvfs2 code, so it
>> saves defining them twice in separate source files.  I see two
>> alternatives at this point:  we could make them macros (ew), or we
>> could move the function defs to source files in both user space code
>> and kernel module code and give up on not replicating them.  Any
>> other good ideas?  Once this is fixed, it looks like the -ansi causes
>> a plethora of other bugs to be expressed in our test code.  The two
>> big ones:  use of // instead of /* */.  And apparently -ansi has some
>> issues with bzero, snprintf, strdup, getopt...not sure what the deal
>> is there yet...
>
> There's only two functions that the kernel sees in pvfs2-util.h and
> they're both too big to be inlined anyway.  We don't have any
> shared user/kernel C files?

We don't appear to, no.

>   If so, they could go in there.  If not,
> why is the kernel even exposed to these functions in pvfs2-util.h?

It needs the PVFS2_translate_mode function at least (kernel/linux-2.6/ 
pvfs2-util.c calls it).  Even though we don't have any shared source  
files right now, I don't see any reason why we couldn't.  Could the  
makefile just list a relative path to a pvfs2-shared.c source file  
in ../../common/misc?

-sam

> Otherwise I vote for duplication as needed.
>
> You can always use __inline__ to get around the -ansi warning, but
> rather those functions would just go elsewhere.
>
> Always good to get rid of //, bzero.  The other missing functions
> probably just want the right headers included.
>
> You're right about all the other nitpicks, in my opinion.
>
> 		-- Pete
>