How do I SHORTEN a file without rewriting it?
Laird Broadfield
lairdb at crash.cts.com
Mon Oct 29 20:17:34 AEST 1990
In article <thurlow.657134836 at convex.convex.com> you write:
>In <5289 at crash.cts.com> lairdb at crash.cts.com (Laird Broadfield) writes:
>
>>In article <2830 at lectroid.sw.stratus.com> bad at atrain.sw.stratus.com (Bruce Dumes) writes:
>>>In article <1162 at bilver.UUCP> alex at bilver.UUCP (Alex Matulich) writes:
>>>>
>>>>Is there a way to shorten a file, that is, chop some data off the end of
>>>>it, so that it doesn't consume as much physical space on the disk? The
>>>>file I have is too big to read into memory and write back out again, and
>>>>there is not enough room on the disk to write out a temporary file.
>>>
>>>Have you thought about using ftruncate()?
>
>>Okay, tell us where in K&R you find ftruncate. I don't see it in
>>the TurboC manual, or K&R2. Perhaps YOUR funky.lib has it, but not
>>everyone's does.
>
>Take it easy, Laird. ftruncate() is a Berkeley Unix system call, and
>would probably have nothing to do with K&R or Turbo C in any case.
>While it isn't all that useful to point to it without saying where it
>comes from, there very well might have been a lookalike function in
>someone's C library. And there was no clue to readers of comp.lang.c
>that Alex wanted an MS-DOS solution.
>
>Some people don't think enough about the fact that C is everywhere,
>and that <insert your OS of choice here> is not reflective of the way
>the whole world works. It annoys me wherever I see it. ...
[flame control at 30%]
I don't particularly want to drag this out much further, but I've
received at least one flame on my message as well as your (non-flame,
(mostly) well-thought-out) response. Perhaps my response was a little
vitriolic, but Bruce's had more than a small air of "What a stupid
question."
1) Alex did not ask for an MSDOS solution, he asked for a C solution.
A proper response might have been "Let me explain the difference
between language features and library functions ...()... therefore
you should RTFM, libraries differ." I don't think "Here's the function
you blind idiot." with no mention of OS or compiler differences was
valid. In fact, _I_ was the first one to mention TurboC, and I could
as well have mentioned my 8080-CP/M environment C compiler's libraries,
the point is the same. (It doesn't have ftruncate() either.) (We
may never know what Alex's environment is, he's probably too embarrased
by now over the fuss it's kicked up. :-) )
2) K&R is not the ANSI standard. K&R2 _incorporates_ the ANSI standard,
and a whole lot of other stuff, including library _guidelines_ which
have, substantially, been followed by compiler vendors on _many_
targets. (Actually, I don't have it handy here, the library stuff
may be part of the ANSI document, but I'm pretty sure if so they
are "Additions and Appendices" rather than part of the standard itself.)
3) I was not "bitching" that Bruce did not provide a tailored MSDOS-
specific answer; I was "annoyed", as you say you are, by his asumption
that BSD is the world. Again, perhaps I was a little harsh in my
response, and admittedly most academic computing fosters this view,
but people do need to keep in mind that C implements on an incredibly
wide range of targets and OSs. Personally I think MSDOS is among the
worst, but that's neither here nor there.
Anyway:
1) Alex, read and understand about the differences between library and
language, and then please _do_ ask appropriate questions. Just
remember to include sufficient background so net.land can help.
2) Bruce, I didn't really mean to reply to a spitball with a tac-nuke,
but you should remember that Berkeley, and *IX for that matter, is
not the world. Please accept one minor-apology token if you feel
you deserve one.
3) Rob, your comments are appropriate and well-taken.
'Nuff said. ("yow! let's burn some bandwidth, binky!")
--
-- Laird P. Broadfield | Year after year, site after
UUCP: {akgua, sdcsvax, nosc}!crash!lairdb | site, and I still can't think
INET: lairdb at crash.cts.com | of a funny enough .sig.
More information about the Comp.lang.c
mailing list