From owner-freebsd-questions@freebsd.org Sat Apr 18 13:31:26 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1BBED2C961C for ; Sat, 18 Apr 2020 13:31:26 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 494DPn0NwWz4FCq for ; Sat, 18 Apr 2020 13:31:24 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([94.222.27.149]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPA (Nemesis) id 1MKbc2-1jgNZl2iRY-00L21u; Sat, 18 Apr 2020 15:31:21 +0200 Date: Sat, 18 Apr 2020 15:31:21 +0200 From: Polytropon To: =?UTF-8?B?UGF3ZcWC?= Jasiak Cc: freebsd-questions@freebsd.org Subject: Re: Arguments format Message-Id: <20200418153121.c4419587.freebsd@edvax.de> In-Reply-To: <20200418120700.GA47913@gmail.com> References: <20200417160556.GA44862@gmail.com> <20200417184725.b49109b7.freebsd@edvax.de> <20200418120700.GA47913@gmail.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K1:2bfoSTFCalZL1tU4unNNXxpv7pPuyteDTQJAxnPxXM3upuSTNYe dDFBb8rwVrRxg93bDjBK8sLOAPPE1F+gecF1yySoKeIIwEsjWiIWIsT2mmN28Uh5cFMomaa 7Kw4p4obuik7/sbhyuM0et/ZTcM9og3CPmgLzRhUmB+T7iEORTFO8N2q+0uz+ZfEE5utjtU ZtEmcY7r5qGLqTzT9gfhA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:WtaW0reXmrU=:EMAY/QrSo+FdpEcwKu4ZY8 jBOQBgIyNoJt0Qfq9ngo+2by5SO96OVsQFTMMe0D29vgcRWvGJHmQrcLz1PJ1VU1cYleaj8j7 V3PJLhAzIihBRtwim9pFoufxpthXeQ+65I4aOn9GQWormpV8NumhSoiqGqo7WTDe8DMdVpKyA nl48hYRnkyVaPVbo1EW9Qnrfi7h/8xeKqTqEp/s2lzwF+chm5i/juGmxBwjOtxwv6dbUZZk/u oHe9cm9MOhmUU/Si+s/AU6E2rF/X+HTQhUbgSHsXavmFLQHC8kdiuhy0t36Q24cGoJ/k20vhu L6q7sbrguJG2HZqIxCLYzy7F5BCy+wMwXPwlfWhJmyowVT4KQIijvzju5H/mHz9i2PSCDSxcK jaQuX6IbyglKeUGdtVn9wtyQM+1rn7NpLMAcFnVtiAin0J8j5HsjhFctP6rasdjFpW/2gyYZV N9ugwkp8kfDpGg/igCWu8OOSsln4uFJlFkI8hIIG2X3W+e1CtfE3SpFN8825YhoaT5vx+Bceq An7OzcZ+5YYn+abFi82HKsPKCmc/Nn+O/TM69mkdhMQ9xHhvXzUDRRUBlrYo3QJxh0G5tOYFI 0jayslBdbv5iNBDXUG2d7l+McYyJLTLbnRrVoxah7/nS/F3Kx3w2n6G0U4SZowNwi/3bNlzkJ lHfncdpT/G1sS/+3U3ZV5p6ZBmmlu6iuy89TsfDpewHbIGrxiuH0yHnn+K+N/gzDGJTDsuJgC ucrAE2Rw2cO3cYLSViDClGINiOw5HMK1YX/OFdzwmXhM1pFEgDUEEx84wv5PM2Sj957c3Srus ca8DGJVSgu9JovKm89bXpgg+H09B+aRA+Xzw47asTrZ00PxRxmsY7j8hlyu4I8Kh/PS54mt X-Rspamd-Queue-Id: 494DPn0NwWz4FCq X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 217.72.192.75) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.60 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; HAS_ORG_HEADER(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:217.72.192.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[149.27.222.94.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.86)[0.864,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.997,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[75.192.72.217.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.34)[ip: (-0.65), ipnet: 217.72.192.0/20(0.26), asn: 8560(2.09), country: DE(-0.02)] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2020 13:31:26 -0000 On Sat, 18 Apr 2020 14:07:00 +0200, Paweł Jasiak wrote: > Thanks for your response! > > On 17/04/20, Polytropon wrote: > > On Fri, 17 Apr 2020 18:05:56 +0200, Paweł Jasiak wrote: > > > 1. In sys/mips/mips/autoconf.c we have functions > > > > > > static void configure_first(dummy) > > > static void configure(dummy) > > > static void configure_final(dummy) > > > > > > and we are not using argument. We are having those functions also in > > > ricv, arm, arm64, powerpc and x86 and in non of them we are using dummy, > > > so maybe we can just remove it? Or if it is necessary why we don't mark > > > it as __unused like in other functions? > > > > I haven't checked any further, but I could imagine that > > is has to do with the requirement of those functions > > being able - at least in their declaration - to accept > > a parameter; the type void * is a "somewhat universal" > > type. Note that the functions are being mentioned in > > macros, such as > > > > SYSINIT(configure1, SI_SUB_CONFIGURE, SI_ORDER_FIRST, configure_first, NULL); > > > > in /usr/src/sys/powerpc/powerpc/autoconf.c which might > > be the reason why there has to be a dummy parameter... > > > > Okay, further investigation. ;-) > > > > According to "man 9 SYSINIT", the definition is > > > > SYSINIT(uniquifier, enum sysinit_sub_id subsystem, > > enum sysinit_elem_order order, sysinit_cfunc_t func, > > const void *ident); > > > > and the type sysinit_cfunc_t is defined as > > > > typedef void (*sysinit_cfunc_t)(const void *); > > > > in /usr/src/sys/sys/kernel.h, so this is the reaon why > > the configure_first(), configure(), and configure_final() > > functions have to be "compatible". > > Thanks, I didn't really pay attention to SYSINIT but still don't > understand why we don't mark the arguments as __unused. If I remember correctly, __unused is an attribute primarily intended as a hint to the compiler that says "the variable probably will not be used", so the compiler won't issue the corresponding warning message. So __unused is optional here, what matters is that sysinit_cfunc_t in SYSINIT requires the argument list of (void *). However, if the dummy argument is not to be used, adding __unused would probably be a good idea. > > > 2. Above functions have strange definition for arguments. > > > > > > static void > > > configure(dummy) > > > void *dummy; > > > { > > > ... > > > } > > > > > > Why we are not using > > > > > > static void > > > configure(void *dummy) > > > { > > > ... > > > } > > > > > > like in other places? > > > > That is not a strange format, it's an older dialect of C, > > usually called "K&R C", where the definition of a function > > typically is: > > > > return-type function-name(arg1, arg2, arg3, ...) > > type arg1; > > type arg2; > > type arg3; > > ... > > { > > function-body > > } > > > > A convention also is to put the function's return type on > > an individual line, so the function's name always starts > > at column 1. > > > > See "man 9 style" for details. > > > > Still, this style is not being followed consistently: > > > > % grep "^configure_first" `find /usr/src/sys -name autoconf.c` > > /usr/src/sys/x86/x86/autoconf.c:configure_first(void *dummy) > > /usr/src/sys/arm64/arm64/autoconf.c:configure_first(void *dummy) > > /usr/src/sys/arm/arm/autoconf.c:configure_first(void *dummy) > > /usr/src/sys/riscv/riscv/autoconf.c:configure_first(void *dummy) > > /usr/src/sys/sparc64/sparc64/autoconf.c:configure_first(void *dummy) > > /usr/src/sys/powerpc/powerpc/autoconf.c:configure_first(void *dummy) > > /usr/src/sys/mips/mips/autoconf.c:configure_first(dummy) > > > > Some use "K&R C" style, others use "ANSI C" style. > > Thanks, I know both styles and I was worried about mixing them. Excellent. :-) The primary reason probably is the age of certain code. Not all code present in FreeBSD conforms to "man 9 style". > > > 3. In sys/mips/mips/octeon_cop2.c we are having > > > > > > struct octeon_cop2_state * > > > octeon_cop2_alloc_ctx() > > > { > > > ... > > > } > > > but it's declaration in sys/mips/include/octeon_cop2.h is > > > > > > struct octeon_cop2_state* octeon_cop2_alloc_ctx(void); > > > > > > Question is if we should change octeon_cop2_alloc_ctx() into > > > octeon_cop2_alloc_ctx(void)? > > > > There is a difference between () and (void) which _might_ be > > intended; however, prototype and declaration should in fact > > have the same signature. If the argument is (), the function > > will accept any parameters, including none ("any parameters > > list"); if it's (void), the function will refuse to accept > > any parameters ("emtpy parameter list"), which is explicit > > for "it doesn't use any parameters". > > I know the difference again ;) > > % grep -nr "octeon_cop2_alloc_ctx" > sys/mips/mips/vm_machdep.c:164: td2->td_md.md_cop2 = octeon_cop2_alloc_ctx(); > sys/mips/mips/vm_machdep.c:169: td2->td_md.md_ucop2 = octeon_cop2_alloc_ctx(); > sys/mips/mips/octeon_cop2.c:53:octeon_cop2_alloc_ctx() > sys/mips/mips/trap.c:942: td->td_md.md_cop2 = octeon_cop2_alloc_ctx(); > sys/mips/mips/trap.c:995: td->td_md.md_ucop2 = octeon_cop2_alloc_ctx(); > sys/mips/include/octeon_cop2.h:208:struct octeon_cop2_state* octeon_cop2_alloc_ctx(void); > > > I believe that all uses of the octeon_cop2_alloc_ctx function so I still > don't understand why we have different signatures. According to "man 9 style", argument names can be omitted in the header files, so declaration and definition might "look different", but are the same to the compiler and linker: int foo(int a, void *b, char c, struct blah d) { ... } int bar(void) { ... } The "simplified prototype" in the header file becomes: int foo(int, void *, char, struct blah); int bar(void); Only the types remain. That would be consistent; the example you provided is inconsistent; /usr/src/sys/mips/mips/octeon_cop2.c contains the definition as follows: struct octeon_cop2_state * octeon_cop2_alloc_ctx() { return uma_zalloc(ctxzone, M_NOWAIT); } The header file /usr/src/sys/mips/include/octeon_cop2.h defines: struct octeon_cop2_state* octeon_cop2_alloc_ctx(void); As I wrote about the meaning of () vs. (void), this might be an occassion to suggest that probably (void) should be used in both places. You could file a bug report for this. Also note that according to "man 9 style", the * belongs to the name: struct octeon_cop2_state *octeon_cop2_alloc_ctx(void); And similarly: struct octeon_cop2_state * octeon_cop2_alloc_ctx(void) { return uma_zalloc(ctxzone, M_NOWAIT); } I cannot imagine why two different signatures exist, but you could ask the developers if there _is_ a reason to do so. As I mentioned, it's not actually wrong, as () "anything" allows (void) "nothing", but still it should match. And the function is always called with _no_ arguments, so (void) should be the correct thing to choose here. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...