yamt commented on code in PR #15320:
URL: https://github.com/apache/nuttx/pull/15320#discussion_r1896557246


##########
libs/libc/stdio/lib_libvsprintf.c:
##########
@@ -911,6 +915,11 @@ static int vsprintf_internal(FAR struct lib_outstream_s 
*stream,
           size = 1;
           goto str_lpad;
 
+        case 'm': /* Print error message (%m) */
+          pnt = strerror(saved_errno);
+          size = strlen(pnt); /* Adjusting the size is not supported by %m */
+          goto str_lpad;
+

Review Comment:
   > I'm not quite sure what process to follow. What it's clear is using those 
`printf` statements within the kernel is unsafe, and should be avoided. 
Literally, the Linux kernel has its own internal implementations of 
`vsprintf.c` which are considered safe.
   > 
   > `syslog`, `printf`, and friends are intended to be used from user space. 
If NuttX is mixing things, it's a problem because changes focusing on achieving 
POSIX compliance may break things on the kernel side, which shouldn't happen.
   
   i personally tend to agree. (i guess i'm biased as my background is BSD)
   
   but it's how nuttx has been. that is, use the (mostly) same api for kernel 
as well.
   
   > @yamt, do you have specific examples of NuttX kernel code using those 
calls? Mainly because a bugfix should be created to actuate on those.
   
   eg. see include/debug.h. these debug macros are usually backed by syslog. 
depending on configurations, they can be used from a bit extreme contexts, like 
interrupt handlers and very early on the boot process.
   
   probably you can avoid errno access depending on the context.
   (using `up_interrupt_context` etc)
   although i feel it's a bit hacky, it seems like a common practice.
   
   > 
   > CC/ @patacongo @xiaoxiang781216 @acassis
   



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to