Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
August 19, 2001 ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
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 |
August 21, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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 > |
August 29, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 >> > > |
August 30, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu Attachments: | 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 >>> >> >> > |
August 31, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter |
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
>
|
September 01, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu | 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 >> > |
September 01, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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
|
September 01, 2001 Re: ANSI compiling issue | ||||
---|---|---|---|---|
| ||||
Posted in reply to Laurentiu Pancescu | 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 > |
Copyright © 1999-2021 by the D Language Foundation