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

Groups > comp.lang.c > #15855

Re: Compile error

Show all headers | View raw

On 2012-01-16, Keith Thompson <kst-u@mib.org> wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>> On Sun, 2012-01-15, Keith Thompson wrote:
>>> dspfun <dspfun@hotmail.com> writes:
>>>> I get a compile/preprocessor error when trying to call/use the
>>>> following line:
>>>> openlog (__FUNCTION__, 0x02 | 0x01 | 0x08, (1<<3));
>>>>
>>>>
>>>> The openlog function is declared as:
>>>>
>>>> extern void openlog (__const char *__ident, int __option, int
>>>> __facility);
>>>
>>> Is "__const" a macro for "const"?  If so, why not just use "const"?
>>> If it's to cater to compilers that don't support "const", I hardly think
>>> that's necessary these days.
>>>
>>> Why are the parameter names reserved identifiers?  (The implementation
>>> is free to define "__ident" as a macro, which would break the
>>> declaration.)
>>
>> To be fair to Linux glibc (from where he must have copied the above),
>> the manual page uses the normal names.
>
> So, dspfun, where did the identifiers __ident et al come from?

Wow, this insipid buffoon is still going on about this, when it's been clear to
everyone that this declaration is from a system header that is making use of a
namespace reserved for implementors.

If the implementation of a standard header has a declaration like

  extern int fputc(int ch, FILE *stream); /* no underscores */

this creates a problem if a program does something like this:

  #define ch blah()
  #include <stdio.h>  /* now we have int fputc(int blah(), FILE *stream). */

This #define is allowed, because ch is not a keyword, and it is not an
identifier that is reserved with respect to this header file. It is the
header that is wrong by using unreserved identifiers in a way that is visible
to the program.

One solution is to not use names:

  extern int fputc(int, FILE *);

but maybe library implementors sometimes want names there, which can sometimes
be helpful.  Also, this issue occurs with struct and union member names, where
you can't omit the name:

  struct stat {
    dev_t st_dev; /* standard member; user cannot #define st_dev */

    /*...*/

    void *__padding[2]; /* for some kernel issue or whatever ... */
     
    /*...*/
  };

The library writer doesn't have to worry that user programs will
#define __padding ...  because that is equivalent to sticking a fork into a
toaster.

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

Thread

Compile error dspfun <dspfun@hotmail.com> - 2012-01-15 08:14 -0800
  Re: Compile error NEON China BLUE <chine.bleu@yahoo.com> - 2012-01-15 08:29 -0800
    Re: Compile error dspfun <dspfun@hotmail.com> - 2012-01-15 08:32 -0800
      Re: Compile error dspfun <dspfun@hotmail.com> - 2012-01-15 09:07 -0800
  Re: Compile error "BartC" <bc@freeuk.com> - 2012-01-15 17:13 +0000
  Re: Compile error Keith Thompson <kst-u@mib.org> - 2012-01-15 13:55 -0800
    Re: Compile error Ian Collins <ian-news@hotmail.com> - 2012-01-16 11:25 +1300
    Re: Compile error Kaz Kylheku <kaz@kylheku.com> - 2012-01-15 23:28 +0000
    Re: Compile error Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-01-16 12:37 +0000
      Re: Compile error Keith Thompson <kst-u@mib.org> - 2012-01-16 12:02 -0800
        Re: Compile error blp@cs.stanford.edu (Ben Pfaff) - 2012-01-16 13:23 -0800
          Re: Compile error Keith Thompson <kst-u@mib.org> - 2012-01-16 14:17 -0800
            Re: Compile error dspfun <dspfun@hotmail.com> - 2012-01-17 03:40 -0800
        Re: Compile error Kaz Kylheku <kaz@kylheku.com> - 2012-01-16 21:51 +0000

csiph-web