syntax error in source3/locking/brlock.c

[Stefan (metze) Metzmacher]

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. I decided
>>>>>>> to see what happens with Sun's C 5.11 SunOS_i386 compiler. It complains
>>>>>>> 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 = (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 = (struct byte_range_lock) { 0 };
>>>>>>
>>>>>> I think that strictly speaking C, does not allow omitting the 0, but C++
>>>>>> compatible compilers allow it. With -pedantic, gcc also warns about
>>>>>> 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 compiler,
>>> 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 error)
>> 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.
> 
> Here is a similar patch for 4.2 (replace all {} initializers with { 0 }
> and adjust the nesting level to avoid further warnings)
> 
> 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 = (type) { 0 };

Places in the declaration, e.g. type var = {}; seem to be fine
and I'd propose to lease them as is.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150309/dba63b70/attachment.pgp>