Closed nars1 closed 6 years ago
@ksbhaskar : Yes 1E9 is less error prone. Now fixed there and other similar places in the same module.
@estess : I am done addressing all review comments. There are 4 comments which I expect you will own since you were the author. Let me know if I missed any comments.
On 03/25/2018 03:36 PM, Steven E. Estes wrote:
@estess commented on this pull request.
In sr_unix/gtm_unique_file_util.c https://github.com/YottaDB/YottaDB/pull/190#discussion_r176951341:
boolean_t status;
gd_id_ptr_t tmp_fileid;
if (!filename) return FALSE; assert(fileid && !*fileid); tmp_fileid = (gd_id_ptr_t)malloc(SIZEOF(gd_id));
- status = (SS_NORMAL == filename_to_id(tmp_fileid, filename->address));
- *fileid = (xc_fileid_ptr_t)tmp_fileid;
- return status;
- actstatus = filename_to_id(tmp_fileid, filename->address);
- status = (SS_NORMAL == actstatus);
- if (status)
- *fileid = (ydb_fileid_ptr_t)tmp_fileid;
- else
- { / There was an error /
- free(tmp_fileid);
- *fileid = NULL;
- }
- return status ? YDB_OK : actstatus;
Here is the description of ydb_file_name_to_id() which is a wrapper for gtm_filename_to_id():
ydb_file_name_to_id() returns YDB_OK /or an error return code./
We can not do that hilighted part because the original version of gtm_filename_to_id() does not do return codes. It returns 1 if it was successful and 0 if it wasn't but does not return any information. Any attempt to rework this routine to return error information is equivalent to returning "TRUE" when it isn't. I need to revert this routine and we can only return success/failure. The spec needs to change for ydb_file_name_to_id() because of this.
[KSB] How about if we define a constant YDB_NOTOK and have the function return YDB_OK or YDB_NOTOK?
– Bhaskar
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/YottaDB/YottaDB/pull/190#discussion_r176951341, or mute the thread https://github.com/notifications/unsubscribe-auth/AcfILQd7RBUNOkPbT3qducTw8QxvvAjdks5th_HFgaJpZM4S5F4U.
-- YottaDB - Rock solid. Lightning fast. Secure. Pick any three.
On 03/24/2018 11:26 PM, Steven E. Estes wrote:
[KSB] It seems to me that defining the constant as 1E9 is less prone than 1000000000 to the possibility of an inadvertent extra or missing zero.
– Bhaskar
-- YottaDB - Rock solid. Lightning fast. Secure. Pick any three.