Re: [Nasm-devel] Windows import and export directive support

[Ed B. <be...@mi...>]

Aaron Gray wrote:

>> Hehe. You've re-introduced the buffer overflow we just got
>> rid of. To get "snprintf", we had to go from "C89" to "C99"
>> (whatever *that* means). This broke the build process for
>> several compilers. I've gotta remove references to "std=c99"
>> from the Linux Makefile, djgpp requires "2.04 beta" to
>> build, as I recall, the workaround for VC was "_snprintf"...
>> I think the trick is to "#define snprintf _snprintf" (in
>> nasm.h, or so...) There's a message about it in the
>> "archives" (horrid interface...) around 02/26/05, I think...
> 
> Oh dear, thats why they are there, but shurely they will just truncate a 
> string that should be there in full and lead to hidden errors. Really 
> the buffer size should be calculated correctly in the first place. Or am 
> I barking up the wrong tree ?

Maybe not.  It's possibly just a difference in philosophy.  I think we 
can all agree that a buffer overflow is a Bad Thing and can lead to all 
kinds of problems, including potentially malicious exploits.  So then 
the question is how to fix it.

One way to fix it is to simply chop the result to the buffer size, which 
has, potentially, the problem of hidden  errors.  It's been a while 
since I looked at that code, but I seem to recall that in those 
particular instances, that a user would only have a hidden error if the 
had two symbols (e.g. variable names) which were both over 4096 bytes 
and only differed in characters after that.

The other way to fix it, is to leave the chop in place and additionally 
make sure that there's no way that the input string can ever actually be 
  chopped.  I think I looked at that but lacked the time and inclination 
to go that extra step.  It would probably be welcome if you decided to 
do that, though.

Ed