Re: Nasm 0.99.00


"Rod Pemberton" <do_not_have@xxxxxxxxxxx> wrote in message
news:46582e30$1@xxxxxxxxxxxxxxxxxxxxxxx

"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:1Jf5i.11410$xP.10082@xxxxxxxxxxx

Hmm..., reply didn't make it to clax "Nasm 0.99.0" thread.

"Frank Kotler" <spamtrap@xxxxxxxxxx> wrote in message
news:4655EA73.6080502@xxxxxxxxxxxxxx
Oh, oh! Nasm *does* require C99 support - since 0.98.39 (needed
"snprintf" to get rid of a buffer overflow). C99 is apparently not as
widely/fully supported as I'd been led to believe...

Oh, no! You just killed the ability to compile it with DJGPP for DOS.
I'm
constantly having to convert snprintf() code for DJGPP. Sigh... ANSI or
C90! :-) Actually, I usually convert them to a combination of strncpy()
and
sprintf().

OpenWatcom has snprintf. I don't know about the other DOS compilers.

This is how I convert. Take this line from Linux's FDISK:

snprintf(error, sizeof(error), _("Unable to open %s\n"), disk_device);

Assuming the buffer is large enough, that can be converted to a
combination
of strncpy() and sprintf():

char buf_snprintf[1024];

sprintf(buf_snprintf, _("Unable to open %s\n"), disk_device);
strncpy(error,buf_snprintf,sizeof(error));

Do you have a better method?


conditionally compiled wrapper function?...

actually, personally I have never heard of nor used snprintf...

actually, in writing my own compiler, one feature that scares me is
dynamically sized arrays, ...


int i;

i=rand()&0xFFF;
char arr[i];

WTF? we have to support things like this?...
pure terror...


so, yeah, if I ever do get my compiler functional, likely at least some
features I will leave out.

that or, if no one minds, the compiler could silently implement it like
this:

char *arr;
int i;

i=rand()&0xFFF;
arr=malloc(i);

and on function exit:
free(arr);

or, maybe it could use alloca.
I don't know...



Rod Pemberton



.

Relevant Pages