Post by Simon ClubleyPost by John ReaganOther
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]
Post by John ReaganIt 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.
:-)
Post by Simon Clubleybut 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