typedef FileName not const?
Friends,
along the lines of other similar emails from me of late,
I tried to avoid casting away const when using the FileName
typedef. There are several calls where a (const char *) has to
be cast to (char *) due to FileName being typedef'd as
non-const. But changing the typedef to const doesn't seem to
conflict with any code in the source tree.
Since this may be seen as an external API change, I kept
these changes in their own patch submission, so that it can
be rejected separately if need be.
Mark Dilger
Attachments:
filename.patch.1application/octet-stream; name=filename.patch.1Download
diff --git a/src/backend/replication/logical/origin.c b/src/backend/replication/logical/origin.c
index cc2b513..02bcd85 100644
--- a/src/backend/replication/logical/origin.c
+++ b/src/backend/replication/logical/origin.c
@@ -533,7 +533,7 @@ CheckPointReplicationOrigin(void)
* no other backend can perform this at the same time, we're protected by
* CheckpointLock.
*/
- tmpfd = OpenTransientFile((char *) tmppath,
+ tmpfd = OpenTransientFile(tmppath,
O_CREAT | O_EXCL | O_WRONLY | PG_BINARY,
S_IRUSR | S_IWUSR);
if (tmpfd < 0)
@@ -644,7 +644,7 @@ StartupReplicationOrigin(void)
elog(DEBUG2, "starting up replication origin progress state");
- fd = OpenTransientFile((char *) path, O_RDONLY | PG_BINARY, 0);
+ fd = OpenTransientFile(path, O_RDONLY | PG_BINARY, 0);
/*
* might have had max_replication_slots == 0 last run, or we just brought
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index 03143f1..c2819be 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -597,7 +597,7 @@ durable_rename(const char *oldfile, const char *newfile, int elevel)
if (fsync_fname_ext(oldfile, false, false, elevel) != 0)
return -1;
- fd = OpenTransientFile((char *) newfile, PG_BINARY | O_RDWR, 0);
+ fd = OpenTransientFile(newfile, PG_BINARY | O_RDWR, 0);
if (fd < 0)
{
if (errno != ENOENT)
@@ -2953,7 +2953,7 @@ pre_sync_fname(const char *fname, bool isdir, int elevel)
if (isdir)
return;
- fd = OpenTransientFile((char *) fname, O_RDONLY | PG_BINARY, 0);
+ fd = OpenTransientFile(fname, O_RDONLY | PG_BINARY, 0);
if (fd < 0)
{
@@ -3013,7 +3013,7 @@ fsync_fname_ext(const char *fname, bool isdir, bool ignore_perm, int elevel)
else
flags |= O_RDONLY;
- fd = OpenTransientFile((char *) fname, flags, 0);
+ fd = OpenTransientFile(fname, flags, 0);
/*
* Some OSs don't allow us to open directories at all (Windows returns
diff --git a/src/include/storage/fd.h b/src/include/storage/fd.h
index cbc2224..7a1e33b 100644
--- a/src/include/storage/fd.h
+++ b/src/include/storage/fd.h
@@ -46,7 +46,7 @@
* FileSeek uses the standard UNIX lseek(2) flags.
*/
-typedef char *FileName;
+typedef const char *FileName;
typedef int File;
Hi,
Can we please keep this topic in one thread? Anybody motivated to apply
these isn't going to have an easy time applying things, and everyone
else is just having a harder time sorting through the mails.
On 2016-09-27 17:08:24 -0700, Mark Dilger wrote:
along the lines of other similar emails from me of late,
I tried to avoid casting away const when using the FileName
typedef. There are several calls where a (const char *) has to
be cast to (char *) due to FileName being typedef'd as
non-const. But changing the typedef to const doesn't seem to
conflict with any code in the source tree.
I think the better fix here is to simply remove the typedef. It doesn't
seem to have much of a benefit, and makes using correct types harder as
demonstrated here. We don't even use it internally in fd.c..
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I think the better fix here is to simply remove the typedef. It doesn't
seem to have much of a benefit, and makes using correct types harder as
demonstrated here. We don't even use it internally in fd.c..
Fine by me.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers