From owner-freebsd-questions@freebsd.org Fri Apr 17 16:47:29 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 EB2B32C0B45 for ; Fri, 17 Apr 2020 16:47:29 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (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 493hpS67Pqz4G0G for ; Fri, 17 Apr 2020 16:47:28 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.12.118.76]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPA (Nemesis) id 1MowbA-1iu0Po0eCs-00qOk5; Fri, 17 Apr 2020 18:47:26 +0200 Date: Fri, 17 Apr 2020 18:47:25 +0200 From: Polytropon To: =?UTF-8?B?UGF3ZcWC?= Jasiak Cc: freebsd-questions@freebsd.org Subject: Re: Arguments format Message-Id: <20200417184725.b49109b7.freebsd@edvax.de> In-Reply-To: <20200417160556.GA44862@gmail.com> References: <20200417160556.GA44862@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:b+p0zRyrT/enhs3+wrAQz/6Td4mDO9T08gD7TdmOk8pHvSyljhc b/Y1IXNVhHoZIEl61k0VPB13qrTYP/BCl+nuO9lIzmY3HgnzGscGMQpt3M6zDVzqUpn7qDa sGNXqR3Bo589TIghiRtrl6vauTGP8QLBUUIzySqnVNjn8cNfBe6dsaMWQeDti1/jKQ3OrOj DT9NJMwitKOZeBxNR6nDQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:h9BpU0HCk70=:5yVtlEMEg+Vyt4edKocDVI YQBk43gE+PrIWwzmPw/Lycs3UP2GYrcrpIAmvRn9GZuCQ4ozc4PNeCvBOQOQ+s7frBwdpafYR J+kWGOo3GkjoMVHsYt7cf0Zfxq2YueKcFUZsQa06RP3wU0NKe4jIVtYSsu1dw5+2plojGXtvc tWD/aCpSsLhYdpCbGLigqJE428FT8M7/ZytavlC5ph9B79xc3S1pPNUuM16HN23YpNU8Y8rU2 IPynufhTriX653+cA3G9hukm8iy1XrLtfTZyny4gz4kNo+uIo0DgItpmaHiSMDxcFT/ohVkZw cVe4Ry5QcnXdDm8XXCJu9KlypVJCQnbLpfF+yApbLXVctz7gv0xRbNgYyTKv1mp+QjOR3dSbY 5xDxld6Gng8ZnlwLYl/5q2Vif2gUJtY7ikwf1zPWbojgjAFf1JHrPBbsdQkE9PALL3/8T3Yp4 7lvxba2Zkn/CNjslRLSL6H85nPNKY9tMF5N8uFkkds4nQw8HJrPVNMjCMBa/kzN9VgBn94yGJ b6oswfCPiGzz65sb9MdPgy4tYPlp48JROBaEc/yuIZiwEuz62poTetMpkWVPNLpOOExM5XbsO snOn4KCYIWphrNb1dduC+ismhCKd0j8Qyk0x7RIays3fy8fJyMMLFPHlSgKsUaKzOKmj57HtZ hvHtOu0uRk1nk4USPU1t4tWz3C0MLIApOfO04MB9igPvgXlBdTX74EujY5ZoICnotooLjwwi2 Z7EM3txVOPP+k2ELqRuOAGDKdr8OlR4IGZ6dWLLymYABZaKiEAV027sRHBHReDQ9JNW7s0K4i d1FwIIxz31mW3oHJO3ootqUL2aHFwkBuNp19hr1ejBWkgeEtDdbjBxvm556hWPedAH7NeUT X-Rspamd-Queue-Id: 493hpS67Pqz4G0G 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.74) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.41 / 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)[76.118.12.178.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.69)[0.694,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.996,0]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[74.192.72.217.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.32)[ip: (-0.75), 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: Fri, 17 Apr 2020 16:47:30 -0000 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". > 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. > 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". -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...