On Jan 16, 2004, at 5:19 PM, Philip Martin wrote:
> [Apologies if this appears twice, but I think I lost the first one.]
>
> kfogel@collab.net writes:
>
>> Greg Hudson <ghudson@MIT.EDU> writes:
>>>> * subversion/libsvn_ra_svn/cram.c (compute_digest): Use an unsigned
>>>> char array for the secret. Patch from Philip Martin.
>>>
>>> The bitwise operations performed on secret are all xors, so there
>>> should
>>> be no semantic problem with them being (possibly) signed char. So,
>>> it's
>>> mainly an issue of warnings with pickier compilers. Do people think
>>> that's important enough for a 1.0 pullup?
>>
>> Personally, I'd rather not. We're already accumulating a lot of
>> little proposed changes late in the game. This one doesn't seem that
>> compelling, given that all we're preventing is a compile warning on
>> some platforms.
>
> It's a bit more than that, the report that led to this patch involved
> using the xlc compiler on AIX, and it was a compiler *error*. xlc
> also has the "volatile sig_atomic_t" problem for which I don't have a
> ready solution, other than suggesting that those that encounter it
> delete volatile from the code. I suspect neither problem affects gcc
> on AIX.
Yes, it was an error. Not a warning. Whether it should be so or not
may be debated, but my experience has led me to believe that the xlc
developers are interested and somewhat strict in coding to the
standard.
Here's a tiny test program that invokes the situation in question under
the various language variations available from the compiler:
====== a.c ======
void test(unsigned char uca[10]) { }
int main() {
char sca[10];
test(sca);
return 0;
}
====== ======
% xlc -qlanglvl=extc89 a.c
% xlc -qlanglvl=stdc89 a.c
"a.c", line 7.8: 1506-280 (E) Function argument assignment between
types "unsigned char*" and "char*" is not allowed.
% xlc -qlanglvl=extc99 a.c
% xlc -qlanglvl=stdc99 a.c
"a.c", line 7.8: 1506-280 (E) Function argument assignment between
types "unsigned char*" and "char*" is not allowed.
% xlc -qlanglvl=ansi a.c
"a.c", line 7.8: 1506-280 (E) Function argument assignment between
types "unsigned char*" and "char*" is not allowed.
% xlc -qlanglvl=saal2 a.c
"a.c", line 7.8: 1506-280 (E) Function argument assignment between
types "unsigned char*" and "char*" is not allowed.
% xlc -qlanglvl=saa a.c
"a.c", line 7.8: 1506-280 (E) Function argument assignment between
types "unsigned char*" and "char*" is not allowed.
% xlc -qlanglvl=extended a.c
% xlc -qlanglvl=classic a.c
%
It does appear that the xlc developers believe that when adhering to
the standard, the condition in question may cause an error (though we
don't know whether such a type mismatch MUST be an error or can be an
error at the implementors discretion). I don't have the standard
available at the moment to cite one way or another.
As you can also see, there are compiler options available to make it
more lenient. I chose "xlc" because if I didn't select a compiler,
configure was picking up an older (2.x) gcc compiler. I could and
maybe should have chosen "cc" which is xlc using one of the more
lenient language options.
On Jan 16, 2004, at 11:38 AM, Philip Martin wrote:
> Hmm, again. I think this is a real AIX bug. The C standard is
> explicit, we need to use "volatile sig_atomic_t". I see that gcc's
> fixincl removes volatile from the shadow sys/signal.h, but says that
> only some versions of AIX are affected. We need to be very careful
> not to remove volatile from our code in cases where there is no
> duplicate. Perhaps we could use an autoconf macro. Or we could use
> an integer type directly, but that's no more portable than not using
> volatile. Or we could leave it as it is, but add a comment to the
> code saying that if the error occurs then volatile should be removed.
I'll have do some more investigation into the "volatile sig_atomic_t"
problem. It does respond the same way as the type problem above to
the language options: it's an error with the default strict "xlc"
settings but the more lenient "cc" settings don't cause an error or
even a warning.
If the standard is explicit (if you have a section reference that'd be
great, if not I'll just look for it when I can get my hands on a copy),
then I'll see if I can't feed this back to the xlc developers for them
to fix.
-Travis Pouarz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 17 05:07:49 2004