Re: New VSI blog post

On 7/30/2024 7:59 PM, Arne Vajhøj wrote:

On 7/30/2024 8:25 AM, Simon Clubley wrote:

On 2024-07-29, John Reagan <johnrreagan@earthlink.net> wrote:

Other
than bugs in the compilers and OS, the most common issue I've seen is a
mismatch of 32/64 bit variables.  I've seen 20 or so instance of code
that is doing a 64-bit write into a 32-bit variable.

[snip]

It mostly has been in BLISS and C code.

>
I don't know enough about BLISS to make a judgement about how bad the
code that does this is,

 I don't think Bliss is the right language for 100% type safe code.
 :-)
 

                        but I would be very interested to see the C code
that makes this possible.
>
Without an obviously incorrect explicit type conversion (which is a serious
bug in the user's C code), I am not seeing how this is possible under C
as the compiler should generate the appropriate size-conversion code
automatically if you assign from a 64-bit variable into a 32-bit variable.

 I have no idea what examples John is seeing, but it is not that
hard to come up with examples.
 Ignoring warnings:
 $ type warns.h
#include <stdint.h>
 void something(int64_t *v);
$ type warns.c
#include <stdint.h>
 #include "warns.h"
 void something(int64_t *v)
{
     *v = -1;
}
 $ type warnm.c
#include <stdio.h>
#include <stdint.h>
 #include "warns.h"
 int main()
{
     int32_t v[3] = { 0, 0, 0 };
     something(&v[1]);
     printf("%ld %ld %ld\n", v[0], v[1], v[2]);
     return 0;
}
 $ cc warns
$ cc warnm
      something(&v[1]);
..............^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer value "&v[1]" is "int", which is not compatible with "long
long".
at line number 9 in file DKA0:[arne.bits]warnm.c;1
$ link/exe=warn warnm + warns
%ILINK-W-COMPWARN, compilation warnings
         module: WARNM
         file: DKA0:[arne.bits]warnm.OBJ;2
$ run warn
0 -1 -1
 Having an inconsistent declaration and forget to
include .h in implementing .c file:
 $ type nowarns.h
#include <stdint.h>
 void something(int32_t *v);
$ type nowarns.c
#include <stdint.h>
 //#include "nowarns.h"
 void something(int64_t *v)
{
     *v = -1;
}
 $ type nowarnm.c
#include <stdio.h>
#include <stdint.h>
 #include "nowarns.h"
 int main()
{
     int32_t v[3] = { 0, 0, 0 };
     something(&v[1]);
     printf("%ld %ld %ld\n", v[0], v[1], v[2]);
     return 0;
}
 $ cc nowarns
$ cc nowarnm
$ link/exe=nowarn nowarnm + nowarns
$ run nowarn
0 -1 -1
 Having an inconsistency and use old style function
declaration without arguments:
 $ type badolds.h
void something();
$ type badolds.c
#include <stdint.h>
 #include "badolds.h"
 void something(int64_t *v)
{
     *v = -1;
}
 $ type badoldm.c
#include <stdio.h>
#include <stdint.h>
 #include "badolds.h"
 int main()
{
     int32_t v[3] = { 0, 0, 0 };
     something(&v[1]);
     printf("%ld %ld %ld\n", v[0], v[1], v[2]);
     return 0;
}
 $ cc badolds
$ cc badoldm
$ link/exe=badold badoldm + badolds
$ run badold
0 -1 -1
 Mixing VMS C and Clang C without consideration:
 $ type trickys.h
void something(long *v);
$ type trickys.c
#include "trickys.h"
 void something(long *v)
{
     *v = -1;
}
 $ type trickym.c
#include <stdio.h>
 #include "trickys.h"
 int main()
{
     long v[3] = { 0, 0, 0 };
     something(&v[1]);
     printf("%ld %ld %ld\n", v[0], v[1], v[2]);
     return 0;
}
$ clang trickys.c
$ cc/name=as_is trickym
$ link/exe=tricky trickym + trickys
$ run tricky
0 -1 -1
 All of the above is bad in some ways.
 Dont't ignore warnings, always include .h in implementing
.c, never use old style declarations without arguments and
don't mix VMS C and Clang C.
 But bad things has been seen out in the big world.
 Arne
    

And don't forget that /STANDARD=VAXC will cover up a ton of bad code