[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mysql-developer
Subject:    tempnam() -> mkstemp()
From:       Michael Widenius <monty () mysql ! com>
Date:       2000-09-27 1:24:26
[Download RAW message or body]


Hi!

>>>>> "John" == John Jones <jjones@cs.ucr.edu> writes:

John> Hi,
John> We have put together a patch for MySQL 3.23.24 that eliminates all
John> warnings when compiling with `gcc' with the `-Wall' option.

Great;  We have tried to eliminate all normal warnings, but haven't
had time to eliminate everything...

John> This includes
John> changes to the implementation of my_tempnam() to attempt to use mkstemp()
John> rather then tempnam() if it is available.  This is done by immediately
John> closing the open file descriptor returned by mkstemp() and returning the
John> file name just as tempnam() would.  The existence of a zero byte file of
John> this name provides the required locking around the file name to prevent
John> reusage.  This places two requirements on the rest of the code...

John> 1) Any opening of a temporary file whose name was provided by my_tempnam() 
John>    must not use the O_EXCL and O_CREAT flags to prevent the opening of an
John>    existing file.

John> 2) Any call to my_tempnam() will produce a file may (if mkstemp() exists) 
John>    produce a file in the filesystem.  Thus the caller must unlink the file
John>    even if they never explicitly open it.  This required a change to the 
John>    IO Cache to delay calling my_tempnam() until immediately before the 
John>    opening of the disk cache.

John> We believe that these changes implement item 13 on the MySQL TODO list.

Yes.

John> Other changes include commenting out unused variables, fixing
John> initialization ordering of class instances, parenthisizing truth value
John> tests, and several other code cleanups.  We believe that while these
John> changes are not crucial they do improve the quality of the code and make
John> future changes easier to debug.  We suggest that all future modifications
John> attempt to keep the code warning free.  

I agree;  We try to avoid warnings.

I will add your patches to MYSQL 3.23.26 (I can't do this to 3.23.25
anymore as I am just making a binary distribution of this)

John> The patch is available at...

John> ftp://ftp.cs.ucr.edu/pub/villarre/patches/mysql/patch-3.23.24-beta

John> Please feel free to include these modifications to whatever degree you
John> consider appropriate and make modifications as you see fit.

John> Thanks,

John> John Jones <jjones@cs.ucr.edu>
John> Jason Villarreal <villarre@cs.ucr.edu> 

Thanks!

I did take a quick look at your patch, and there is only one thing
I don't want to apply:

This is initializing of variables for which the compiler gives a wrong
warning like the following:

+  HASH_INFO *empty,*gpos = NULL,*gpos2 = NULL,*pos;
   DBUG_ENTER("hp_write_key");
 
   LINT_INIT(gpos); LINT_INIT(gpos2);

The reason is that I don't think we should make the code slower just
because the compiler gives you a wrong warning.

It's for variables like the above we have provided the LINT_INIT()
macro.  This just sets the variable to 0 if you have compiled MySQL
with -DFORCE_INIT_OF_VARS

If you don't want to have a warning for these kind of variables (that
we are 100 % sure will not be used uninitialized), just add the above
option to your CFLAGS and CXXFLAGS variable when configuring MySQL.

Regards,
Monty

---------------------------------------------------------------------
Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
posting. To request this thread, e-mail developer-thread1652@lists.mysql.com

To unsubscribe, send a message to the address shown in the
List-Unsubscribe header of this message. If you cannot see it,
e-mail developer-unsubscribe@lists.mysql.com instead.

[prev in list] [next in list] [prev in thread] [next in thread]