www.digitalmars.com         C & C++   DMDScript  

c++ - ANSI compiling issue

reply 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
parent reply "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
parent reply 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
parent reply "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
begin 666 stdlib.h M*B!$969I;F4 7T-25$%023( *&9O<B!C;VUP871I8FEL:71Y('=I=& =&AE M($Y4(%-$2RD *B\-"B-I9FYD968 7T-25$%023(-"B-D969I;F4 7T-25$%0 M9FYD968 7T-25$E-4 T*(VEF(&1E9FEN960H7U=)3C,R*2 F)B!D969I;F5D M1$5&24Y%1"D-"G1Y<&5D968 =6YS:6=N960 <VAO<G0 =V-H87)?=#L-"B-D M"B-P<F%G;6$ <&%C:RA?7T1%1D%,24=.*0T*='EP961E9B!S=')U8W0 7T1) M3$1)5B![(&QO;F< <75O="QR96T[('T ;&1I=E]T.PT*(VEF(%]?24Y44TE: M="QR96T[('T ;&QD:79?=#L-"B-E;F1I9 T*(W!R86=M82!P86-K*"D-" T* M:68-" T*(VEF9&5F(%]?3E1?7PT*97AT97)N(&EN="!?7T-,24()7U]L;V-A M7T-,24( 7V5R<FYO("AV;VED*3L-"B-D969I;F4 97)R;F\ *"I?97)R;F\H M8VAA<B J*3L-"FQO;F< ("!?7T-,24( 871O;"AC;VYS="!C:&%R("HI.PT* M9&]U8FQE(%]?0TQ)0B!S=')T;V0H8V]N<W0 8VAA<B J+&-H87( *BHI.PT* M*BHI.PT*;&]N9R (%]?0TQ)0B!S=')T;VPH8V]N<W0 8VAA<B J+&-H87( M*BHL:6YT*3L-"G5N<VEG;F5D(&QO;F< (%]?0TQ)0B!S=')T;W5L*&-O;G-T M;F< ;&]N9R (%]?0TQ)0B!A=&]L;"AC;VYS="!C:&%R("HI.PT*;&]N9R!L M*3L-"G5N<VEG;F5D(&QO;F< ;&]N9R!?7T-,24( <W1R=&]U;&PH8V]N<W0 M8VAA<B J+&-H87( *BHL:6YT*3L-"B-E;F1I9 T*:6YT(" (%]?0TQ)0B!R M0TQ)0B!A=&5X:70H=F]I9" H*BDH=F]I9"DI.PT*=F]I9" (%]?0TQ)0B!E M971E;G8H8V]N<W0 8VAA<B J*3L-"FEN=" ("!?7T-,24( <WES=&5M*&-O M9" J+&-O;G-T('9O:60 *BQS:7IE7W0L<VEZ95]T+ T*(" (" (&EN=" H M:6YT("A?7T-,24( *BDH8V]N<W0 =F]I9" J+&-O;G-T('9O:60 *BDI.PT* M:6YT(" (%]?0TQ)0B!A8G,H:6YT*3L-"FQO;F< ("!?7T-,24( ;&%B<RAL M;VYG*3L-"F1I=E]T("!?7T-,24( 9&EV*&EN="QI;G0I.PT*;&1I=E]T(%]? M;F< ;&]N9R (%]?0TQ)0B!L;&%B<RAL;VYG(&QO;F<I.PT*;&QD:79?="!? M+"!S:7IE7W0I.PT*<VEZ95]T(%]?0TQ)0B!W8W-T;VUB<RAC:&%R("HL(&-O M;G-T('=C:&%R7W0 *BP <VEZ95]T*3L-"G9O:60 ("!?7T-,24( <&5R<F]R M(" (" (%]?0TQ)0B!?<F]T;"AU;G-I9VYE9"QI;G0I.PT*=6YS:6=N960 M;VYG("!?7T-,24( 7VQR;W1L*'5N<VEG;F5D(&QO;F<L:6YT*3L-"G5N<VEG M;F5D(&QO;F< (%]?0TQ)0B!?;')O='(H=6YS:6=N960 ;&]N9RQI;G0I.PT* M8VAA<B J(%]?0TQ)0B!?9G5L;'!A=& H8VAA<B J8G5F+&-O;G-T(&-H87( M>7-?97)R;&ES=%M=.PT*(V1E9FEN92!?<WES7VYE<G( <WES7VYE<G(-"B-D M="!C:&%R(%]?9F%R("HL<VEZ95]T*3L-"FEN=" ("!?7T-,24( 7U]F87( M7V9W8W1O;6(H8VAA<B!?7V9A<B J+'=C:&%R7W0I.PT*<VEZ95]T(%]?0TQ) M0B!?7V9A<B!?9FUB<W1O=V-S*'=C:&%R7W0 7U]F87( *BP 8V]N<W0 8VAA M<B!?7V9A<B J+"!S:7IE7W0I.PT*<VEZ95]T(%]?0TQ)0B!?7V9A<B!?9G=C M<W1O;6)S*&-H87( 7U]F87( *BP 8V]N<W0 =V-H87)?="!?7V9A<B J+"!S M:7IE7W0I.PT*(V5L<V4-"FEN=" ("!?7T-,24( 7V9M8FQE;BAC;VYS="!C M:&%R(%]?9F%R("HL<VEZ95]T*3L-"FEN=" ("!?7T-,24( 7V9M8G1O=V,H M=V-H87)?="!?7V9A<B J+&-O;G-T(&-H87( 7U]F87( *BQS:7IE7W0I.PT* M:6YT(" (%]?0TQ)0B!?9G=C=&]M8BAC:&%R(%]?9F%R("HL=V-H87)?="D[ M=V-S=&]M8G,H8VAA<B!?7V9A<B J+"!C;VYS="!W8VAA<E]T(%]?9F%R("HL M>'1E<FX =6YS:6=N960 :6YT(%]?8V1E8VP 7V]S=F5R.PT*(VEF;F1E9B!? M>'1E<FX =6YS:6=N960 8VAA<B!?7V-D96-L(%]O<VUA:F]R.PT*97AT97)N M:69D968 7T1,3 T*97AT97)N(&EN=" J(%]?0TQ)0B!?7W!?7U]A<F=C*'9O M:60I.PT*97AT97)N(&-H87( *BHJ(%]?0TQ)0B!?7W!?7U]A<F=V*'9O:60I M.PT*97AT97)N('=C:&%R7W0 *BHJ(%]?0TQ)0B!?7W!?7U]W87)G=BAV;VED M*3L-"B-D969I;F4 7U]A<F=C"2 J7U]P7U]?87)G8R I*0T*(V1E9FEN92!? M7U]W87)G=B I*0T*(V5L<V4-"F5X=&5R;B!I;G0 7U]C9&5C;"!?7V%R9V,[ M9" H7U=)3C,R*0T*=V-H87)?=" J*B!?7T-,24( 7U]W<&%R<V5C;61L:6YE M*&-O;G-T('=C:&%R7W0 *BP :6YT("HI.PT*8VAA<B J*B!?7T-,24( 7U]P M(VEF(&1E9FEN960H7U=)3D1/5U,I('Q\(&1E9FEN960H7U].5%]?*0T*97AT M=6YS:6=N960 8VAA<B!?7V-D96-L(%]W:6YM:6YO<CL-"F5X=&5R;B!U;G-I M9"!C:&%R(%]?8V1E8VP 7V]S;6]D93L-" T*(V1E9FEN92!?4D5!3%]-3T1% M*BP 8VAA<B J+&-H87( *BP 8VAA<B J+"!C:&%R("HI.PT*=F]I9"!?7V-D M96-L(%]M86ME<&%T:"AC:&%R("HL(&-O;G-T(&-H87( *BQC;VYS="!C:&%R M("HL(&-O;G-T(&-H87( *BP 8V]N<W0 8VAA<B J*3L-"G9O:60 7U]C9&5C M;"!?<V5A<F-H96YV*&-O;G-T(&-H87( *F9I;&5N86UE+"!C;VYS="!C:&%R M:68 7U])3E1325I%(#T M7U]F87( *BQS:7IE7W0I.PT*(V5L<V4-"FEN="!?7V-D96-L(%]H96%P861D M;BAV;VED*3L-" T*(VEF9&5F(%]?3E1?7PT*(V1E9FEN92!?97AP86YD(')E M9&5C;"!?9F-A;&QO8RAS:7IE7W0L<VEZ95]T*3L-"G9O:60 *B!?7V-D96-L M(%]F<F5A;&QO8RAV;VED("HL<VEZ95]T*3L-"G9O:60 7U]C9&5C;"!?9F9R M964H=F]I9" J*3L-"G-I>F5?="!?7V-D96-L(%]F;7-I>F4H=F]I9" J*3L- M"G5N<VEG;F5D(&QO;F< 7U]C9&5C;"!C;W)E;&5F="AV;VED*3L-"G5N<VEG M;F5D(&QO;F< 7U]C9&5C;"!F87)C;W)E;&5F="AV;VED*3L-"B-I9B!?5TE. M1$]74PT*=F]I9"!?7VYE87( *B!?7V-D96-L(%]N;6%L;&]C*'-I>F5?="D[ M96%R("HL<VEZ95]T*3L-"G9O:60 7U]C9&5C;"!?;F9R964H=F]I9"!?7VYE M.PT*<VEZ95]T(%]?8V1E8VP 7VUE;6UA>"AV;VED*3L-"G-I>F5?="!?7V-D M;FUA;&QO8RAS:7IE7W0I.PT*=F]I9" J(%]?8V1E8VP 7VYC86QL;V,H<VEZ M;65M;6%X*'9O:60I.PT*<VEZ95]T(%]?8V1E8VP 7VUE;6%V;"AV;VED*3L- M"G5N<VEG;F5D(&EN="!?7V-D96-L(%]F<F5E8W0H<VEZ95]T*3L-"G5N<VEG M;"!?9FUA;&QO8RAS:7IE7W0I.PT*=F]I9"!?7V9A<B J(%]?8V1E8VP 7V9C M25I%(#T M;V$H;&]N9RP 8VAA<B J+"!I;G0I.PT*8VAA<B J(%]?0TQ)0B!?;'1O82AL M;F5D(&QO;F<L(&-H87( *BP :6YT*3L-"F-H87( *B!?7T-,24( 96-V="AD M;W5B;&4L:6YT+&EN=" J+&EN=" J*3L-"F-H87( *B!?7T-,24( 9F-V="AD M;W5B;&4L:6YT+&EN=" J+&EN=" J*3L-"F-H87( *B!?7T-,24( 7V9C=G0H M9&]U8FQE+&EN="QC:&%R("HI.PT*=F]I9" J(%]?8V1E8VP <V)R:RAS:7IE M7W0I.PT*=F]I9" (%]?0TQ)0B!S=V%B*&-H87( *BQC:&%R("HL<VEZ95]T M*3L-"F9L;V%T("!?7T-,24( <W1R=&]F*&-O;G-T(&-H87( *BQC:&%R("HJ M>7!E9&5F('9O:60 *%]?8V1E8VP *B!?9F]N97AI=%]T*2AV;VED*3L-"E]F M;VYE>&ET7W0 7U]C9&5C;"!?9F]N97AI=" H7V9O;F5X:71?="!F=6YC*3L- M9&5C;"!?7V9A<B J9G5N8RDH=F]I9"DI.PT*='EP961E9B!V;VED("A?7V-D M:68-" T*='EP961E9B!V;VED("A?7V-D96-L("H 7V]N97AI=%]T*2AV;VED M*3L-"E]O;F5X:71?="!?7V-D96-L(%]O;F5X:70 *%]O;F5X:71?="!F=6YC M*3L-" T*(VEF;F1E9B!?7U-41$-?7PT*(V1E9FEN92!O;F5X:70 7V]N97AI M(%]?9F%R(%]?0TQ)0B!?7VUA;&QO8V8H<VEZ95]T*3L-"G9O:60 (" (" M969I;F4 7U]M87 H82QB*2 (" (" (" (" H*&$I(#X *&(I*2 _("AA M*2 Z("AB*2D-"B-D969I;F4 7U]M:6XH82QB*2 (" (" (" (" H*&$I M(#P M7U]F87( 7U]C9&5C;" J7VUA;&QO8U]H86YD;&5R*2AV;VED*3L-"F5X=&5R M(%]E;G9I<F]N(" J7W!?96YV:7)O;B I*0T*(V5L<V4-"F5X=&5R;B!C:&%R M='( 7V5N=G!T< T*97AT97)N('=C:&%R7W0 *B!?7V-D96-L(%]W96YV<'1R M=V5N=FER;VX *'9O:60I.PT*(V1E9FEN92!?=V5N=FER;VX *"I?<%]W96YV M:7)O;B I*0T*(V5L<V4-"F5X=&5R;B!W8VAA<E]T("HJ(%]?8V1E8VP 7W=E M960 *%]?3E1?7RD ?'P 9&5F:6YE9" H1$]3,S V*2D-"F5X=&5R;B!I;G0 M:6YT(%]?8V1E8VP ;W!T:6YD.PT*97AT97)N(&EN="!?7V-D96-L(&]P=&5R M3$E"('=C<W1O;&0H8V]N<W0 =V-H87)?=" J+"!W8VAA<E]T("HJ*3L-"FQO M:&%R7W0 *BP =V-H87)?=" J*BP :6YT*3L-"FQO;F< ;&]N9R!?7T-,24( M0TQ)0B!?=V=E=&5N=BAC;VYS="!W8VAA<E]T("HI.PT*:6YT(%]?0TQ)0B!? M=W-Y<W1E;2AC;VYS="!W8VAA<E]T("HI.PT*=V-H87)?=" J(%]?0TQ)0B!? M:71O=RAI;G0L('=C:&%R7W0 *BP :6YT*3L-"G=C:&%R7W0 *B!?7T-,24( M7VQT;W<H;&]N9RP =V-H87)?=" J+"!I;G0I.PT*=V-H87)?=" J(%]?0TQ) M0B!?=6QT;W<H=6YS:6=N960 ;&]N9RP =V-H87)?=" J+"!I;G0I.PT*=V-H M87)?=" J(%]?0TQ)0B!?=V9U;&QP871H*'=C:&%R7W0 *BP 8V]N<W0 =V-H M87)?=" J+"!S:7IE7W0I.PT*=F]I9"!?7T-,24( 7W=M86ME<&%T:"AW8VAA M<E]T("HL(&-O;G-T('=C:&%R7W0 *BP 8V]N<W0 =V-H87)?=" J+"!C;VYS M87)C:&5N=BAC;VYS="!W8VAA<E]T("HL(&-O;G-T('=C:&%R7W0 *BP =V-H M7W0 *BP =V-H87)?=" J+"!W8VAA<E]T("HL('=C:&%R7W0 *BP =V-H87)? M=" J*3L-"B-D969I;F4 :71O=R!?:71O=PT*(V1E9FEN92!L=&]W(%]L=&]W ` end
Aug 29 2001
parent reply 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
parent reply "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
parent reply 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
parent "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