NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/lang/c/11407

Internet Message Format | 1992-07-21 | 3.2 KB

Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!wupost!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!decwrl!decwrl!oracle!unrepliable!bounce
From: [e-mail] (William Kaufman)
Newsgroups: comp.lang.c
Subject: Re: (Help) dynamic use of sprintf ?
Message-ID: <[e-mail]>
Date: 21 Jul 92 01:56:26 GMT
References: <brself.711345285@hal> <[e-mail]> <[e-mail]>
Sender: [e-mail] (Oracle News Poster)
Organization: Oracle Corporation, Redwood Shores CA
Lines: 56
Nntp-Posting-Host: hqsun2.us.oracle.com
X-Disclaimer: This message was written by an unauthenticated user
              at Oracle Corporation.  The opinions expressed are those
              of the user and not necessarily those of Oracle.

In article <[e-mail]> [e-mail] (Richard A. O'Keefe) writes:
] In article <[e-mail]>, [e-mail] (William Kaufman) writes:
] > In article <brself.711345285@hal> [e-mail] (Ben Self) writes:
] > ]
] > ]      . using the return value of fprintf () to a file pointer attached
] > ]        to /dev/null with the same arg format that I pass to sprintf ()
] >
] >     Oooh, icchh!  All the overhead of opening a useless file, writing to
] > the file every time, closing the file; the malloc()'s, free()'s and
] > system calls the stdio functions use.  This solution I'd *absolutely*
] > argue against.
]
] I would respectfully point out that there is no need to open and close
] a file _EACH_TIME_.

    OK, this is the second guy to tell me that.

    The "every time", by proper placement of commas, binds with "writing
to the file", not with "opening a useless file".  To be C-ish, this
should be parsed as:

        opening(useless_file);
        while (every_time--)
            writing_to(useless_file);
        closing(useless_file);

    And there's still fopen()'s malloc() and fclose()'s free (every
implementation I've seen does this for the I/O buffer(s)).  And you can
expect that writing to /dev/null, or whatever the local bitbucket is,
will go all the way down, straight to whatever passes for a kernel, and
all the way up: for N variable-length sprintf()'s, that's N+2 system
calls that do damned little.

    I stand by my statement, and hereby proudly reiterate:

        Oooh.  Icchh.

    (Oh, and your code isn't re-entrant.  Nyah. ;-)

] The best thing of all would be to use a stdio implementation that lets
] users define their own stuff, like the 4.4BSD one, so that "null files"
] can be implemented with _no_ mallocs, frees, or system calls, but still
] look just like other stdio files.

    OK, I admit, I haven't seen any BSD internals: maybe it recognizes
the bitbucket as "special" and doesn't have the overhead.  But I really
wouldn't exactly count on that everywhere.

    (Maybe I can take some comfort that no one addressed the other
options I put forward,...)

                                           -- Bill K.

Bill Kaufman,          | "...all conscious species are plastic and
Corporate Lackey       |  all plastic species are conscious."
[e-mail] |                     -- Yew-Kwang Ng