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

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
>

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

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

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
>

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

"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

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
>