By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,479 Members | 1,749 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,479 IT Pros & Developers. It's quick & easy.

What is wrong with a standard truncate function ?

P: n/a
[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.

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.

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.

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.

Thank you,
Timothy Madden
Nov 10 '08 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On Mon, 10 Nov 2008 03:50:34 +0200, Timothy Madden
<te**********@gmail.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.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html
Nov 10 '08 #2

P: n/a
On Nov 10, 3:50 am, Timothy Madden <terminato...@gmail.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.
Nov 10 '08 #3

P: n/a
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.
Nov 10 '08 #4

P: n/a
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 <iostreamlibrary and the
behavior of the <stdio.hlibrary.

Both committees are committed to, among other priorities, avoiding
gratuitous incompatibilities 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.
Nov 11 '08 #5

This discussion thread is closed

Replies have been disabled for this discussion.