Warning in huge compile of eval.c

[Tony Mechelynck]

Sorry if this has already been reported, I'm very far behind reading mail due to computer slowness (computer won't stay up unless I set "Fan: silent (but may reduce CPU performance)" in the BIOS, and this makes it *very* slow indeed).

At 7.4.617 (but after updating the Mercurial source up several patchlevels without compiling each of them), in Huge Linux64 build but not in Tiny build, eval.c gets the following warning:

eval.c: In function ‘garbage_collect’:
eval.c:6934:5: warning: ‘did_free’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return did_free;
^

This does not prevent generation of an object and later of an executable.


Best regards,
Tony.

[Ben Fritz]

Thanks, it looks like did_free needs to be initialized to FALSE in case setting references is aborted. It looks like I need to enable some compiler warning options on my Windows build setup at home. :-(

[Michael Jarvis]

I noticed the same warning building with Cygwin, plus a "clobber" warning in main.c.

I'm a little obsessive about "no warnings," so my solution was also to intialize did_free to FALSE, as well as marking the "previous_got_int" variable as volatile in main.c.




main.c: In function ‘main_loop’:
main.c:1054:10: warning: variable ‘previous_got_int’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
int previous_got_int = FALSE; /* "got_int" was TRUE */
^


and

eval.c: In function ‘garbage_collect’:
eval.c:6934:5: warning: ‘did_free’ may be used uninitialized in this function [-Wmaybe-uninitialized]
return did_free;
^

Patch:

diff -r b0a227941705 src/eval.c
--- a/src/eval.c Tue Feb 03 19:13:34 2015 +0100
+++ b/src/eval.c Wed Feb 04 11:50:26 2015 -0600
@@ -6815,7 +6815,7 @@
win_T *wp;
int i;
funccall_T *fc, **pfc;
- int did_free;
+ int did_free = FALSE;
int did_free_funccal = FALSE;
#ifdef FEAT_WINDOWS
tabpage_T *tp;
diff -r b0a227941705 src/main.c
--- a/src/main.c Tue Feb 03 19:13:34 2015 +0100
+++ b/src/main.c Wed Feb 04 11:50:26 2015 -0600
@@ -1051,7 +1051,7 @@
int noexmode; /* TRUE when return on entering Ex mode */
{
oparg_T oa; /* operator arguments */
- int previous_got_int = FALSE; /* "got_int" was TRUE */
+ volatile int previous_got_int = FALSE; /* "got_int" was TRUE */
#ifdef FEAT_CONCEAL
linenr_T conceal_old_cursor_line = 0;
linenr_T conceal_new_cursor_line = 0;

On Wednesday, February 4, 2015 at 6:48:45 AM UTC-6, Tony Mechelynck wrote:

[Bram Moolenaar]

I don't get the warning but I see why it would happen.


--
The CIA drives around in cars with the "Intel inside" logo.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Bram Moolenaar]

Michael Jarvis wrote:

> I noticed the same warning building with Cygwin, plus a "clobber"
> warning in main.c.
>
> I'm a little obsessive about "no warnings," so my solution was also to
> intialize did_free to FALSE, as well as marking the "previous_got_int"
> variable as volatile in main.c.

I also like to keep the build warning-free. I had not seen that
clobbered warning though.

> main.c: In function ‘main_loop’:
> main.c:1054:10: warning: variable ‘previous_got_int’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered]
> int previous_got_int = FALSE; /* "got_int" was TRUE */
> ^
>
> and
>
> eval.c: In function ‘garbage_collect’:
> eval.c:6934:5: warning: ‘did_free’ may be used uninitialized in this function [-Wmaybe-uninitialized]
> return did_free;
> ^
>
> Patch:

Thanks!


--
If Microsoft would build a car...
... The airbag system would ask "are you SURE?" before deploying.

[Michael Jarvis]

I'm using gcc 4.9.2 and "-O2 -Wall -Wextra -pipe -std=gnu99 -DNDEBUG" as my compiler flags, and got the same warning on both 64-bit Cygwin and 64-bit Ubuntu Linux. 

It's possible that older versions of GCC are more forgiving. :-)

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/LYkqB17eD44/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Michael Jarvis

McKinney, TX USA

http://about.me/michael.a.jarvis

[Mike Williams]

On 04/02/2015 16:19, Ben Fritz wrote:
>It looks like I need to enable some compiler warning options on my Windows build setup at home. :-(

Just turned up MSVC build from W3 to W4. I had to turn off a bunch of
warnings through vim.h for the usual C coding slackness, but doesn't
catch them all since not all files include vim.h. See attached diff for
details.

The build with VC11 throws up a pile more potentially un-intialised
before use variables, amongst a few other C hacks used in VIM that may
or may not be important to address. I doubt VIM will ever default to W4
when building, but it is good to go through the exercise once in a while
to clean the worst things up, and then fall back to W3.

There is enough there to come a few people busy for a while so just dive
into issues you see.

HTH - TTFN

Mike
--
My other computer's a... er... well, it's a piece of junk too.

[Bram Moolenaar]

I guess that compilers throw more warnings to avoid mistakes in C
programs, even though the code is OK. I can include that patch, but I
don't think we can avoid some warnings without taking a penalty in
performance.


--
Press any key to continue, press any other key to quit.

[Mike Williams]

On 07/02/2015 13:38, Bram Moolenaar wrote:
>
> Mike Williams wrote:
>
>> On 04/02/2015 16:19, Ben Fritz wrote:
>>> It looks like I need to enable some compiler warning options on my
>>> Windows build setup at home. :-(
>>
>> Just turned up MSVC build from W3 to W4. I had to turn off a bunch of
>> warnings through vim.h for the usual C coding slackness, but doesn't
>> catch them all since not all files include vim.h. See attached diff for
>> details.
>>
>> The build with VC11 throws up a pile more potentially un-intialised
>> before use variables, amongst a few other C hacks used in VIM that may
>> or may not be important to address. I doubt VIM will ever default to W4
>> when building, but it is good to go through the exercise once in a while
>> to clean the worst things up, and then fall back to W3.
>>
>> There is enough there to come a few people busy for a while so just dive
>> into issues you see.
>
> I guess that compilers throw more warnings to avoid mistakes in C
> programs, even though the code is OK. I can include that patch, but I
> don't think we can avoid some warnings without taking a penalty in
> performance.

I have looked through the potentially uninitialised variables reported
for my usual Windows builds and they all look benign. It seems the
compiler is just spotting branches in the code where the variable is not
assigned to but is used later. A simplistic example is:

int foo, bar;

if (a)
foo = bar;
else
bar = 1;

if (a)
bar += 2*foo;

This generates a warning since it doesn't spot that foo is initialised
and referenced under the same condition. There are various approaches
that can be made to remove the warnings from simple initialisation
through code refactoring.

The other common warning is for function and data pointer conversions.
In standard C a function pointer is not compatible with void * but
typically doesn't cause a problem, so not worth worrying about.

Based on this I don't see any point in using W4 with Visual C, you just
get a pile of warnings you wont ever clear up.

There may be more used in looking at the output from ANALYZE=yes with
VC. More code reading ...

Mike
--
My computer's sick and I think my modem is a carrier.

[James McCoy]

On Sat, Feb 07, 2015 at 03:42:50PM +0000, Mike Williams wrote:
> I have looked through the potentially uninitialised variables reported for
> my usual Windows builds and they all look benign. It seems the compiler is
> just spotting branches in the code where the variable is not assigned to but
> is used later. A simplistic example is:
>
> int foo, bar;
>
> if (a)
> foo = bar;
> else
> bar = 1;
>
> if (a)
> bar += 2*foo;
>
> This generates a warning since it doesn't spot that foo is initialised and
> referenced under the same condition.

Well, bar when a is true, then bar is uninitialized and when a is false,
foo is uninitialized. Maybe that wasn't the example you meant.

--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@debian.org>

[Mike Williams]

On 07/02/2015 18:00, James McCoy wrote:
> On Sat, Feb 07, 2015 at 03:42:50PM +0000, Mike Williams wrote:
>> I have looked through the potentially uninitialised variables reported for
>> my usual Windows builds and they all look benign. It seems the compiler is
>> just spotting branches in the code where the variable is not assigned to but
>> is used later. A simplistic example is:
>>
>> int foo, bar;
>>
>> if (a)
>> foo = bar;
>> else
>> bar = 1;
>>
>> if (a)
>> bar += 2*foo;
>>
>> This generates a warning since it doesn't spot that foo is initialised and
>> referenced under the same condition.
>
> Well, bar when a is true, then bar is uninitialized and when a is false,
> foo is uninitialized. Maybe that wasn't the example you meant.

Email in haste, bugs reported at leisure ;-) Yep, I meant to initialise
bar first. I'll get my coat.

Mike
--
Just when you thought you were winning the rat race, along comes a
faster rat.