On Fri, Apr 7, 2017 at 10:05 AM, Joel Sherrill <j...@rtems.org> wrote: > > > On Fri, Apr 7, 2017 at 4:15 AM, Cillian O'Donnell <cpodonne...@gmail.com> > wrote: >> >> Great! That looks like a cleaner, more standardized solution. I was just >> hacking away until the warnings stopped. So can I go ahead and #include >> <inttypes.h> or should I wait until <rtems/inttypes.h> is defined before >> doing any more? Does this work for printk() too? > > > First the easy answer. printk() supports a subset of printf() formats. So > as long as it is a supported printf format, then yes. But I just looked for > printk() documentation and I don't see any. The code is in > cpukit/libcsupport/src/vprintk.c for a double check. It is supposed to > support everything required by any test. > > If a file only uses C99 standard PRI constants, then use <inttypes.h> > > If a file needs the extra ones being collected into <rtems/inttypes.h>, > then it should include that. > > No need to introduce an unneeded dependency. > > Funny, how this simple set of warnings has rippled. It also makes me > want to file a ticket for printk() documentation and adding code style > rules about <inttypes.h>. > Please do.
Also we should consider converting our code style into a doc instead of wiki page. > --joel > > >> >> >> Thanks Joel. >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel