yamt commented on pull request #4754:
URL: https://github.com/apache/incubator-nuttx/pull/4754#issuecomment-990471626


   > > Hmm, the following commit has a problem with uSD card on Spresense.
   > > If I revert the commit locally, it works fine.
   > 
   > @xiaoxiang781216 Because the nuttx/fs/fat uses `wchar_t` inside, the side 
effect happened with this PR. If I added `-fshort-wchar` to the compile 
options, it worked again.
   > 
   > However, there are many linker warnings.
   > 
   > ```
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_udivmoddi4.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/thumb/v7e-m+fp/hard/libgcc.a(_fixunsdfdi.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-w_pow.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-e_pow.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-e_sqrt.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-s_fabs.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-s_finite.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-s_lib_ver.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-s_nan.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-s_rint.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > arm-none-eabi-ld: warning: 
/opt/gcc-arm-none-eabi-9-2020-q2-update/bin/../lib/gcc/arm-none-eabi/9.3.1/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libm.a(lib_a-s_scalbn.o)
 uses 4-byte wchar_t yet the output is to use 2-byte wchar_t; use of wchar_t 
values across objects may fail
   > ```
   
   i guess `nuttx/fs/fat` should use uint16_t instead.
   using wchar_t to mean particular encoding (utf16, utf32, or whatever) is a 
bad practice.
   


-- 
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