Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #105234

Re: Double-underline-itis

Show all headers | View raw

BartC <bc@freeuk.com> writes:

> On 01/03/2017 01:19, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> I came across this declaration in some Linux header:
>>>
>>>  extern int mbtowc (wchar_t *__restrict __pwc,
>>>           const char *__restrict __s, size_t __n) __THROW;
>>>
>>> There are thousands just the same. I can understand the
>>> double-underline prefix used for implementation names that may clash
>>> with those in the user namespace.
>>>
>>> But what's with the double-underline on the parameter names? They
>>> shouldn't clash with anything.
>>
>> That's why the underscores are there.  Without them, the names could
>> clash with user-defined macros.
>
> Yes, that's what supercat said. But then, macros can cause all sorts
> of mischief. Anyone producing a header file for a library, and wishing
> to use parameter names in function declarations, would also be at risk
> of having those names clashing with macros declared before the header.

I'm not sure what your point is.  You asked a question and I tried to
answer it (in fact I'd say I did answer it).  Are you saying that system
headers should not take this into account because some other header
might not bother?

> What can do they do?

They should either not use names in the header or document the names
used so annt one #defining one of them prior to including the header
will know what's gone wrong.

<snip>
>>> Sometimes, as well as the double-underline at the start, they need to
>>> have one at the end too, such as '__restrict__' (what's wrong with
>>> just 'restrict', if you need to have it all?).
>>
>> __restrict__ can be #defined away when processing the header with a
>> pre-1999 version of C.  You can't do that with restrict because it's not
>> a name reserved to the implementation.  Obviously one could use
>> different headers for different C versions, but this method is simple
>> and effective.
>
> You mean that
>
>    #define restrict
>
> won't work because someone could have....
>
> I don't even understand the problem. These are system headers,
> designed to work with a particular implementation, so will know
> whether 'restrict' is supported or not. What's the point of such a
> keyword being introduced if it then goes onto use something else?

Many implementations support various C standards.  As I said, you could
include a different header for C90, C99 and so on but it's easier to
#define __restrict__ to either nothing or restrict depending on the
language version.

<snip>
-- 
Ben.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Double-underline-itis BartC <bc@freeuk.com> - 2017-02-28 23:44 +0000
  Re: Double-underline-itis supercat@casperkitty.com - 2017-02-28 15:54 -0800
  Re: Double-underline-itis Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-01 01:19 +0000
    Re: Double-underline-itis David Brown <david.brown@hesbynett.no> - 2017-03-01 09:11 +0100
    Re: Double-underline-itis BartC <bc@freeuk.com> - 2017-03-01 11:45 +0000
      Re: Double-underline-itis Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-01 12:30 +0000
        Re: Double-underline-itis BartC <bc@freeuk.com> - 2017-03-01 13:04 +0000
          Re: Double-underline-itis Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-03-01 15:29 +0000
            Re: Double-underline-itis gazelle@shell.xmission.com (Kenny McCormack) - 2017-03-01 15:47 +0000
          Re: Double-underline-itis Keith Thompson <kst-u@mib.org> - 2017-03-01 09:30 -0800
            Re: Double-underline-itis supercat@casperkitty.com - 2017-03-01 10:14 -0800
            Re: Double-underline-itis Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 18:45 -0700

csiph-web