What is wrong with a standard truncate function ?

**Jack Klein** · Nov 10 '08, 02:55 AM

Re: What is wrong with a standard truncate function ?

On Mon, 10 Nov 2008 03:50:34 +0200, Timothy Madden
<terminatorul@g mail.comwrote in comp.lang.c:

[cross-posted to comp.lang.c, comp.lang.c++]
Hello
>
I see there is now why to truncate a file (in C or C++)
and that I have to use platform-specific functions for
truncating files.

If your platform has such functions.

Anyone knows why ? I mean C/C++ evolved over many years now,
and still, people making _the_ standards never decided to
include such a function. Even in POSIX it was included only
in recent versions, mostly not fully supported yet.

You seem to think that people making _the_ standards get to impose
their will by fiat.

Why is that ? They must think there is something wrong with it,
or that there are better ways to do it.

Or perhaps they think it is not generally useful enough.

I mean I want to write a portable application, I keep
application data in a file, at some point the user
deletes something from the data my program presents
to him/her, and now I delete some data from the data file
and want to shrink the file. Like a database system,
after dropping some records or tables and compacting
(or vacuum) the database. That is a good example
of when a programmer legally needs to truncate a file.

No, that is an example of when a programmer might want to truncate a
file.

Copying only remaining data to a new file that will then
replace the old one is not a solution for a large database,
and leaving the empty space in the file is also not a
solution for large files.

In your opinion, rewriting a file is "not a solution". I am sure that
others disagree. In fact, I think that there are many who would
disagree with compacting an existing file. Much too risky.

So why is it "not a solution"? For "large files", whatever your
definition of "large" is, I would suspect most programmers these days
would use a database engine. They are available for all popular
platforms, and even good, free open source versions are available. You
could use the database library to take care of details like this.

The simple fact is that it is not the language standard's job to add
every single function that some programmers might find useful. Once a
function is added to the standard library, every conforming
implementation needs to implement. Regardless of whether or not the
underlying operating system makes it easy.

There are many new language features or library functions that some
particular programmer thinks would make his/her job much easier, so
much so that it is worth the effort of every single compiler
implementer to add it to their compiler or library.

But no matter how useful such a function might be to you, there is a
cost/benefit calculation that need to be made.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

**Gordon Burditt** · Nov 10 '08, 04:05 AM

Re: What is wrong with a standard truncate function ?

>I see there is now why to truncate a file (in C or C++)

>and that I have to use platform-specific functions for
>truncating files.

Such functions might not exist.
Also, there is the issue of how accurately you can truncate a file.
In CP/M, for example, all binary files are a multiple of 128 bytes
(a single-density floppy sector) bytes in size. You can't make a
binary file with an odd length, period. Text files actually occupy
a multiple of 128 bytes in size, but an end-marker byte is used to
indicate the end of the data.

>Anyone knows why ? I mean C/C++ evolved over many years now,
>and still, people making _the_ standards never decided to
>include such a function. Even in POSIX it was included only
>in recent versions, mostly not fully supported yet.

Its usefulness seems limited, especially when compared with other
features like networking, pipes, sockets, multiple processes,
threads, etc.

>Why is that ? They must think there is something wrong with it,
>or that there are better ways to do it.

There's no function to reverse a string, either. Never mind that
it's only useful for homework.

File truncation might have some undesirable interaction with file
locking. What happens when you truncate a locked portion of a file?

>I mean I want to write a portable application, I keep
>application data in a file, at some point the user
>deletes something from the data my program presents
>to him/her, and now I delete some data from the data file
>and want to shrink the file.

This sort of issue comes up with *memory* and malloc() a lot.
It is often considered an optimization to not bother releasing
the memory back to the OS, but to keep it available when another
record is needed.

>Like a database system,
>after dropping some records or tables and compacting
>(or vacuum) the database.

Compacting a database is generally an expensive operation that
should not be done every time a record is deleted. It's often
easier to arrange to re-use the space when another record is needed.
In a database with fixed-size records, there's no fragmentation
problem.

>That is a good example
>of when a programmer legally needs to truncate a file.

That's why you WANT to truncate a file. It hasn't been established
as a need, except for pessimization of the speed of delete operations.
It might be an issue if the disk space for one punch card image (80
bytes) cost two cents. Instead we have terabyte disks that cost
about 35 cents per gigabyte. And it's still dropping.

>Copying only remaining data to a new file that will then
>replace the old one is not a solution for a large database,
>and leaving the empty space in the file is also not a
>solution for large files.

Often, it is. It may be acceptable for the database to take up
twice the space of the actual data, whether the data is a megabyte
or a terabyte. It's not uncommon for an index on a database to
take up about as much space as the data itself. It's often considered
a small price to pay for more speed.

**vippstar@gmail.com** · Nov 10 '08, 01:55 PM

Re: What is wrong with a standard truncate function ?

On Nov 10, 3:50 am, Timothy Madden <terminato...@g mail.comwrote:

[cross-posted to comp.lang.c, comp.lang.c++]
Hello
>
I see there is now why to truncate a file (in C or C++)
and that I have to use platform-specific functions for
truncating files.

There are ways.

int trunc(const char *file, size_t newsize) {
FILE *fp;
void *p = NULL;

if(newsize) {
fp = fopen(file, "rb");
if(fp == NULL) return 1;
p = malloc(newsize) ;
if(p == NULL) { fclose(fp); return 1; } /* errno may be lost and
the user will get a misleading error message */
if(fread(p, 1, newsize, fp) != newsize) { fclose(fp); return
1; } /* ditto */
fclose(fp);
}
fp = fopen(file, "wb");
if(fp == NULL) {
free(p);
return 1;
}
if(newsize) if(fwrite(p, 1, newsize, fp) != newsize) { free(p);
fclose(fp); return 1; } /* ditto */
free(p);
return fclose(fp) == EOF;
}

}

Anyone knows why ? I mean C/C++ evolved over many years now,
and still, people making _the_ standards never decided to
include such a function. Even in POSIX it was included only
in recent versions, mostly not fully supported yet.
>
Why is that ? They must think there is something wrong with it,
or that there are better ways to do it.

You're right. There is something wrong with it, that some platforms
that support C do not support file truncating (hell, some might not
even support file operations at all). There are better ways, to use a
more specific standard like POSIX.

**CBFalconer** · Nov 10 '08, 10:45 PM

Re: What is wrong with a standard truncate function ?

Timothy Madden wrote:

>
[cross-posted to comp.lang.c, comp.lang.c++]
>
I see there is now why to truncate a file (in C or C++)
and that I have to use platform-specific functions for
truncating files.

That depends on file systems, so cannot be portable.

Do not cross-post to c.l.c++. The languages are different.

F'ups set.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

**jameskuyper** · Nov 11 '08, 12:05 AM

Re: What is wrong with a standard truncate function ?

CBFalconer wrote:

Timothy Madden wrote:

[cross-posted to comp.lang.c, comp.lang.c++]

I see there is now why to truncate a file (in C or C++)
and that I have to use platform-specific functions for
truncating files.

>
That depends on file systems, so cannot be portable.
>
Do not cross-post to c.l.c++. The languages are different.

Cross-posting reinstated.

Don't overstate the differences between the languages. As far as this
issue is concerned they are very similar. All of the <stdio.h>
facilities are still present in C++, and the C++ standard mandates
connections between the behavior of the <iostreamlibrar y and the
behavior of the <stdio.hlibrary .

Both committees are committed to, among other priorities, avoiding
gratuitous incompatibiliti es between the two languages. Therefore, in
the unlikely event that either committee were inclined to add a file
truncation feature to their own language, the joint sub-committee
would seriously consider recommending that it also be added to the
other language in a compatible fashion.

What is wrong with a standard truncate function ?

What is wrong with a standard truncate function ?

Comment

Comment

Comment

Comment

Comment