Mail Archives: djgpp/2013/04/06/03:15:18
Hi,
Just a few comments (from a noob-ish fop, so take it with a bucket of salt ...)
On Friday, April 5, 2013 6:50:19 PM UTC-5, Mikhail Ryazanov wrote:
> On 03.04.2013 11:59, rugxulo AT gmail DOT nospam wrote:
>
> > You can instead use the simple snprintf() / vsnprintf() versions
> > included in latest NASM if desired:
>
> Thanks for suggestions!
FYI, NASM used to be strict ANSI C89, but 2.x changed to needing some C99 stuff. AFAIK, only GCC and OpenWatcom are supported (and the latter is a fair bit weaker re: C99).
I don't want to say C99 isn't any good, but it surely isn't (IMHO) as popular as C89 was. Of course, esp. for old things like DOS, most compilers were C89 at best.
> However, I use DJGPP mostly as a mean to run gcc under MSW ...
Under Windows? Yes, that used to be one of the best ways. Nowadays, it might be the worst (unless you still use XP). Other choices include DOSEMU, DOSBox ("only for games"), VirtualBox, QEMU, bootable USB (e.g. RUFUS) or a native DOS install (dual boot).
> ... for checking standard compliance and portability, so
> the idea is that it must compile my sources without tweaking them. :-)
There's nothing wrong with adding compatibility when needed or replacing pre-existing functionality when desired. Sometimes standards conflict. Sometimes they are ignored. Other times they just aren't feasible. Most projects honestly don't care. People seem to enjoy coding for hardware peripherals (esp. for multimedia) more than "standard" console and file I/O. Certainly Linux and Windows projects never waste time supporting DOS/DJGPP. :-(
In your case, vsnprintf is a C99 function that 2.03p2 (circa late 2001) didn't have. There's nothing wrong with testing for standards compliance with DJGPP, but there are some obvious holes. Especially some things can't be widely implemented (fork, mmap, threads, Unicode) and others are too tedious for the few volunteers (e.g. most C11 stuff is still missing; better support exists elsewhere, sadly).
Also, lest I forget, be careful that some "standard" code has some environmental dependencies, e.g. memory requirements, file names, or assumes 32-bit int / long / pointer, etc. Know your limits.h, choose your standard wisely, and modularize everything.
> Do you know about any problems with v2.04?
Still "beta" because of no release manager. It works well enough (and sometimes better) than 2.03p2 but wasn't tested in as many environments as previous "stable". It (DJDEV204.ZIP) hasn't been officially refreshed since late 2003 (though CVS has had various fixes), so there are some minor problems: popen, rdtsc, some minor LFN call errors, and probably some other stuff I don't know about.
Go ahead and use it, I use it all the time, but don't mix 2.03p2 libraries and headers (e.g. Ada) with 2.04 stuff. Oh, 2.04 has pseudo-symlink support, but that bloats up the libc a bit. Also it has some large 4 GB file fixes, but that's rare (and not supported on XP-ish OSes, IIRC). Some other minor stuff (better malloc? but not nmalloc??), better DXE support (DXE3).
DJGPP is awesome, but we (they?) seriously need some more volunteers. GSoC? Kickstarter? Heh, well at least they've got me. (gong!) ;-)
- Raw text -