CalculiX build error using clang
Mark Brethen
mark.brethen at gmail.com
Tue Jul 26 20:24:09 UTC 2022
Thanks for the feedback everyone. I also created patches to replace sem_init and sem_destory instances and will be forwarding them to the developer. I didn’t see any warnings or errors but it wouldn’t hurt to give them another look.
Thanks,
Mark
> On Jul 26, 2022, at 3:12 PM, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>
>
>
>> On 26 Jul 2022, at 8:59 pm, Mark Brethen <mark.brethen at gmail.com> wrote:
>>
>>
>> Only 1 instance found:
>>
>> src $ sudo ack moveLineEndPoint
>> Password:
>> cgx.h
>> 941:void moveLineEndPoint(int lineNr, int pntNr, double llength);
>>
>> pickFunktions.c
>> 4583:void moveLineEndPoint(int lineNr, int pntNr, double llength)
>> 4800: moveLineEndPoint( lineNr, px, pickbuf);
>>
>>
>>
>> int createLine( char *apnt, int flag )
>> {
>> int i,j=0, nr=-1;
>> static int px, p1, p2, pc=-1, pm=-1, ps[1000], seq=1;
>> double P1[3], P2[3], Pc[3], Pm[3], pbuf[3], u;
>> char name[MAX_LINE_LENGTH], setname[MAX_LINE_LENGTH];
>> double pmp1[3], pmp2[3], pmp1_2[3], pmp2_2[3], nm12[3];
>> double eva[3], evb[3], va[3], vb[3], p0p1_2[3], p0p2_2[3], vr[3];
>> …
>> else if (flag==5)
>> {
>> if(lineNr==-1)
>> {
>> printf("ERROR: select line with key l first\n");
>> return(-1);
>> }
>> px = getPntNr( apnt );
>> moveLineEndPoint( lineNr, px, pickbuf);
>> for (i=0; i<anzGeo->l; i++) repLine(i);
>>
>> lineNr=-1;
>> }
>> return (nr);
>> }
>>
>> It looks like the return(-1) is needed?
>
> Nope, the opposite. That one call to the method ignores the return value. So the void signature is valid and the return statement should just omit the value. I.e.
>
> return;
>
> Chris
>
>>
>> Mark Brethen
>> mark.brethen at gmail.com <mailto:mark.brethen at gmail.com>
>>
>>
>>
>>> On Jul 26, 2022, at 2:18 PM, Chris Jones <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>>
>>>
>>>
>>>> On 26 Jul 2022, at 6:27 pm, Mark Brethen <mark.brethen at gmail.com <mailto:mark.brethen at gmail.com>> wrote:
>>>>
>>>> would a ‘return;’ instead of ‘return(-1);’ suffice>?
>>>
>>> Depends on what the intentions of the developers are here…
>>>
>>> If callees of the function expect a return value, then the method should instead be updated to declare a return type, and then to always return something (usually 0 for successful calls).
>>>
>>>>
>>>> Mark Brethen
>>>> mark.brethen at gmail.com <mailto:mark.brethen at gmail.com>
>>>>
>>>>
>>>>
>>>>> On Jul 26, 2022, at 11:51 AM, Christopher Jones <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>>>>
>>>>>
>>>>> clang is correct in this case, gcc is being sloppy.
>>>>>
>>>>> Basically you cannot return a value, from a function declared as void… fairly basic stuff really..
>>>>>
>>>>>> On 26 Jul 2022, at 5:34 pm, Mark Brethen <mark.brethen at gmail.com <mailto:mark.brethen at gmail.com>> wrote:
>>>>>>
>>>>>> I’m seeing this build error when using clang (gcc doesn’t complain):
>>>>>>
>>>>>> info:build /opt/local/bin/clang-mp-14 -O2 -Wall -Wno-narrowing -I./ -I/opt/local/include -I/opt/local/include/GL -I../../libSNL/src -I../../glut-3.5/src -c -o pickFunktions.o pickFunktions.c
>>>>>> :info:build pickFunktions.c:4599:7: error: void function 'moveLineEndPoint' should not return a value [-Wreturn-type]
>>>>>> :info:build return(-1);
>>>>>> :info:build ^ ~~~~
>>>>>>
>>>>>> code snippet below:
>>>>>>
>>>>>> void moveLineEndPoint(int lineNr, int pntNr, double llength)
>>>>>> {
>>>>>> int p1,p2, flag=0;
>>>>>> double P1[3], P2[3], u, eva[3], va[3], p0p1_2[3];
>>>>>>
>>>>>> p1=line[lineNr].p1;
>>>>>> p2=line[lineNr].p2;
>>>>>>
>>>>>> /* determine which side of the line has to be moved */
>>>>>> if(pntNr==p1) flag=-1;
>>>>>> else if(pntNr==p2) flag=1;
>>>>>> else
>>>>>> {
>>>>>> printf("ERROR: selected point:%s is no line endpoint\n", point[pntNr].name);
>>>>>> return(-1);
>>>>>> }
>>>>>> u=flag*llength;
>>>>>> u/=scale->w;
>>>>>>
>>>>>> /* calc direction */
>>>>>> if(line[lineNr].typ=='s')
>>>>>> {
>>>>>> if(flag==-1) p2=set[line[lineNr].trk].pnt[1];
>>>>>> else p1=set[line[lineNr].trk].pnt[set[line[lineNr].trk].anz_p-2];
>>>>>> }
>>>>>> P1[0]=point[p1].px;
>>>>>> P1[1]=point[p1].py;
>>>>>> P1[2]=point[p1].pz;
>>>>>> P2[0]=point[p2].px;
>>>>>> P2[1]=point[p2].py;
>>>>>> P2[2]=point[p2].pz;
>>>>>> v_result( P1, P2, p0p1_2);
>>>>>> v_norm(p0p1_2,eva);
>>>>>> v_scal(&u,eva, va);
>>>>>> point[pntNr].px+=va[0];
>>>>>> point[pntNr].py+=va[1];
>>>>>> point[pntNr].pz+=va[2];
>>>>>> printf("moved by dxyz= %lf %lf %lf\n",
>>>>>> (va[0]* scale->w),
>>>>>> (va[1]* scale->w),
>>>>>> (va[2]* scale->w));
>>>>>> }
>>>>>>
>>>>>> I do not code in C, so I’ll pass this up to the developer. How should this be patched?
>>>>>>
>>>>>> Thanks,
>>>>>> Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0004.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-cgx_2_18-src-cgx_c.diff
Type: application/octet-stream
Size: 1293 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0003.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0005.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-cgx_2_18-src-pickFunktions_c.diff
Type: application/octet-stream
Size: 1314 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0004.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0006.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-cgx_2_18-src-setFunktions_c.diff
Type: application/octet-stream
Size: 885 bytes
Desc: not available
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0005.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220726/79a7e4e2/attachment-0007.htm>
More information about the macports-dev
mailing list