Omer Mussaev <[EMAIL PROTECTED]> writes:

> Sorry, ppl , but IMHO Oleg had pointed out a very strong point. Imagine
> you are to distribute small utility, which takes, say, 300 kb. But, instead
> of using libc and debugging your code to death, you decided to rely on glib
> to provide it to you. As a programmer, you are to give out the cleanest code
> one can provide (well, we are talking very hypothetical programmer here).
> But as code provider, you must make sure that your code will fit into its
> place without headaches.
> In such a case you are to wind up by including glib in your distribution.

Right.

Actually, I was making an even stronger point. Imagine a situation
whereby you cannot include glib in your distribution, period. There
are abundant cases in this mad mad mad mad world where you do not have
control over your target platform or what you can or cannot use on it.

"No third-party code" regardless of the license is not such an
uncommon requirement. Does anyone doubt that "no open source code" is
used here and there? Both will preclude glib (or glibc for that
matter), and these are just the most obvious examples.
 
Even ANSI C might be too wide in pathological cases.  Just as a
curiosity, I know of at least one case where a requirement was not to
use malloc()/free() in the code [well, at least not easily]. Don't ask
for details, just take my word for it.

> Again, welcome to Real World of Real users. Forget all hope, yer, who enters
> there.

Sad chuckle.

-- 
Oleg Goldshmidt | BLOOMBERG L.P. (BFM) | [EMAIL PROTECTED]
"... We work by wit, and not by witchcraft;
 And wit depends on dilatory time." - W. Shakespeare.

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to