Philip Guenther <guent...@gmail.com> writes:
...
>>> file a.c contains "char foo" on the code.
>>> and b.c contains "int foo" on the code.
...
>
> It violates a constraint of the C standard for two translation units
> of a program to have different tentative definitions for a single
> (necessarily external) identifier. Therefore, the behavior of your
> program is NOT DEFINED BY THE C STANDARD.
...
> You were doing something that isn't guaranteed by the standard and
> whose behavior isn't guaranteed by OpenBSD. If you ever upgrade your
> system or try to compile this software on other systems, it may behave
> differently WITH NO WARNING.
>
> Given that, writing such code seems...unwise. I certainly recommend
> against doing so.
>
Funny, this question coming now when just last night I was struggling
with whether mixing of int and u_int8_t in sys/dev/pci/pccbb.c and in
sys/dev/ic/i82365.c could be causing the regression from 4.5 to 4.6
where my wi wireless card stopped working on my old latitude. I noticed
an ansification of functions in pccbb.c happening (revision 164) that
claimed to make no binary change but actually changed the signature of
pccbb_pcmcia_write from
void
pccbb_pcmcia_write(ph, reg, val)
struct pcic_handle *ph;
int reg;
u_int8_t val;
... to ...
void
pccbb_pcmcia_write(struct pcic_handle *ph, int reg, int val)
Curiously, there was a fn prototype in the 4.5 version that also had val
be int, conflicting with the definition, which makes it almost like his
case, except it was all within one file.
The timing of this change fit perfectly with my problem. And yet my
attempt to correct it made no difference to what I'm seeing, and I
haven't yet worked out in my head just how a conversion between int and
unsigned char or vice versa could cause a real problem here. But I have
to admit I have great difficulty trying to understand what this code is
doing exactly.
And even in 4.5, where my card worked, there was still lots of mixing of
int and u_int8_t. st_pcic_write seemed to suffer the same inconsistency
in types for the data read or written with st_pcic_read and
st_pcic_write as did pccbb_pcmcia_read and pccbb_pcmcia_write. Many
functions in i82365.c have a local reg variable that's int and use it to
hold the return of the _read and then pass to the data of the _write.
When I changed these to u_int8_t it didn't seem to make a difference,
though it's likely I missed something.
--
Mike Small
sma...@panix.com
