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

Groups > comp.lang.c > #15822 > unrolled thread

Compile error

Back to article view | Back to comp.lang.c

Contents

  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

#15822 — Compile error

Hi,

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);

The compiler error is:

------------------------------------------
 powerpc-linux-gnu-gcc -c
...snip...
 -Wno-write-strings  foo.c -o foo.o
foo.c:62: error: expected declaration specifiers or '...' before
'__FUNCTION__'
...snip...
gmake[1]: *** [foo.o] Error 1
Command exited with non-zero status 2
------------------------------------------

Does anyone have any idea what the problem is and how to resolve it?

Brs,
Markus

[toc] | [next] | [standalone]

#15823

In article <5976423f-f7d5-40e6-b8fa-7636c8a8d8b7@a17g2000yqj.googlegroups.com>,
 dspfun <dspfun@hotmail.com> wrote:

> Hi,
> 
> I get a compile/preprocessor error when trying to call/use the
> following line:
> openlog (__FUNCTION__, 0x02 | 0x01 | 0x08, (1<<3));

Did you mean __func__?

-- 
My name Indigo Montoya.      |                  Yippee-kay-yay, eh.
You flamed my father.        |       I'm whoever you want me to be.
Prepare to be spanked.       |  Annoying Usenet one post at a time.
Stop posting that!           |    At least I can stay in character.

[toc] | [prev] | [next] | [standalone]

#15824

On 15 Jan, 17:29, NEON China BLUE <chine.b...@yahoo.com> wrote:
> In article <5976423f-f7d5-40e6-b8fa-7636c8a8d...@a17g2000yqj.googlegroups.com>,
>
>  dspfun <dsp...@hotmail.com> wrote:
> > Hi,
>
> > I get a compile/preprocessor error when trying to call/use the
> > following line:
> > openlog (__FUNCTION__, 0x02 | 0x01 | 0x08, (1<<3));
>
> Did you mean __func__?
>

I tried with __func__ as well instead of __FUNCTION__ but the same
error.

Any ideas?

Brs,
Markus

[toc] | [prev] | [next] | [standalone]

#15825

On 15 Jan, 17:32, dspfun <dsp...@hotmail.com> wrote:
> On 15 Jan, 17:29, NEON China BLUE <chine.b...@yahoo.com> wrote:
>
> > In article <5976423f-f7d5-40e6-b8fa-7636c8a8d...@a17g2000yqj.googlegroups.com>,
>
> >  dspfun <dsp...@hotmail.com> wrote:
> > > Hi,
>
> > > I get a compile/preprocessor error when trying to call/use the
> > > following line:
> > > openlog (__FUNCTION__, 0x02 | 0x01 | 0x08, (1<<3));
>
> > Did you mean __func__?
>
> I tried with __func__ as well instead of __FUNCTION__ but the same
> error.
>
> Any ideas?
>
> Brs,
> Markus

Hi!

The problem is most likely related to that it's not possible to call
functions at file scope - they need to be inside another function.

The call to openlog() was actually embedded in a MACRO, which in turn
was embedded into another MACRO, so it was a bit confusing. The code I
put above had I  extracted from after the preprocessor had been run..

Thanks!

Markus

[toc] | [prev] | [next] | [standalone]

#15826

"dspfun" <dspfun@hotmail.com> wrote in message 
news:5976423f-f7d5-40e6-b8fa-7636c8a8d8b7@a17g2000yqj.googlegroups.com...
> Hi,
>
> 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);

> Does anyone have any idea what the problem is and how to resolve it?

What happens when __FUNCTION__ is replaced with NULL or 0? What happens when 
you change __const to const (or leave it out altogether)?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#15833

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.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15835

On 01/16/12 10:55 AM, 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.)

It looks like a bastardised version of the standard Unix function 
declaration:

void openlog(const char *ident, int logopt, int facility);

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#15836

On 2012-01-15, Keith Thompson <kst-u@mib.org> 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"?

Yes and no. GCC has such a keyword.

In the GNU C Library /usr/include/sys/cdefs.h we have this:

#ifdef __GNUC__

/* GCC can always grok prototypes.  For C++ programs we add throw()
   to help it optimize the function calls.  But this works only with
   gcc 2.8.x and egcs.  For gcc 3.2 and up we even mark C functions
   as non-throwing using a function attribute since programs can use
   the -fexceptions options for C code as well.  */
# if !defined __cplusplus && __GNUC_PREREQ (3, 3)
#  define __THROW	__attribute__ ((__nothrow__))
#  define __NTH(fct)	__attribute__ ((__nothrow__)) fct
# else
#  if defined __cplusplus && __GNUC_PREREQ (2,8)
#   define __THROW	throw ()
#   define __NTH(fct)	fct throw ()
#  else
#   define __THROW
#   define __NTH(fct)	fct
#  endif
# endif

#else	/* Not GCC.  */

# define __inline		/* No inline functions.  */

# define __THROW
# define __NTH(fct)	fct

# define __const	const
# define __signed	signed
# define __volatile	volatile

#endif	/* GCC.  */

> If it's to cater to compilers that don't support "const", I hardly think
> that's necessary these days.

It avoids unnecessary namespace pollution, I suppose. A program can use
const as a macro and it won't interfere with the GNU C Library headers.

*shrug*

Good questions for the glibc mailing list.

[toc] | [prev] | [next] | [standalone]

#15847

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.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#15852

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?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15854

Keith Thompson <kst-u@mib.org> writes:

> 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?

On a glibc system:

    blp@blp:~$ grep -r __ident /usr/include
    /usr/include/sys/syslog.h:extern void openlog (__const char *__ident, int __option, int __facility);
    blp@blp:~$ 
-- 
"I should killfile you where you stand, worthless human." --Kaz

[toc] | [prev] | [next] | [standalone]

#15857

blp@cs.stanford.edu (Ben Pfaff) writes:
> Keith Thompson <kst-u@mib.org> writes:
>> 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?
>
> On a glibc system:
>
>     blp@blp:~$ grep -r __ident /usr/include
>     /usr/include/sys/syslog.h:extern void openlog (__const char *__ident, int __option, int __facility);
>     blp@blp:~$ 

Ok, that makes some sense, given that /usr/include/sys/syslog.h is
part of the implementation.

The name of a parameter in a function declaration (as opposed to a
definition) is ignored; there's no way in C for a caller to refer
to a parameter by name.  The authors of syslog.h decided to use
reserved identifiers to avoid clashing with user-defined macros.
For example, if they had written:

    extern void openlog (__const char *ident, int option, int facility);

and a user wrote:

    #define ident 42
    #include <sys/syslog.h>

then the declaration would be a syntax error.

The lesson here is that system header files are intended for the
compiler, not necessarily for human readers (unless you have a
specific need to dive into the gory details); they can have all sorts
of implementation-defined cruft that's of no interest to most users.
The way to get the declaration for openlog() is to read the man page,
which says:

    #include <syslog.h>

    void openlog(const char *ident, int option, int facility);

As for __const, that's a gcc-specific "alternate keyword".
It probably goes back to the pre-ANSI days when some compilers didn't
support the "const" keyword.  It's equivalent (for gcc) to "const",
and there's no reason to use it or refer to it in your own code.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#15883

On 16 Jan, 23:17, Keith Thompson <ks...@mib.org> wrote:
> b...@cs.stanford.edu (Ben Pfaff) writes:
> > Keith Thompson <ks...@mib.org> writes:
> >> Jorgen Grahn <grahn+n...@snipabacken.se> writes:
> >>> On Sun, 2012-01-15, Keith Thompson wrote:
> >>>> dspfun <dsp...@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?
>
> > On a glibc system:
>
> >     blp@blp:~$ grep -r __ident /usr/include
> >     /usr/include/sys/syslog.h:extern void openlog (__const char *__ident, int __option, int __facility);
> >     blp@blp:~$
>
> Ok, that makes some sense, given that /usr/include/sys/syslog.h is
> part of the implementation.
>
> The name of a parameter in a function declaration (as opposed to a
> definition) is ignored; there's no way in C for a caller to refer
> to a parameter by name.  The authors of syslog.h decided to use
> reserved identifiers to avoid clashing with user-defined macros.
> For example, if they had written:
>
>     extern void openlog (__const char *ident, int option, int facility);
>
> and a user wrote:
>
>     #define ident 42
>     #include <sys/syslog.h>
>
> then the declaration would be a syntax error.
>
> The lesson here is that system header files are intended for the
> compiler, not necessarily for human readers (unless you have a
> specific need to dive into the gory details); they can have all sorts
> of implementation-defined cruft that's of no interest to most users.
> The way to get the declaration for openlog() is to read the man page,
> which says:
>
>     #include <syslog.h>
>
>     void openlog(const char *ident, int option, int facility);
>
> As for __const, that's a gcc-specific "alternate keyword".
> It probably goes back to the pre-ANSI days when some compilers didn't
> support the "const" keyword.  It's equivalent (for gcc) to "const",
> and there's no reason to use it or refer to it in your own code.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

Hi,

Thanks all for your help!

Here is more info regarding where the __const etc comes from in my
code:

My .c-file uses the macro TRACE_OBJ(GROUP,TRACE_OBJ,MSG) and this
macro is declared in the file

/usr/include/xxx_trace_obj.h

as

#define TRACE_OBJ(GROUP,TRACE_OBJ,MSG) LOG(LOG_INFO, STR("TRACE_OBJ:
%s", #TRACE_OBJ))

LOG_INFO is defined as
#define LOG_INFO 6

and STR is defined as
-------------------------
static char buf_s[1024];

static char* STR(const char *fmt, ...)
{
   va_list args;

   __builtin_va_start(args,fmt);
   (void)vsprintf(buf_s, fmt, args);
   __builtin_va_end(args);
   return (char*)buf_s;
}
-------------------------

The LOG macro is declared in the file

/usr/include/slog.h

as

#define LOG(level, msg) do {\
openlog (__FUNCTION__, LOG_CONS | LOG_PID | LOG_NDELAY, LOG_USER);\
syslog (level, "%s", msg);\
closelog ();\
} while(0)


slog.h above includes the file
/usr/include/syslog.h"

which only contains

#include <sys/syslog.h>

and sys/syslog.h contains the declaration of openlog

/* Open connection to system logger.
   This function is a possible cancellation point and therefore not
   marked with __THROW.  */
extern void openlog (__const char *__ident, int __option, int
__facility);

Brs,
Markus

[toc] | [prev] | [next] | [standalone]

#15855

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web