Re: a bunch of warnings

[Mojca M. <moj...@gm...>]

On Tue, Aug 28, 2012 at 8:52 AM, Daniel J Sebald wrote:
> On 08/27/2012 11:21 PM, Ethan Merritt wrote:
>>
>> On Monday, 27 August 2012, Mojca Miklavec wrote:
>>>
>>> Hello,
>>>
>>> I'm sending a bunch of compiler warnings for gnuplot from two
>>> different compilers. The first batch comes from Sparc Solaris, the
>>> second one from clang on Mac OS X 10.7 (most warnings are recent, in
>>> particular those about plot2d; the last three are older).
>>
>>
>> Thanks.
>>
>> I'm using clang also, but it hasn't given me these particular warnings.
>> Almost all look like either false positives or utter trivia.
>> The emf.trm declarations should be fixed, however.
>> The lua.trm and wxt_gui.cpp ones I do not understand.
>>
>> "datafile.c", line 448: warning: syntax error:  empty declaration
>> EAM: True, but so what?
>
>
> Usually semincolons aren't placed after function definitions.  Is that what
> it's complaining about?
>
> static void auto_filetype_function(void){};     /* Just a placeholder for
> auto    */

Yes. Removing the semicolon got rid of the warning.

>> "datafile.c", line 642: warning: statement not reached
>> EAM: True, and it's even commented as such in the source
>
>
> I wonder why the "return NULL;" was left in?  The typical error would be
> "missing return", but I can't recall any C compiler complaining about the
> construct whereby this function ends with the infinite loop rather than
> "return".  The fact it was left in with that comment makes me suspect
> someone came across a compiler where "missing return" was a problem.  Odd.
> If there are any other similar constructs in gnuplot code...  in fact, I do
> see several routines which end with an infinite loop.  Since those
> apparently aren't causing problems, I'd say remove this:
>
>     /* NOTREACHED */
>     return NULL;
>
> so that the routine is consistent with the rest.

That also solved it.

>> "set.c", line 1444: warning: argument #2 is incompatible with prototype:
>>          prototype: pointer to pointer to const char :
>> "/opt/csw/include/iconv.h", line 83
>>          argument : pointer to pointer to char
>>
>> EAM: Feh. Ignore all warnings about "const char"
>>       That's not even our code - that's a system header.
>
>
> Well, just changing
>
>     char degree_utf8[3] = {'\302', '\260', '\0'};
>     char *in = degree_utf8;
>
> to
>
>     const char degree_utf8[3] = {'\302', '\260', '\0'};
>     const char *in = degree_utf8;
>
> will get rid of the warning.  Small change.  The header is simply indicating
> that whatever the input is, it won't be altered by the library routine.
> (They probably use the same headers to compile the library itself so the
> "const" enforces that rule.)

Thanks. That change helped.

>> "../term/emf.trm", line 344: warning: initializer does not fit or is
>> out of range: -5
>>
>> EAM: This one is a true hit, however.
>>       It looks to me that a dozen or so of the declarations at the
>>       top of emf.trm are marked "unsigned" for no good reason.
>>       But why only complain about this one and not 10 others?
>
>
> The others look to be set to valid unsigned numbers, e.g., 0, 1, FALSE,
> TRUE, 0x2222, EMF_COLORS (which is 15), etc.  LT_UNDEFINED (which is -5) is
> the only signed value.

Thanks. (But I leave it up to others to figure out which ones need a change.)

>> "../term/hpgl.trm", line 2580: warning: statement not reached
>> EAM: OK
>
>         break;
>         return;
>
> Probably lose points for that one on an exam.

Why is return needed here at all? (Removing it got rid of warning.)

>> "../term/lua.trm", line 469: warning: initialization type mismatch
>> EAM: I have absoluately no idea what this one is about.
>
>
> The definition of LUA_GP_get_boundingbox is incomplete, i.e., missing
> argument definition:
>
> static int
> LUA_GP_get_boundingbox() {
>
> should be
>
> static int
> LUA_GP_get_boundingbox(lua_State *L) {

This helped. Thank you.

>> "term.c", line 2159: warning: tokens ignored at end of directive line
>> EAM: ignore it
>
> What's wrong with this line?  Is it that the comment appears within the
> preprocessor definitions?
>
> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
>
> or is it the $ is not a valid character so that this is really

It seems so. Removing comments didn't have any influence, while
replacing $ by _ got rid of the warning. But then, this was only
diagnosis, not a valid solution.

>> "gplt_x11.c", line 634: warning: initializer does not fit or is out of
>> range: 129
>> "gplt_x11.c", line 635: warning: initializer does not fit or is out of
>> range: 136
>> "gplt_x11.c", line 636: warning: initializer does not fit or is out of
>> range: 255
>> "gplt_x11.c", line 637: warning: initializer does not fit or is out of
>> range: 128
>> "gplt_x11.c", line 638: warning: initializer does not fit or is out of
>> range: 128
>> "gplt_x11.c", line 639: warning: initializer does not fit or is out of
>> range: 136
>> "gplt_x11.c", line 640: warning: initializer does not fit or is out of
>> range: 136
>> EAM: These make no sense to me.
>
>
> You might have to declare stipple_pattern_bits as unsigned:
>
> static const unsigned char stipple_pattern_bits[stipple_pattern_num][8] = {
>
> vs.
>
> static const char stipple_pattern_bits[stipple_pattern_num][8] = {
>
> because some of those bit fields as hexadecimal definitons are greater than
> the maximum signed char value.  (Man, this compiler is going after
> everything!)

Exactly. I tried that (the only one I tried to debug myself
yesterday). But then the following complained:

    XCreateBitmapFromData(dpy, plot->pixmap, stipple_pattern_bits[i],
        stipple_pattern_width, stipple_pattern_height);

because XCreateBitmapFromData wants to use signed char as the 3rd
argument. In this particular case I don't really understand why
signed. (It would probably need some casting, but I'm not sure how.)

Thank you for all the diagnosis.

Oh, and of course I forgot another one:
    "fit.c", line 574: warning: statement not reached
(Was it other dumber compiler that complained if return was missing?)

I'm attaching the summary of changes which only left those gplt_x11.c
warnings (I'm not sure how to properly cast) in and the complaint
about $. emf might need a closer look of course. (The bool changes
were needed since I'm unable to compile gnuplot otherwise.)

Mojca