This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: signed vs unsigned pointer warning


> -----Original Message-----
> From: Joe Buck [mailto:Joe.Buck@synopsys.COM] 
> Sent: 23 September 2004 17:11

> On Thu, Sep 23, 2004 at 12:35:22PM +0100, Dave Korn wrote:
> > > "Dave Korn" writes:
> > > 
> > > > Which I don't think you can, since you can't store 
> negative numbers
> > > > in an unsigned type. 
> > > 
> > > Actually you can, due to the modulo behaviour of unsigned 
> integers.
> > > 
> > > Andreas.
> > 
> >   Well, yes, it is physically possible, but it's a kind of 
> type-punning, it
> > defies the aliasing rules, and we get into some very deeply
> > language-lawyerly issues here, but it's not a valid 
> representation IIUIC and
> > therefore invokes undefined behaviour in many circumstances.
> 
> The C aliasing rules specifically bless accessing ints as 
> unsigneds, and,
> more generally, punning accesses between any type and the 
> unsigned version
> of that type.


  Ya learn something new every day :)

  Actually, come to think of it, I stumbled across that myself just a few
weeks back, when I was trying to work round the _restrict_ bug (in a block
of code that was copying some memory to some registers) by defining one
pointer as an int and one pointer as a long (both actually being 32 bit
ints), and I had tried to use the signed/unsigned distinction to get it to
work, but it didn't until I actually used different underlying types.

  Anyway, it's all wandering a bit far enough from the original point now,
which is that a warning would be a good idea, and I'm convinced enough by
that line of argument without any reference to the finer details of buggy
ctype implementations anyway!

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]