Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Ian Collins <ian-news@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Octal
Date: Mon, 2 Jan 2017 13:09:43 +1300
Lines: 41
Message-ID: <ectk27Fq0soU4@mid.individual.net>
References: <o3tsi4$es8$1@dont-email.me> <o3u96r$t9f$1@dont-email.me> <lnmvfh6s9t.fsf@kst-u.example.com> <o3uqga$1g2$1@dont-email.me> <o43tve$cuv$1@dont-email.me> <o45f38$qo6$1@dont-email.me> <o45ltq$h8n$1@dont-email.me> <o45p7b$soo$1@dont-email.me> <o45vv9$mtk$1@dont-email.me> <o4b5fm$ul5$1@dont-email.me> <ect3siFq0soU1@mid.individual.net> <clang-20170101205038@ram.dialup.fu-berlin.de> <ect5i5Fq0soU2@mid.individual.net> <tidy-20170101211124@ram.dialup.fu-berlin.de> <ect7ltFq0soU3@mid.individual.net> <3500f98c-6317-47bb-b703-c1530496ba93@googlegroups.com> <5b5861c2-94b6-43af-872d-7135c9d57204@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net r720SmR8uV59rPfgXiDpZQH4DmlEUphdJ3dsjKTWMG1i3OTrhx
Cancel-Lock: sha1:AKJ608fZRHmntfFdfl3PmIOg6o8=
User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
In-Reply-To: <5b5861c2-94b6-43af-872d-7135c9d57204@googlegroups.com>
Xref: csiph.com comp.lang.c:100836

On 01/ 2/17 12:51 PM, supercat@casperkitty.com wrote:
> On Sunday, January 1, 2017 at 3:59:37 PM UTC-6, Malcolm McLean wrote:
>> On Sunday, January 1, 2017 at 8:38:37 PM UTC, Ian Collins wrote:
>>> "Parameter names may be omitted only if the parameter is unused and its
>>> purpose is obvious."
>>>
>> Kind of an oxymoron. If a parameter is used, its purpose can often
>> be obvious. But if it is unused, there must always be the question
>> why it was included.
>
> The reason for inclusion in the called function is generally obvious:
> callers are going to pass the argument, so the called functions need
> to receive it.  On the other hand, without knowing what the parameter
> is supposed to represent, it's hard to know whether one should be
> using it.
>
> Perhaps the nicest way to handle such things would be to allow functions
> to specify distinct parameter and argument types, with the compiler
> coercing values as necessary.  A lot of memory-management code ends up
> looking like:
>
>      void *do_something(void *p1, void *p2, ...whatever...)
>      {
>        unsigned char *pp1 = p1;
>        unsigned char *pp2 = p1;
>        ... code uses pp1 and pp2 from here on out instead of p1 and p2
>      }
>
> Even if a compiler can optimize out the redundant variables, the
> declarations and initializations add complexity to the code, making it
> unclear whether intention is to copy the passed-in pointers or merely
> be able to use them as type "unsigned char*".  A syntax to allow a
> programmer to specify caller-side and called-function-side types of
> arguments and parameters would resolve that problem as well as the
> unused-argument issue (simply allow unused arguments to be declared
> as having a called-function-side type of "void").

In what way is that a better solution to allowing unnamed parameters?

-- 
Ian