Re: a bunch of warnings

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

First of all, thank you for applying all the patches.

On Tue, Aug 28, 2012 at 7:10 PM, Daniel J Sebald <dan...@ie...> wrote:
> On 08/28/2012 10:46 AM, sfeam (Ethan Merritt) wrote:
>>
>> On Monday, 27 August 2012, Daniel J Sebald wrote:
>>>>
>>>>
>> The assignment of octal values to a (char) is not an error no matter
>> what the signedness of (char), so that set of warnings is spurious and
>> I won't change the code in gplt_x11.c or elsewhere.
>
>
> Not sure.  I tried searching the Internet for a reference, but there is so
> much static from people wondering how to print/read hexadecimal values in C
> that I can't find anything.
>
> The problem is that statement implies that hexadecimal values (i.e.,
> representations) are inherently unsigned, which I'm not sure.  For example,
> 0xFE is a valid representation in C compilers.  Is -0xFE?  If so, then 0xFE
> means 254 and -0xFE means -254.  In the execution of the code, the
> assignment of a hexadecimal is just a byte transfer, but how the compiler
> interprets the abstract representation might be something different.

Fortran would sometime give compiler errors, not just warnings, for
trying to store FF into signed 1-byte integer.
The expression
    char a = 0xff;
is (from what I believe) equivalent to
    char a = 255;
and doesn't necessarily mean bitmap representation that should be
stored into a. Here's a counterexample:
    float f = 0xffff;
This is definitely different from doing memcpy from 0x0000ffff from to f.

But on the other hand I agree that one doesn't need to worry about
that code so much.

>>> # ifndef TT2$M_DECCRT3          /* VT300 not defined as of VAXC v2.4 */
>>> or is it the $ is not a valid character
>>
>> The $ is valid (and very common) in VAX/VMS identifiers.
>> This whole section of code is inside #ifdef VMS so non-VAX compilers
>> should not even be looking at it.
>
> Yes, from what I remember, this should be ignored.  The compiler might have
> some internal test order wrong.

I agree with both. I just wanted to reply that it was $ that was
problematic after testing. (I later discovered that I probably sent
the wrong patch. I didn't want to ask for patching this.)

What about the other two trivial patches?

--- a/src/set.c
+++ b/src/set.c
@@ -1420,10 +1420,10 @@ static void
 set_degreesign(char *locale)
 {
 #if defined(HAVE_ICONV) && !(defined WIN32)
-    char degree_utf8[3] = {'\302', '\260', '\0'};
+    const char degree_utf8[3] = {'\302', '\260', '\0'};
     size_t lengthin = 3;
     size_t lengthout = 8;
-    char *in = degree_utf8;
+    const char *in = degree_utf8;
     char *out = degree_sign;
     iconv_t cd;
--- a/term/lua.trm
+++ b/term/lua.trm
@@ -168,7 +168,7 @@ static char last_error_msg[MAX_LINE_LEN+1] = "";
  *  the plot's bounding box
  */
 static int
-LUA_GP_get_boundingbox() {
+LUA_GP_get_boundingbox(lua_State *L) {
   lua_newtable (L);
   lua_pushstring (L, "xleft");
   lua_pushinteger(L, plot_bounds.xleft);

Mojca