Re: Deprecated POSIX functions ?
On Sun, 29 Aug 2010 20:11:40 -0700, Geoff wrote:
On Mon, 30 Aug 2010 01:18:43 +0300, Timothy Madden
<terminatorul@gmail.com> wrote:
On 30.08.2010 00:44, Geoff wrote:
On Mon, 30 Aug 2010 00:29:48 +0300, Timothy
Madden<terminatorul@gmail.com> wrote:
On 29.08.2010 22:04, Geoff wrote:
On Sun, 29 Aug 2010 13:36:37 +0300, Timothy
Madden<terminatorul@gmail.com> wrote:
First, symbol names starting with an underscore are reserved for
use by the C/C++ implementation, so users should use the standard
ones, without the underscores !
The DEFINITION of names starting with underscore are reserved to the
implementation and user programs should not DEFINE them but it is
permissible to use them if the implementation provides them.
You can use them, but then your code or application will be dependent
on that particular implementation (you lose portability).
No, you lose portability to POSIX compliant implementations.
Yes, that is what I said: I lose portability.
It's a warning. You don't actually lose anything, your application still
compiles but the function names are deprecated. Microsoft is doing you
the great favor of warning you about the coming changes before it breaks
your code.
Does Microsoft actually intends to /remove/ the POSIX names, for this
pretense that it contravines to ISO C ?
And, as an extra bonus, I now depend on the one C++ implementation that
provides all the names with the underscores.
Why do you think it's only one compiler? Any C99-compliant or modern C++
compiler that pretends to comply with the new standard specification
will have to change. Have you compiled your coded under the latest GCC
with -Wall?
I have now, with gcc and with g++ 4.5.0 on Slackware (latest on gcc web
site is 4.5.1), and surprise: no warning with either --pedantic, -Wall,
or both (below is my C++ code).
So why should I use the non-portable names ? How are they better ?
Because the standard says so? The leading underscore denotes
implementation defined functionality that extends beyond the standard
and this functionality is also likely to be system dependent as well. A
program that depends on this extended functionality must be prepared to
change as it is ported.
Where does the ISO C or C++ standard says so ? Search the standard, you
will find nothing about deprecating POSIX functions.
And functionality is not system dependent, it is a portable operating
systems interface, and it is not implementation-defined because it is not
defined by the C implementation, it is defined by POSIX and provided by
the POSIX implementation (the operating system).
Thank you,
Timothy Madden
Here is the code sample:
/**
* Uses POSIX stat function on the file name argument
*/
// POSIX/XOpen feature test macros
#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE 600
#include <cstdlib>
#include <cerrno>
#include <cstring>
#include <ctime>
#include <cstdio>
#include <stdexcept>
#include <iostream>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
using namespace std;
int main(int argc, char const *argv[])
try
{
int iRetCode = EXIT_FAILURE;
if (argc != 2)
{
cerr << "Invokes stat (or other) funtion(s) on ";
cerr << "the given argument.\n";
cerr << "Usage:\n";
cerr << "\t" << argv[0] << " filename" << endl;
cerr << endl;
}
else
{
struct stat file_stat;
int iStatCode = stat(argv[1], &file_stat);
if (iStatCode)
{
cerr << "Application error." << endl;
cerr << strerror(errno) << endl;
}
else
{
struct tm file_time;
char szTimestamp[255];
file_time = *localtime(&file_stat.st_mtime);
strftime
(
szTimestamp,
sizeof szTimestamp / sizeof szTimestamp[0],
"%a, %Y-%m-%d %H:%M:%S",
&file_time
);
cout << argv[1] << "\t" << szTimestamp << "\t";
cout << file_stat.st_size << " bytes\n";
FILE *tmp_file = tmpfile();
if (tmp_file)
{
int tmp_fd = fileno(tmp_file);
if (tmp_fd < 0)
{
cerr << "Failed to open temporary file descriptor.\n";
cerr << strerror(errno) << endl;
}
else
cout << "Temporary file descriptor: " << tmp_fd << ".\n";
fclose(tmp_file);
tmp_file = NULL;
iRetCode = EXIT_SUCCESS;
}
else
cerr << "Failed to open temporary file.\n";
}
}
return iRetCode;
}
catch (exception const &ex)
{
cerr << "Application error.\n";
cerr << ex.what() << endl;
return EXIT_FAILURE;
}
catch (...)
{
cerr << "Application error.\n";
return EXIT_FAILURE;
}