🚀 go-pugleaf

In article <4gfe2b$32l@solutions.solon.com>,
Paul Schlyter <pausch@electra.saaf.se> wrote:
>
>There is one good reason to allow sprintf/sscanf bot not printf/scanf in
>a DLL:  printf/scanf need to malloc() a memory buffer.  sprintf/sscanf
>need not do this, since they are given a memory buffer when called.

Huh?  Why is this a "good reason"?  Are you saying that malloc()
cannot be used in a DLL either?  (I've never used DLL's, but
it's beginning to sound to me that any claim that you can use
"C" with them could be considered fraudulent.)

Also, even if the reason for not having printf/scanf makes some sense
(nowhere for the input to come from / output to go to), there
surely would be a need for fprintf/fscanf, which surely require
malloc() if printf/scanf do.

I am not impressed by any of the arguments others have made pertaining
to near vs. far pointers.  Any sensible compiler could (and should)
take care of that whenever #include <stdio.h> is present.

Cheers,
Stan.
--
Stan Ryckman  (stanr@tiac.net) (new e-mail address)