vfs-wrap.c compile issues - was Re: Error #2 compiling Samba

[John E. Malmberg]

On Thu, 12 Jul 2001, Jim Duey wrote:

> In source/smbd/vfs-wrap.c, function vfswrap_ftruncate() are the 
> following lines:
[All but compiler diagnostics snipped for brevity] 
>     if(vfs_ops->lseek(fsp, currpos, SEEK_SET) != currpos) {
> 
> The compiler errors out on these calls with the following:
> 
> /home/jim/archive/samba-2.2.0a/source/smbd/vfs-wrap.c: In function 
> `vfswrap_ftruncate':
> /home/jim/archive/samba-2.2.0a/source/smbd/vfs-wrap.c:499: too few 
> arguments to function
> /home/jim/archive/samba-2.2.0a/source/smbd/vfs-wrap.c:508: warning: 
> passing arg 2 of pointer to function makes integer from pointer without 
> a cast
> 
> The prototypes for these calls are in source/include/vfs.h and are:
> 
>     ssize_t (*write)(struct files_struct *fsp, int fd, char *data, 
> size_t n);
>     SMB_OFF_T (*lseek)(struct files_struct *fsp, int filedes, SMB_OFF_T 
> offset, int whence);
> (snip)
>     int (*fstat)(struct files_struct *fsp, int fd, SMB_STRUCT_STAT *sbuf);
> 
> So is this a bug in vfs-wrap.c?

It all depends on what you call a bug.

I originally hit the same compiler diagnostics on Compaq C on OpenVMS,
and chased down the root cause for me.

I also mentioned this a few days back on another thread.

In my case, because my config.h is hand generated, I put some creative
macros to make the code compile, rather than patch the code.


What you have apparently is the function pointer members of the vfs
structure have the same names as the standard C library routines, but take
different arguments.

The next issue is that for whatever compiler and platform you are using
apparently has implemented those standard C libary routines as macros.

Those two things are not compatable.

(This is often done to allow binary backwards compatability when a change
 is done.

 EX 1: An architecture that formerly supported only 32 bits is extended to
 one that now supports 64 bits.  Macros are used to map the routines like
 lseek() to lseek64().  This keeps old binaries working, but new compiles
 will now be 64 bits instead of 32.

 EX 2: An architecture has an instruction that effectively does a library
 function like memset().  A macro is used to cause inline assembly of the
 code instead of the overhead of calling the routine.


The only way to avoid this problem generically is to treat the standard
C library names as reserved words, and avoid ever using them as variables,
structure names, or structure members.


Which brings up another issue.  For portability to non-UNIX platforms,
a programmer can not assume that external routine names are case
sensitive.  So changing the case of an externally visible symbol to
remove a conflict is also not a good idea.

In the case of SAMBA, that was done for Realloc().  But this later caused
a problem when a library that also contained a Realloc() was added.
So this problem is not just an OpenVMS issue.

If a prefix was used instead like smb_realloc(), or .vfs_lseek() this
conflict is avoided in all cases.



In my case, the conflicting macros are ones I wrote because of issues
where the native C system calls did not work as SAMBA expected them to.

You now have the choice of either finding why you have these conflicts and
seeing what you can do about them with your compiler and system
architecture, or trying to see if you can get a patch accepted.


The fix I would prefer to see is not to have any structure name or
structure member name be the same as a system routine.  This would require
slightly changing the names of all of the function pointer members of
the vfs structure, and all of the references to them.  This actually seems
to be restricted to vfs_wrapped.


-John
wb8tyw at qsl.network
Personal Opinion Only