Full ANSI Compliance of WLA-DX

[cr1901]

Ville, do you object if I/we change the -pedantic option to -pedantic-errors, and add -Wextra? This entails a few minor code tweaks where gcc complains (mainly below-bound array subscript), but I'd love to see the assembler suite backported to some older systems, where the assembler is in fact native :).

Though I say gcc, of course adding other compilers is simple as well. MinGW is just my default compiler. I'd suggest anyone who did so make sure extensions are disabled and warnings are enabled (and maxed :P). More to the point, I think it's great to be able to say that: "If your platform has an ANSI C Compiler, you can compile this successfully."

[vhelin]

On Fri, Apr 25, 2014 at 6:23 AM, William D. Jones notifications@github.comwrote:

Ville, do you object if I change the -pedantic option to -pedantic-errors, and add -Wextra? This entails a few minor code tweaks where gcc complains

No objections, strict compiling is good. Though I just checked, using those flags will give a couple unsigned int vs int warnings that will then need fixing. Possibly a good thing.

(mainly below-bound array subscript), but I'd love to see the assembler suite backported to some older systems, where the assembler is in fact native :).

Making WLA-DX to run on e.g. Z80? Huh, sounds like a big challenge. :)

Though I say gcc, of course adding other compilers is simple as well. MinGW is just my default compiler. I'd suggest anyone who did so make sure extensions are disabled and warnings are enabled (and maxed :P). More to the point, I think it's great to be able to say that: "If your platform has an ANSI C Compiler, you can compile this successfully."

Sounds great! If you have to energy to add support for other compilers, feel free to make the scripts / mods.

— Reply to this email directly or view it on GitHubhttps://github.com/vhelin/wla-dx/issues/2 .

[vhelin]

On Fri, Apr 25, 2014 at 12:34 PM, Ville Helin ville.helin@gmail.com wrote:

On Fri, Apr 25, 2014 at 6:23 AM, William D. Jones < notifications@github.com> wrote:

Ville, do you object if I change the -pedantic option to -pedantic-errors, and add -Wextra? This entails a few minor code tweaks where gcc complains

No objections, strict compiling is good. Though I just checked, using those flags will give a couple unsigned int vs int warnings that will then need fixing. Possibly a good thing.

Just to let you know: I replaced "-pedantic" with "-pedantic-erros -Wextras" in the unix makefiles, and fixed those warnings.

(mainly below-bound array subscript), but I'd love to see the assembler suite backported to some older systems, where the assembler is in fact native :).

Making WLA-DX to run on e.g. Z80? Huh, sounds like a big challenge. :)

Though I say gcc, of course adding other compilers is simple as well. MinGW is just my default compiler. I'd suggest anyone who did so make sure extensions are disabled and warnings are enabled (and maxed :P). More to the point, I think it's great to be able to say that: "If your platform has an ANSI C Compiler, you can compile this successfully."

Sounds great! If you have to energy to add support for other compilers, feel free to make the scripts / mods.

— Reply to this email directly or view it on GitHubhttps://github.com/vhelin/wla-dx/issues/2 .

[cr1901]

(Sorry for the delay...) Beautiful, thanks! EDIT: Ignore the rest of this comment. I include it for completeness, but I removed the branch remotely because it doesn't take into effect that someone porting to an OS will need to add the platform-specific code into the WLA suite (#ifdef MY_OS) before they EVER worry about Makefile generation :P. Short-sightedness on my part. Assuming a supported OS, porting to another compiler besides GCC is still simple, if inconvenient (need to rewrite makefiles).

I made a new branch called "refactor/build-sys", and created a script to autogenerate Makefiles, provided they have m4 installed. This should make porting to other compilers easier, but it's still up to the user to make sure they create a simple build script.

To be perfectly honest, I'm not sure how useful this will be, an may remove the branch... a user who wishes to port to a new compiler doesn't actually need to do much more work (just remember to change CC, LD, etc for all makefiles), but this makes it less likely that they miss a script by accident. There is no guarantee that these m4 scripts will generate a correct makefile out-of-the-box for OSes with esoteric command lines (AmigaOS 3 and earlier).

There may be a better solution to this than my way- that additionally makes it less likely for those porting to make a mistake (forgetting to change a makefile's command line for instance). I'd advise against using a "global config include" for the Makefiles, since I believe the include directive isn't portable between makes (nmake, GNU make, BSD make).

[vhelin]

On Tue, May 6, 2014 at 8:22 AM, William D. Jones notifications@github.comwrote:

(Sorry for the delay...) Beautiful, thanks! I made a new branch called "refactor/build-sys", and created a script to autogenerate Makefiles, provided they have m4 installed. This should make porting to other compilers easier, but it's still up to the user to make sure they create a simple build script.

To be perfectly honest, I'm not sure how useful this will be, an may remove the branch... a user who wishes to port to a new compiler doesn't actually need to do much more work (just remember to change CC, LD, etc for all makefiles), but this makes it less likely that they miss a script by accident. There is no guarantee that these m4 scripts will generate a correct makefile out-of-the-box for OSes with esoteric command lines (AmigaOS 3 and earlier).

There may be a better solution to this than my way that makes it less likely for those porting to make a mistake (forgetting to change a makefile's command line for instance). I'd advise against using a "global config include" for the Makefiles, since I believe the include directive isn't portable between makes (nmake, GNU make, BSD make).

I haven't received any requests regarding adding support for new compilers for years, and I think that the guys who wanted WLA DX to compile on say Amiga OS4, wrote the missing makefiles and such themselves. That in mind it's completely up to you to decide what to do. The Makefile autogenerator script might be useful to some people, I guess, as the current makefiles don't cover all operating systems. I have to admit that I really don't know. If you think the script is good to have, then it is. :)

— Reply to this email directly or view it on GitHubhttps://github.com/vhelin/wla-dx/issues/2#issuecomment-42268867 .

[cr1901]

The more I think about it, the more I think it would be useful to have it as a separate project for developers as a TOOL (rather than a prerequisite). I've also been on an M4 kick (ironic, considering I run Windows 98% of the time).

Knowing me, it's only a matter of time before I screw up the build because I forgot to edit a Makefile. As they are, the Makefiles present in the source tree look autogenerated as is (in the respect that they all are formatted the same way, just that exe and object names have been changed).

You may have noticed that I added CL.EXE (Microsoft's compiler for Windows) support to the Makefiles... writing the Makefiles took about an hour, but they worked right out-of-the-box since the code is standard C. Anyone who wishes to add a backend will of course now need to write 6 Makefiles instead of 5 (DJGPP, MinGW, POSIX, Amiga 1-3, Amiga 4, and now CL) :P.

Although the fact I like DOS from Vintage Computing makes me biased a bit, I feel the DOS and Amiga ports are still valid because there are a multitude of tools that people used in the past for homebrew that still only exists for those platforms (GEMS for z80 music, DeluxePaint was THE gfx editor for Amiga, so I've heard)... and having the assembler right there should make it easier to make an entire dev system.

[vhelin]

On Fri, May 9, 2014 at 2:37 PM, William D. Jones notifications@github.comwrote:

The more I think about it, the more I think it would be useful to have it as a separate project for developers as a TOOL (rather than a prerequisite). I've also been on an M4 kick (ironic, considering I run Windows 98% of the time).

Knowing me, it's only a matter of time before I screw up the build because I forgot to edit a Makefile. As they are, the Makefiles present in the source tree look autogenerated as is (in the respect that they all are formatted the same way, just that exe and object names have been changed).

Ok, let's have the Makefile autogenerator script as a tool for those people who are not happy with the existing, hardcoded makefiles. :)

— Reply to this email directly or view it on GitHubhttps://github.com/vhelin/wla-dx/issues/2#issuecomment-42657074 .

[cr1901]

I just re-pushed the branch (refactor/build-sys) back to remote. The generated Makefiles DO work, but... please excuse my horrendous bash scripting :P (gen_makefiles.sh).

[vhelin]

On Fri, May 9, 2014 at 2:49 PM, William D. Jones notifications@github.comwrote:

I just re-pushed the branch (refactor/build-sys) back to remote. The generated Makefiles DO work, but... please excuse my horrendous bash scripting :P (gen_makefiles.sh).

It doesn't look that bad. :) Anyway, I merged refactor/build-sys into master...

• Ville

— Reply to this email directly or view it on GitHubhttps://github.com/vhelin/wla-dx/issues/2#issuecomment-42657867 .

[cr1901]

Well thanks :P... in any case, I've tested both the CL an MinGW auto-generated scripts against the current scripts. They produce identical binaries (beyond certain fields in the Portable Executable format- Unix time of compiler, etc- which change between successive compiles and links), so I'm convinced they work properly.

I'll test the UNIX scripts on my Raspberry Pi since that's the only Linux distro I currently have. Amiga will have to wait until I get one :P. Since I can't test Amiga opcode table generation, I'll have to leave the opcodes_*_table.c source files intact for the time being for those who want to compile for Amiga.

As of right now (ed8eeba8), none of the generated-makefiles are being used, but they are ready to replace the old ones when I can test all currently-supported platforms :P.

[cr1901]

I just noticed that include_file.c uses fseek with the SEEK_END whence value. According to ANSI C (http://stackoverflow.com/questions/9830788/how-to-get-file-size-in-ansi-c-without-fseek-and-ftell), library implementations are allowed to not meaningfully support SEEK_END, so using it is implementation defined.

However, there's always going to be some implementation defined behavior in WLA (double requiring a size of 8-bytes... btw, this begs for a static_assert if it were ANSI :P), and since implementation-defined ANSI C is still standards-compliant, I'm not going to change it.

Besides, ALL modern C libraries should support SEEK_END :P. At some point, I may add a footnote for those looking to compile WLA on their TRS-80's or whatever. ;)

[vhelin]

On Fri, Jun 20, 2014 at 1:50 AM, William D. Jones notifications@github.com wrote:

I just noticed that include_file.c using fseek with the SEEK_END whence value. According to ANSI C ( http://stackoverflow.com/questions/9830788/how-to-get-file-size-in-ansi-c-without-fseek-and-ftell), library implementations are allowed to not meaningfully support SEEK_END, so using it is implementation defined.

However, there's always going to be some implementation defined behavior in WLA (double requiring a size of 8-bytes... btw, this begs for a static_assert if it were ANSI :P), and since it's implementation-defined ANSI C is standards-compliant, I'm not going to change it.

Besides, ALL modern C libraries should support SEEK_END :P.

Thanks for the heads up. :) I've never had issues with SEEK_END, but now that you mention it, we've been lucky so far. I also think that it doesn't require any immediate fixing, so let's fix it after we get a report from a user who has problems with SEEK_END...

— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/2#issuecomment-46626978.

[lhsazevedo]

How can we know that WLA DX has full ANSI Compliance?

[cr1901]

Flippantly, I define it as "compiles and runs properly on compilers not named cl, gcc, or clang". WLA DX is prob "good enough" minus the SEEK_SET thing. Let's wait until new tests are available that compile and pass on the old machines before closing this.

[vhelin]

Well, we already have WLA DX compiling on an Amiga with SAS/C 6.58 compiler. Anyone tried to compile WLA DX e.g. under MSDOS with another ancient compiler? :)

[lhsazevedo]

Back in #399 I was able to compile on FreeDOS and MSDOS, can try again

[vhelin]

But I think the MSDOS makefiles use gcc? What would be interesting is finding another compiler that is not gcc, cl or clang and using that to compile WLA DX under MSDOS.

OpenWatcom?

https://stackoverflow.com/questions/15096609/c-compiler-for-ms-dos

[cr1901]

OpenWatcom worked when I cross-compiled to MS-DOS using the Makefiles years ago. I have no reason to believe it would've broke since then. Or, if it did break, I don't think a fix would be invasive.

If WLA-DX still works under an Amiga C compiler, I'm happy to close this issue and test under OpenWatcom at a later date when I'm feeling up to it.

[vhelin]

I ran the tests under WinUAE just before releasing v10.1 so I think what SAS/C compiles on Amiga works pretty well. :)