API changes involving C99 integer types

[Joel Sherrill]

Till Straumann wrote:
> Between 4.7 and what is to become 4.9 a few prototypes
> (e.g., in <rtems/pci.h>, <libcpu/io.h> [powerpc]) have
> been converted from
>
> unsigned char  -> uint8_t
> unsigned short -> uint16_t
> unsigned int   -> uint32_t
>   
And these changes are correct in that they
correctly reflect the size of the data being
accessed.  The native types are not always
the sizes that were assumed.

The code was broken for any target architecture
that did not agree with those assumptions.

> While these changes superficially may make sense they do
> introduce a major maintenance nightmare:
>
>   
These changes have been slowly occurring for
a long time now.  The pci.h change happened
over two years ago and was included in 4.8.

I wondered how much discussion on C99 types
there has been on the mailing list.  I know the
Steering Committee has discussed API changes.
The first post google found was in a thread that
you participated in December 2006.

We started submitting patches to newlib for C99
back in 2001. 

I even included a discussion of this in the EPICS
presentation I did last November.  Thanks to Google
for reminding me of this. :)

This has been on the table and horizon
a very long time.

Where is the io.h file you are referring to?
The one I see in libcpu/powerpc only has 4 revisions
since it was added in 2001 and none of them are
type related.

The io.h for the Classic API IO Manager was
changed in 2004.

I am sure there was discussion on the change
since 4.6 was the last release branch to not
use these in some way.  The Classic API was
changed in 4.7 and they have just been used
more and more.

It has been going on so long that it is a topic
I always mention in the class.
> All of our software which is affected by these changes
> now produces lots of 'pointer incompatibility' and
> 'wrong printf format' and other warnings.
>   
printf warnings usually indicate that you
should be using inttypes.h.  In nearly 20 years of
working on RTEMS, I am convinced there is
no portable cross-target way to reliably remove
them EXCEPT using inttypes.h.

Without seeing the code, I can't say much about the
pointer warnings. 
> Unfortunately, it is not possible to just migrate
> all our stuff to the new API since it must build/work
> with several RTEMS versions.
>   
I am guessing based upon the file you mentioned
(pci.h) that you guys have never touched 4.8.0. 

4.7.0 came out in March 2007
4.8.0 came out in February 2008

How long has it been since this application code
was updated?
> I would suggest to more carefully discuss and test
> any API changes (even if they seem trivial) ahead
> of committing them.
>
>   
These have been discussed at various times.

The entire point of more frequent release branches
is to freeze the API at more points and to allow for
changes and improvements.

I appreciate the pain of the differences.  I maintain
the class material that can be taught to any user using
4.5 and up and highlight what has changed. It is important
so people know what to expect when updating.  But change
has to happen.  C99 is nine years old. 

> T.
>
>   


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985