This is the mail archive of the gcc-patches@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: Preliminary mainline patch for __attribute__ ((sentinel))


 > > 4. Leave the warning as is, and fix all calls to concat in gcc
 > >    (other source code using sentinels will still have the problem.)
 > 
 > This is my preferred approach, and I will explain why.
 > 
 > ISO C doesn't guarantee that NULL be a pointer. It can be any kind of
 > integral zero instead (we know that C++ is different).
 > 
 > Allowing people to keep their NULL being 0 (or 0L, actually, for
 > OpenBSD) allows us to be very picky about portable code: our sentinel
 > does insist that you explicitly write a null pointer for code
 > termination, and it isn't satisfied by our definition of NULL. Mind
 > you, our NULL is specifically 0L to make sure the code still works: 0L
 > is exactly the size of a pointer on all architectures that OpenBSD
 > does support.
 > 
 > So, we get working code, until we fix the warning, and then we get
 > portable code.

Portable to where exactly?  I think it's worth asking, can you name
one single platform where NULL is not suitably defined to pass in lieu
of a pointer through a variadic function call?

I think it's also relevant but not pivotal whether is GCC supported on
that platform.

Unless you can name one, I think #4 is busy-work with no realizable
benefit.  (Note you'll have to change all users of libiberty like GDB
and BFD, not just GCC.  I.e. anywhere we have a call site for concat
et al.)

If you really think it's useful, be my guest.  I think your efforts
are better spent on option #2 from my previous message.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu


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