6 errors
Closed this issue · 9 comments
/usr/bin/gnumake
/opt/llvm/bin/clang -g -mmacosx-version-min=10.12 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fstack-protector-all -fPIE -fPIC -O2 -Wformat -Wformat-security -Werror=format-security -Wall -D_FORTIFY_SOURCE=2 -I/usr/local/include -c -o c_ksh.o c_ksh.c
c_ksh.c:518:13: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
shprintf(newline);
^~~~~~~
c_ksh.c:518:13: note: treat the string as an argument to avoid this
shprintf(newline);
^
"%s",
c_ksh.c:819:16: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
shprintf(newline);
^~~~~~~
c_ksh.c:819:16: note: treat the string as an argument to avoid this
shprintf(newline);
^
"%s",
c_ksh.c:909:14: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
shprintf(newline);
^~~~~~~
c_ksh.c:909:14: note: treat the string as an argument to avoid this
shprintf(newline);
^
"%s",
c_ksh.c:933:14: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
shprintf(newline);
^~~~~~~
c_ksh.c:933:14: note: treat the string as an argument to avoid this
shprintf(newline);
^
"%s",
c_ksh.c:1169:13: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
bi_errorf(null);
^~~~
c_ksh.c:1169:13: note: treat the string as an argument to avoid this
bi_errorf(null);
^
"%s",
c_ksh.c:1190:13: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security]
shprintf(newline);
^~~~~~~
c_ksh.c:1190:13: note: treat the string as an argument to avoid this
shprintf(newline);
^
"%s",
6 errors generated.
gnumake: *** [c_ksh.o] Error 1
GCC 4.2.1 does not report this as an error in base OpenBSD. As more programs and ports are linted and eventually switched over to clang, the code will be changed. It's up to Ibara if he wants to diverge from the original OpenBSD source to accommodate these being reported as errors. I can prepare a pull request if you want.
Yes please.
Note: GCC does not report the errors because it does not make clang's extensive audit. The errors are still there, whether GCC reports them or not.
Patches for
exec.c
expr.c
jobs.c
lex.c
main.c
misc.c
var.c
Results of compilation and comparison
>ls -l /bin/*sh
-r-xr-xr-x 1 root wheel 626272 Mar 23 00:57 /bin/bash
-rwxr-xr-x 1 root wheel 375632 Mar 23 00:57 /bin/csh
-r-xr-xr-x 1 root wheel 1377872 Mar 23 00:57 /bin/ksh
-rwxr-xr-x 1 root wheel 354424 May 9 10:45 /bin/oksh
-r-xr-xr-x 1 root wheel 630464 Mar 23 00:57 `/bin/sh`
-rwxr-xr-x 1 root wheel 375632 Mar 23 00:57 /bin/tcsh
-rwxr-xr-x 1 root wheel 592656 Mar 23 00:57 /bin/zsh
>otool -L /bin/oksh
/bin/oksh:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.50.2)
How to use oksh as default shell (MacOS)
Go to System Preferences -> Users & Groups
Click the lock icon to unlock the preference pane
Right-click (or control-click) on the user and select "advanced options"
Change "login shell" to /bin/oksh.
hey @hdatma, when I get some time I can review these and create another pull request with these changes, but please be aware that most of openbsd isn't using C99 as a standard, most utils are still using ANSI C or C89 as the base. I think that we should fix errors/warnings (I think these reported are valid) that are discovered by clang, but while adhering to the standards (-std=c89 or -ansi) added to your compile will show errors/issues while not introducing code that could be troublesome to compile on platforms that don't have a C99+ compiler handy. Thanks!
Hey! OpenBSD is on track to replace gcc with clang. The two previous releases removed obsolete architectures on purpose, and the next release is said to include clang along with gcc.
I think we can close this issue, as all errors have been cleared with patches.
Closed.