Digital Mars - c++ - ANSI compiling issue

↑ ↓ ← → Laurentiu Pancescu <plaur crosswinds.net> writes:

Hi!

I'm having trouble compiling in ANSI mode (sc -A).  The
problems arise when including the standard header file "stdlib.h":
there are several functions which use "long long" and/or
"wchar_t".  Use example below (hello.c - C file, but we also get errors
in C++ mode):

#include <stdio.h>
#include <stdlib.h> /* we'll get errors here */

int main(void)
{
  printf("Hello, world!\n");
  exit(EXIT_SUCCESS);
}

Using -Aw solves the problems with wchar_t, but not the ones
with long long.  Anyway, the header files should ifdef out such
definitions in ANSI mode, because it prevents compiling
perfectly legal ANSI code, be it C or C++.  I don't think that a
compiler should choke at its own headers...

I'm using the 8.1c patch for the CD.  BTW, in the change log
for 8.18 it's written: "long longs no longer turned off by -A" -
then, why am I getting these errors?


Laurentiu Pancescu

Aug 19 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

You're right, that's a bug and I'll get it fixed. -Walter

Laurentiu Pancescu wrote in message <9lp5t9$2f34$1 digitaldaemon.com>...
Hi!

I'm having trouble compiling in ANSI mode (sc -A).  The
problems arise when including the standard header file "stdlib.h":
there are several functions which use "long long" and/or
"wchar_t".  Use example below (hello.c - C file, but we also get errors
in C++ mode):

#include <stdio.h>
#include <stdlib.h> /* we'll get errors here */

int main(void)
{
  printf("Hello, world!\n");
  exit(EXIT_SUCCESS);
}

Using -Aw solves the problems with wchar_t, but not the ones
with long long.  Anyway, the header files should ifdef out such
definitions in ANSI mode, because it prevents compiling
perfectly legal ANSI code, be it C or C++.  I don't think that a
compiler should choke at its own headers...

I'm using the 8.1c patch for the CD.  BTW, in the change log
for 8.18 it's written: "long longs no longer turned off by -A" -
then, why am I getting these errors?


Laurentiu Pancescu

Aug 20 2001

↑ ↓ ← → Laurentiu Pancescu <plaur crosswinds.net> writes:

Great to hear this - Walter, you're very responsive, as always!
 When do you think the changes will be available for download?
 Sorry for reporting bugs <g> - DM is great, I really love
it!!!  Perhaps we could help spreading it by contributing with
makefiles to various projects: I don't see why V or FLTK, for
instance, can have project files for the commercial Borland or
Microsoft compilers, and not also for DigitalMars, which is also
available as a free download - it's really a pity!

I got into this ANSI problem while trying to compile NASM 0.98
with DM, and since NASM wants to be compiled in ANSI-C mode
with any compiler, I tried!!  BTW, NASM compiles without any
problems with a slightly modified version of Makefile.scw (CFLAGS=-c
-Jm -a1 -mn -o -w2 -w7 -6).  I had to use "relaxed type
checking", because otherwise DM gives errors in nasmlib.c, because
failing to convert pointers from type "void (*)(void)" to various
pointers to void-returning functions, but with various
arguments.  I also think this is wrong (I don't know if it also
happens with -A, since DM doesn't pass its own stdlib.h):
- the definition "void null_debug_routine() {}" is NOT the same
with "void null_debug_routine(void){}", in ANSI-C, because
lack of arguments means no info about the arguments, and not
"void" as argument list (this is only true in C++)
- pointer conversion is allowed in C without explicit cast: the
compiler might generate warnings in this case, but not errors.

This is, of course, in the light of my current C/C++ knowledge.
 I also compiled NASM 0.98 with gcc, lccwin32 and Borland C++
5.5.1, without any problems, in ANSI mode (not even "-Wall
-ansi -pedantic" doesn't complain at these conversions if compiling
with gcc-2.95.3).  So, I guess I can't be too wrong, but I
would be especially interested in Walter's or Jan's opinions about this.

How can I detect if my code compiles in ANSI-C++ mode, using
#ifdef?  According to spec, in ANSI-C mode, __STDC__ is defined,
and, when compiling C++, __cplusplus will be defined, and
__STDC__ not (this is implementation dependent: __STDC__ may, or may
not be defined, but it's not by most compilers).  How is this in DM?


Laurentiu Pancescu

"Walter" <walter digitalmars.com> wrote:

You're right, that's a bug and I'll get it fixed. -Walter

Laurentiu Pancescu wrote in message <9lp5t9$2f34$1 digitaldaemon.com>...
Hi!

I'm having trouble compiling in ANSI mode (sc -A).  The
problems arise when including the standard header file "stdlib.h":
there are several functions which use "long long" and/or
"wchar_t".  Use example below (hello.c - C file, but we also get errors
in C++ mode):

#include <stdio.h>
#include <stdlib.h> /* we'll get errors here */

int main(void)
{
  printf("Hello, world!\n");
  exit(EXIT_SUCCESS);
}

Using -Aw solves the problems with wchar_t, but not the ones
with long long.  Anyway, the header files should ifdef out such
definitions in ANSI mode, because it prevents compiling
perfectly legal ANSI code, be it C or C++.  I don't think that a
compiler should choke at its own headers...

I'm using the 8.1c patch for the CD.  BTW, in the change log
for 8.18 it's written: "long longs no longer turned off by -A" -
then, why am I getting these errors?


Laurentiu Pancescu

Aug 29 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

I've attached a fixed stdlib.h. Try it with that one. -Walter


Laurentiu Pancescu wrote in message <9mjfb8$4ua$1 digitaldaemon.com>...
Great to hear this - Walter, you're very responsive, as always!
 When do you think the changes will be available for download?
 Sorry for reporting bugs <g> - DM is great, I really love
it!!!  Perhaps we could help spreading it by contributing with
makefiles to various projects: I don't see why V or FLTK, for
instance, can have project files for the commercial Borland or
Microsoft compilers, and not also for DigitalMars, which is also
available as a free download - it's really a pity!

I got into this ANSI problem while trying to compile NASM 0.98
with DM, and since NASM wants to be compiled in ANSI-C mode
with any compiler, I tried!!  BTW, NASM compiles without any
problems with a slightly modified version of Makefile.scw (CFLAGS=-c
-Jm -a1 -mn -o -w2 -w7 -6).  I had to use "relaxed type
checking", because otherwise DM gives errors in nasmlib.c, because
failing to convert pointers from type "void (*)(void)" to various
pointers to void-returning functions, but with various
arguments.  I also think this is wrong (I don't know if it also
happens with -A, since DM doesn't pass its own stdlib.h):
- the definition "void null_debug_routine() {}" is NOT the same
with "void null_debug_routine(void){}", in ANSI-C, because
lack of arguments means no info about the arguments, and not
"void" as argument list (this is only true in C++)
- pointer conversion is allowed in C without explicit cast: the
compiler might generate warnings in this case, but not errors.

This is, of course, in the light of my current C/C++ knowledge.
 I also compiled NASM 0.98 with gcc, lccwin32 and Borland C++
5.5.1, without any problems, in ANSI mode (not even "-Wall
-ansi -pedantic" doesn't complain at these conversions if compiling
with gcc-2.95.3).  So, I guess I can't be too wrong, but I
would be especially interested in Walter's or Jan's opinions about this.

How can I detect if my code compiles in ANSI-C++ mode, using
#ifdef?  According to spec, in ANSI-C mode, __STDC__ is defined,
and, when compiling C++, __cplusplus will be defined, and
__STDC__ not (this is implementation dependent: __STDC__ may, or may
not be defined, but it's not by most compilers).  How is this in DM?


Laurentiu Pancescu

"Walter" <walter digitalmars.com> wrote:

You're right, that's a bug and I'll get it fixed. -Walter

Laurentiu Pancescu wrote in message <9lp5t9$2f34$1 digitaldaemon.com>...
Hi!

I'm having trouble compiling in ANSI mode (sc -A).  The
problems arise when including the standard header file "stdlib.h":
there are several functions which use "long long" and/or
"wchar_t".  Use example below (hello.c - C file, but we also get errors
in C++ mode):

#include <stdio.h>
#include <stdlib.h> /* we'll get errors here */

int main(void)
{
  printf("Hello, world!\n");
  exit(EXIT_SUCCESS);
}

Using -Aw solves the problems with wchar_t, but not the ones
with long long.  Anyway, the header files should ifdef out such
definitions in ANSI mode, because it prevents compiling
perfectly legal ANSI code, be it C or C++.  I don't think that a
compiler should choke at its own headers...

I'm using the 8.1c patch for the CD.  BTW, in the change log
for 8.18 it's written: "long longs no longer turned off by -A" -
then, why am I getting these errors?


Laurentiu Pancescu

Aug 29 2001

↑ ↓ ← → Laurentiu Pancescu <plaur crosswinds.net> writes:

Thanks, Walter!

It works fine for that small test program.  NASM still won't
compile in ANSI mode, because of those pointer conversions, and,
if I use -Jm in addition to -A, it cannot compile stdlib.h,
because wchar_t is unknown.

Why does DM consider that converting "void (*)()" to "void
(*)(int, FILE *)" is illegal in ANSI mode?  It should only emit
warnings, not errors, IMHO.  BTW, gcc -Wall -ansi -pedantic
doesn't even emit warnings for those implicit conversions, and
neither does Borland's bcc 5.5.1...  I know that using this kind of
implicit conversions is not recommended, but it's legal ANSI-C
code, isn't it?


Laurentiu Pancescu

"Walter" <walter digitalmars.com> wrote:

I've attached a fixed stdlib.h. Try it with that one. -Walter

Aug 31 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

Why does it need to be compiled with -A?

Laurentiu Pancescu wrote in message <9moio6$5mo$1 digitaldaemon.com>...
Thanks, Walter!

It works fine for that small test program.  NASM still won't
compile in ANSI mode, because of those pointer conversions, and,
if I use -Jm in addition to -A, it cannot compile stdlib.h,
because wchar_t is unknown.

Why does DM consider that converting "void (*)()" to "void
(*)(int, FILE *)" is illegal in ANSI mode?  It should only emit
warnings, not errors, IMHO.  BTW, gcc -Wall -ansi -pedantic
doesn't even emit warnings for those implicit conversions, and
neither does Borland's bcc 5.5.1...  I know that using this kind of
implicit conversions is not recommended, but it's legal ANSI-C
code, isn't it?


Laurentiu Pancescu

"Walter" <walter digitalmars.com> wrote:

I've attached a fixed stdlib.h. Try it with that one. -Walter

Aug 31 2001

↑ ↓ ← → Laurentiu Pancescu <plaur crosswinds.net> writes:

"Walter" <walter digitalmars.com> wrote:

Why does it need to be compiled with -A?


Actually, I don't think it really *needs* that... I
successfully compiled it without -A, and I ran it without any problems. 
NASM's authors claim that NASM can be compiled with any ANSI-C
compliant compiler, and even more, for most compilers, they
disable extensions and enforce strict ANSI-C mode.

It was important for me because when you write a console-mode
program, and want it to be really portable, you try to stick to
strict ANSI (be it C or C++).  The -A switch is very useful
from this point of view, and I just wanted to test DM's ANSI-C
compliance with something non-trivial...  :)

Do you expect there will be another patch version after 8.1c?

Thanks again,
  Laurentiu

Sep 01 2001

↑ ↓ ← → "Walter" <walter digitalmars.com> writes:

Ok, I'm just glad you got NASM to work and this issue isn't blocking you.
There's already an 8.1d patch, but it doesn't address the void cast
problem. -Walter

Laurentiu Pancescu wrote in message <9mq7h3$186k$1 digitaldaemon.com>...
"Walter" <walter digitalmars.com> wrote:

Why does it need to be compiled with -A?


Actually, I don't think it really *needs* that... I
successfully compiled it without -A, and I ran it without any problems.
NASM's authors claim that NASM can be compiled with any ANSI-C
compliant compiler, and even more, for most compilers, they
disable extensions and enforce strict ANSI-C mode.

It was important for me because when you write a console-mode
program, and want it to be really portable, you try to stick to
strict ANSI (be it C or C++).  The -A switch is very useful
from this point of view, and I just wanted to test DM's ANSI-C
compliance with something non-trivial...  :)

Do you expect there will be another patch version after 8.1c?

Thanks again,
  Laurentiu

Sep 01 2001