Where is the error in this code?

[Erwin Lindemann]

Hi group!

I found the following code in a free unix program and used it
successfully in a couple of programs. But for some reason it
does not compile under Windows.

Here's the code:

--------
#include <stdarg.h>
#include <stdio.h>

static int dbg_lvl = 0;

int dlevel(int lvl)
{
int prvlvl = dbg_lvl;
if(lvl < 0 || lvl > 7)
return -1;
dbg_lvl = lvl;
return prvlvl;
}

int dprintf(int lvl, const char *fmt, ...)
{
va_list ap;
int rv=0;
static char *s[] = {
"NONE", "INFO", "NOTICE", "WARNING",
"ERROR", "CRITICAL", "ALERT", "EMERG"
};

if(lvl <= dbg_lvl)
{
va_start(ap, fmt);
rv = fprintf(stderr, "%s: ", s[lvl]);
if(rv > 0) rv += vfprintf(stderr, fmt, ap);
va_end(ap);
}
return rv;
}

#define TEST

#ifdef TEST
int main(void)
{
int i;
dlevel(7);

for(i = 0; i <= 8; i++)
dprintf(i, "debug msg at level %d\n", i);

return 0;
}
#endif
--------

The error message from the Windows compiler is:

--------
Error dbg.c: 16 redefinition of 'dprintf'
Error c:\Programme\lcc\include\stdio.h: 133 Previous definition of 'dprintf' here
2 errors, 0 warnings
1 error
--------

I tried my best, but I can't find the problem.

Thanks,
Erwin Lindemann

 

[Walter Roberson]

I found the following code in a free unix program and used it
successfully in a couple of programs. But for some reason it
does not compile under Windows.

Here's the code:

#include <stdarg.h>
#include <stdio.h>
int dprintf(int lvl, const char *fmt, ...)
{ [...]

}

The error message from the Windows compiler is:

Error dbg.c: 16 redefinition of 'dprintf'
Error c:\Programme\lcc\include\stdio.h: 133 Previous definition of 'dprintf' here

I tried my best, but I can't find the problem.

Windows has a non-standard routine named dprintf() that it declares
in its stdio.h . (There is also a dprintf() that is in the GNU glibc2
library.)

You might have to use command line flags on your compile in order
to tell Windows that you only want standard functions and not
Windows extensions. In an ideal world, you would have to specifically
enable the extensions instead of having to specifically disable them,
but this does not appear to be an ideal world.

 

[Randy Howard]

Windows has a non-standard routine named dprintf() that it declares
in its stdio.h . (There is also a dprintf() that is in the GNU glibc2
library.)

So they are broken in much the same way lcc-win32 is, as seen in a
recent thread.

You might have to use command line flags on your compile in order
to tell Windows that you only want standard functions and not
Windows extensions. In an ideal world, you would have to specifically
enable the extensions instead of having to specifically disable them,
but this does not appear to be an ideal world.

Indeed.

 

[Flash Gordon]

Randy Howard wrote, On 22/01/08 23:41:

So they are broken in much the same way lcc-win32 is, as seen in a
recent thread.

On this Linux box dprintf is not present by default (i.e. gcc with
absolutely no options), you actually have to defind _GNU_SOURCE before
including stdio.h to enable it.

Indeed.

Agreed. gcc does not conform by default and I'm not aware of any other
compilers that conform by default.

 

[user923005]

Hi group!

I found the following code in a free unix program and used it
successfully in a couple of programs. But for some reason it
does not compile under Windows.

Here's the code:

--------
#include <stdarg.h>
#include <stdio.h>

static int dbg_lvl = 0;

int dlevel(int lvl)
{
  int prvlvl = dbg_lvl;
  if(lvl < 0 || lvl > 7)
    return -1;
  dbg_lvl = lvl;
  return prvlvl;

}

int dprintf(int lvl, const char *fmt, ...)
{
  va_list ap;
  int rv=0;
  static char *s[] = {
    "NONE", "INFO", "NOTICE", "WARNING",
    "ERROR", "CRITICAL", "ALERT", "EMERG"
  };

  if(lvl <= dbg_lvl)
  {
    va_start(ap, fmt);
    rv = fprintf(stderr, "%s: ", s[lvl]);
    if(rv > 0) rv += vfprintf(stderr, fmt, ap);
    va_end(ap);
  }
  return rv;

}

#define TEST

#ifdef TEST
int main(void)
{
  int i;
  dlevel(7);

  for(i = 0; i <= 8; i++)
    dprintf(i, "debug msg at level %d\n", i);

  return 0;}

#endif
--------

The error message from the Windows compiler is:

--------
Error dbg.c: 16  redefinition of 'dprintf'
Error c:\Programme\lcc\include\stdio.h: 133  Previous definition of 'dprintf' here
2 errors, 0 warnings
1 error

Call your routine Dprintf() instead of dprintf().

 

[Keith Thompson]

So they are broken in much the same way lcc-win32 is, as seen in a
recent thread.

Actually, I think the stdio.h file is provided by the compiler, not by
Windows. Note that the file name in the compiler's error message was
"c:\Programme\lcc\include\stdio.h".

The identifier "dprintf" is available for user code; if the
implementation interferes with this in conforming mode, that's a bug.
The OP should contact the compiler vendor.

 

[Richard Bos]

^^^

Call your routine Dprintf() instead of dprintf().

That's the wrong solution. The right solution is to use a conforming
implementation. This is the second such gaffe we've seen in a week.

Richard

 

[Keith Thompson]

That's the wrong solution. The right solution is to use a conforming
implementation. This is the second such gaffe we've seen in a week.

I agree that changing the name isn't a good solution, but it's a
reasonable short-term workaround. It's a lot easier than switching to
another compiler (which might have bugs of its own).

On the other hand, if you were thinking of switching compilers anyway,
this could be one more reason to do so.

 

[user923005]

I agree that changing the name isn't a good solution, but it's a
reasonable short-term workaround.  It's a lot easier than switching to
another compiler (which might have bugs of its own).

On the other hand, if you were thinking of switching compilers anyway,
this could be one more reason to do so.

Also, if the compiler is invoked in conforming mode and acts in a non-
conforming manner, issue a defect report to the compiler vendor with
enough information to reproduce the problem. Generally speaking, this
is a good way to increase the quality of software tools of any sort.

 

[Fumeur]

I found the following code in a free unix program and used it
successfully in a couple of programs. But for some reason it
does not compile under Windows.

Here's the code:

#include <stdarg.h>
#include <stdio.h>
int dprintf(int lvl, const char *fmt, ...)
{ [...]

}

The error message from the Windows compiler is:

Error dbg.c: 16 redefinition of 'dprintf'
Error c:\Programme\lcc\include\stdio.h: 133 Previous definition of
'dprintf' here

I tried my best, but I can't find the problem.

Windows has a non-standard routine named dprintf() that it declares
in its stdio.h .

Are you sure about that? I checked MSVC6 and Borland Builder 3 (they're
both rather old, but then I didn't do any MS Windows projects since
that time frame...)

Borland does not have any dprintf() at all.

Microsoft has a static dprintf() (including the whole function body)
in "dprintf.h", but not "stdio.h".

Did this change in later versions?

You might have to use command line flags on your compile in order
to tell Windows that you only want standard functions and not
Windows extensions. In an ideal world, you would have to specifically
enable the extensions instead of having to specifically disable them,
but this does not appear to be an ideal world.

The right way would be to guard those declarations by a preprocessor
symbol that is only defined in pure standards mode, right?
(lcc-win32 apparently has "__ANSIC__ONLY__" defined if "-ansic" is
specified on its command line).

It currently guards getline(), getdelim(), fggets(), ggets(ln),
fgetstr(), fgetstralloc(), _filbuf(), flsbuf(), asprintf(),
vasprintf(), _fsopen(), _fcloseall(), fdopen(), fileno(),
_fileno(), _flushall(), _pclose(), pclose(), popen(),
_putw(), _vsnprintf(), _vsnwprintf(), xvsnprintf(), xvsnprintf(),
xvsprintf(), _unlink(), _snprintf(), _tempnam(), _rmtmp(),
and unlink() inside a "#ifndef __ANSIC__ONLY__" in its "stdio.h",
but unfortunately not dprintf(), so I'm afraid invoking the
compiler in standard mode (via "-ansic") does not help with
dprintf().

It also seems to declare all of Microsoft's "safe" functions
unconditionally (those should only be made available if
"__STDC_WANT_LIB_EXT1__" is defined as 1 or greater, either by
means of a command line switch or other compiler magic, right?)