Re: (ITS#3839) pedantic and format troubles

[h.b.furuseth@usit.uio.no]

Howard Chu writes:
> I feel this concern is unwarranted for a number of reasons:
>   1) re int vs pointer - any supposed normalization must be reversible.
> We are not converting integers to pointers or vice versa; that is, we do
> not store an integer and later attempt to use it as a pointer. As such,
> if the value we read from this variable is not the same as the value we
> stored, the compiler is broken.

No.  The C standard does not require this, precisely because various
architectures and compilers do so many strange things with pointers.

Maybe you are thinking of the optional integer types (u)intptr_t in C99:
If they are defined, you can convert _from_ a pointer to those types and
back again.  But that doesn't help when you want conver from an int to a
pointer and back.

>   2) there is a large body of code that depends on the
> interchangeability of function pointers and object pointers, thanks to
> APIs like dlsym() and friends.
> http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html
> The fact that this stuff still works tells me no problem exists. When
> these things stop working, then there's a legitimate issue to fix.

I can dig up some real-world examples from comp.std.c if you wish.

There is indeed a large body of code which cannot be used on unusual
architectures, and people with unusual arthitectures learn to live with
that, but I see no need to add to the problem when it's easy to not do
so.

>>  This should either be replaced with 3 fields (where only one is set
>>  per table entry), or the current field could be set to a pointer to a
>>  variable containg the current value.
>
> Feel free to replace this with a union if you wish. I don't see the need
> but also there's no harm if you make this change.

Only the first element in unions can be initialized, IIRC:-(
C99 has support for initializing any element.

>>  Um.  And I guess it's about time to fix the same problem with
>>  ldap_pvt_thread_pool_<setkey/getkey>().  They receive function
>>  pointers sometimes.  I'll create some static variables to hold these
>>  function pointers, and pass them pointers to those variables instead.
>
> Don't bother to preserve the function pointers. The only point in
> those calls is to pass a unique value to distinguish one key from
> another. (...) If you don't like using function pointers here, just
> pass some other unique value instead.

Oh, good.  I'll do that, so I won't forget that it's not a problem next
time I compile with -pedantic:-)

-- 
Hallvard
Don't anthropomorphize computers. They hate that.