syntax error in source3/locking/brlock.c

[Thomas Schulz]

> Am 09.03.2015 um 04:22 schrieb Christof Schmitt:
>> On Sat, Mar 07, 2015 at 02:18:11PM -0500, Thomas Schulz wrote:
>>>> On Fri, Mar 06, 2015 at 01:54:38PM -0700, Christof Schmitt wrote:
>>>>> On Fri, Mar 06, 2015 at 09:41:19PM +0100, Volker Lendecke wrote:
>>>>>> On Fri, Mar 06, 2015 at 01:35:31PM -0700, Christof Schmitt wrote:
>>>>>>> On Fri, Mar 06, 2015 at 01:26:43PM -0500, Thomas Schulz wrote:
>>>>>>>> I have been building 4.2.0 on Solaris 10 using the GNU C compiler=
> =2E I decided
>>>>>>>> to see what happens with Sun's C 5.11 SunOS_i386 compiler. It com=
> plains
>>>>>>>> with the following error:
>>>>>>>>
>>>>>>>> "../source3/locking/brlock.c", line 2008: syntax error before or =
> at: }
>>>>>>>> cc: acomp failed for ../source3/locking/brlock.c
>>>>>>>>
>>>>>>>> The offending line is:
>>>>>>>>
>>>>>>>>         *br_lck =3D (struct byte_range_lock) {};
>>>>>>>>
>>>>>>>> The GNU C compiler thinks that this line is OK. Does anyone have =
> an
>>>>>>>> idea what is intended here and why the Sun compiler does not like=
>  it?
>>>>>>>
>>>>>>> Try changing this to:
>>>>>>> 	*br_lck =3D (struct byte_range_lock) { 0 };
>>>>>>>
>>>>>>> I think that strictly speaking C, does not allow omitting the 0, b=
> ut C++
>>>>>>> compatible compilers allow it. With -pedantic, gcc also warns abou=
> t
>>>>>>> this:  warning: ISO C forbids empty initializer braces
>>>>>>
>>>>>> Yep.
>>>>>>
>>>>>> $ git grep '{}'|grep c:|wc -l
>>>>>> 153
>>>>>>
>>>>>> That would be a 153-line patch I guess. Or you can gain 153
>>>>>> ohloh-points with single patches :-)
>>>>>
>>>>> It might be even less than 153 patches, there also some empty code
>>>>> blocks in there. Let me try to put a patch together, having single
>>>>> patches would be too much overhead.
>>>>
>>>> The diffstat now shows 124 lines, see attached patch. Would be it
>>>> possible to compile test master with this patch with the SunOS compil=
> er,
>>>> to see whether there are other issues remaining?
>>>>
>>>> Christof
>>>
>>> Applying the patch to 4.2.0rc5 (the release is killing me with the
>>> requirements for gnutls and gcrypt), the following files were patched:=
> 
>>>
>>> lib/ldb/common/ldb_msg.c
>>> source3/locking/brlock.c
>>> source3/modules/non_posix_acls.c
>>> source3/passdb/pdb_get_set.c
>>> source3/smbd/dir.c
>>> source3/smbd/notify_internal.c
>>> source4/lib/wmi/tools/wmic.c
>>> source4/lib/wmi/tools/wmis.c
>>> source4/libcli/wbclient/wbclient.c
>>> source4/torture/raw/acls.c
>>> source4/torture/raw/unlink.c
>>> source4/torture/smb2/create.c
>>> source4/torture/smb2/dir.c
>>> source4/torture/smb2/lease.c
>>> source4/torture/smb2/util.c
>>>
>>> The following were not patched:
>>>
>>> auth/gensec/schannel.c
>>> libcli/auth/netlogon_creds_cli.c
>>> source3/lib/messages_dgm.c
>>> source3/lib/srprs.c
>>> source3/passdb/pdb_samba_dsdb.c
>>> source3/profile/profile.c
>>> source3/utils/status_profile.c
>>> source4/kdc/db-glue.c
>>> source4/torture/rpc/schannel.c
>>>
>>> All of the patched files were compiled except for:
>>>
>>> source4/lib/wmi/tools/wmic.c
>>> source4/lib/wmi/tools/wmis.c
>>>
>>> which were skipped.
>>>
>>> In each case the umpatched file (except brlock.c which had a fatal err=
> or)
>>> created the warning
>>> 'warning: syntax error:  empty initializer'
>>> and the patched file compiled without that warning.
>>>
>>> Of the files that could not be patched, only
>>>
>>> source3/lib/messages_dgm.c
>>>
>>> generated that warning.
>>>
>>> I could try to get the master and build that, but I will have to get
>>> newer versions of at least gnutls and gcrypt before I can go past 4.2.=
> 0rc5.
>>=20
>> Here is a similar patch for 4.2 (replace all {} initializers with { 0 }=
> 
>> and adjust the nesting level to avoid further warnings)
>>=20
>> It seems like the SunOS compiler only fails this particiluar instance,
>> so the question is whether we want to only fix the failure, or also fix=
> 
>> the other warnings at the same time.
> 
> I'd only try to fix the instances which cause problems.
> 
> It seems to be that we only need to fix places where we try to intialize
> a variable within the function, where we have var =3D (type) { 0 };
> 
> Places in the declaration, e.g. type var =3D {}; seem to be fine
> and I'd propose to lease them as is.
> 
> metze

It looks like we are only going the fix the one file with the fatal error,
but I just tried the smaller patch. It applied cleanly and the result
builds correctly. I do wonder about lines such as:

+       struct torture_lease_break break_info_tmp = { { { { { 0 } } } } };

I am affraid that we are in danger of using up the world's supply of
braces. :-)

Tom Schulz
Applied Dynamics Intl.
schulz at adi.com