Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.lang.c Subject: Re: Octal Date: Mon, 2 Jan 2017 14:24:15 +1300 Lines: 27 Message-ID: References: <3500f98c-6317-47bb-b703-c1530496ba93@googlegroups.com> <5b5861c2-94b6-43af-872d-7135c9d57204@googlegroups.com> <7a6aab4b-acc4-4c08-88ae-dbdbecd79f4f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net kH2Rat2RGeqRkpbODysz4wWh+IYxxjbgGQZIg8uR8+XJ7D9EC/ Cancel-Lock: sha1:W6lIY+qOdJTNrmRgKExq67N1ys4= User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <7a6aab4b-acc4-4c08-88ae-dbdbecd79f4f@googlegroups.com> Xref: csiph.com comp.lang.c:100847 On 01/ 2/17 01:50 PM, supercat@casperkitty.com wrote: > On Sunday, January 1, 2017 at 6:09:52 PM UTC-6, Ian Collins wrote: Keeping some of the context would be nice. >> In what way is that a better solution to allowing unnamed parameters? > > As noted, it would allow for the situation where a function needs to > receive pointers to arbitrary objects but process those objects as a > sequence of bytes (a situation unnamed parameters wouldn't help at all). Which wasn't the issue being discussed. > Further, function headers often serve as a form of documentation; if > a string-display function which is designed for a black and white console > ignores a couple parameters "int fgColor:void" and "int bgColor:void) [I > really don't know what syntax would be best], someone reading the code > might be able to recognize that it shouldn't be expected to use those > parameters. If instead it just ignored a couple of parameters of type > "int", someone examining the code might have no idea whether they > represented something the code should be using. If the parameters aren't named, it's pretty clear that they aren't intended to be used! -- Ian