Regarding the whole C89/C90 language compliance debacle ...

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Regarding the whole C89/C90 language compliance debacle ...

Dennis Clarke

I may be the only person that does this sort of testing for my own
reasons and perhaps for sanity checking also. I tend to think that if
something is written to be compliant with C89/C90 then I should be able
to run the most strict compliance compiler flags in creation and be
perfectly happy.

However that is not the case here wwith gcc 9.2.0 on RHEL 7.4 :

../sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009.compile.log
/opt/bw/gcc9/bin/gcc  -std=iso9899:1990 -pedantic -Wpedantic
-pedantic-errors -O0 -m64 -g -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mksourceid
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:23:25:
error: ISO C90 does not support 'long long' [-Wlong-long]
    23 |   typedef unsigned long long int u64;
       |                         ^~~~
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:
In function 'KeccakF1600Step':
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:5:
error: use of C99 long long integer constant [-Wlong-long]
    74 |     0x0000000000000001ULL,  0x0000000000008082ULL,
       |     ^~~~~~~~~~~~~~~~~~~~~
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:29:
error: use of C99 long long integer constant [-Wlong-long]
    74 |     0x0000000000000001ULL,  0x0000000000008082ULL,
       |                             ^~~~~~~~~~~~~~~~~~~~~

etc etc

If we look :

boe13$ head -80 tool/mksourceid.c | tail
   u64 C0, C1, C2, C3, C4;
   u64 D0, D1, D2, D3, D4;
   static const u64 RC[] = {
     0x0000000000000001ULL,  0x0000000000008082ULL,
     0x800000000000808aULL,  0x8000000080008000ULL,
     0x000000000000808bULL,  0x0000000080000001ULL,
     0x8000000080008081ULL,  0x8000000000008009ULL,
     0x000000000000008aULL,  0x0000000000000088ULL,
     0x0000000080008009ULL,  0x000000008000000aULL,
     0x000000008000808bULL,  0x800000000000008bULL,
boe13$

Here I am using some very strict flags and note the -fno-builtin :

boe13$ echo $CFLAGS
-std=iso9899:1990 -pedantic -Wpedantic -pedantic-errors -O0 -m64
  -g -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags
  -fno-builtin -malign-double
boe13$

So that clearly isn't going to work here.

So let's try -std=iso9899:1999 and see a different type of failure :

/opt/bw/gcc9/bin/gcc  -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mksourceid
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
tclsh8.7
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksqlite3h.tcl
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009
 >sqlite3.h
/opt/bw/gcc9/bin/gcc  -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
mkkeywordhash
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mkkeywordhash.c
./mkkeywordhash >keywordhash.h
/opt/bw/gcc9/bin/gcc  -std=iso9899:1999 -O0 -m64 -g -pedantic
-pedantic-errors -Wpedantic -march=k8 -mtune=k8
-Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
lemon
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:
In function 'main':
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1639:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
  1639 |     {OPT_FSTR, "d", (char*)&handle_d_option, "Output directory.
  Default '.'"},
       |                     ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1640:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
  1640 |     {OPT_FSTR, "D", (char*)handle_D_option, "Define an %ifdef
macro."},
       |                     ^
/opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1654:21:
error: ISO C forbids conversion of function pointer to object pointer
type [-Wpedantic]
  1654 |     {OPT_FSTR, "T", (char*)handle_T_option, "Specify a template
file."},
       |                     ^

OKay so at this point I move over to an entirely separate system and
architecture wherein I have very strict POSIX compliance at all levels
and use the Oracle Studio 12.6 compiler tools. Specifically the c99
compiler there with -Xc strict compliance and a very few other flags.
This is a very well maintained sparc M-class Oracle/Fujitsu server on
maintenance contract and it runs very very stable and well :

beta$ pwd
/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005
beta$
beta$ echo $CFLAGS
-m64 -xarch=sparc -Xc -g -mc -xs -errfmt=error -erroff=%none
-errshort=full -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none
-xildoff -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil
-xunroll=1 -xregs=no%appl -xdebugformat=dwarf
beta$ echo $CC
/opt/developerstudio12.6/bin/c99
beta$

I can report that the code compiles clean.

However the testsuite is another matter :

/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c:
"/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c",
line 23: warning: empty translation unit (E_EMPTY_TRANSLATION_UNIT)
/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c:
"/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c",
line 2624: warning: argument #3 is incompatible with prototype:
         prototype: pointer to long : "/usr/local/include/tclDecls.h",
line 2866
         argument : pointer to long long (E_ARG_INCOMPATIBLE_WITH_ARG_L)
sqlite3.c:
"sqlite3.c", line 21610: warning: implicit function declaration:
localtime_r (E_NO_IMPLICIT_DECL_ALLOWED)
"sqlite3.c", line 53745: warning: statement not reached
(E_STATEMENT_NOT_REACHED)
"sqlite3.c", line 87339: warning: statement not reached
(E_STATEMENT_NOT_REACHED)
"sqlite3.c", line 154637: warning: statement not reached
(E_STATEMENT_NOT_REACHED)
ld: warning: option -Q appears more than once, first setting taken
Undefined                       first referenced
  symbol                             in file
sched_yield                         test4.o
ld: fatal: symbol referencing errors. No output written to testfixture
gmake: *** [Makefile:1221: testfixture] Error 2


So on different systems with different architectures and compilers I get
different behavior from very clean compliant code that I can not compile
with gcc.  This is all very confusing to me.  Is my thinking wrong here
in that I think that clean code should just compile everywhere with a
good compiler?

Note that I have not check on IBM Power not FreeBSD with LLVM/Clang but
that is on my todo list.  Ultimately I am trying to get to FreeBSD on a
RISC-V platform here but that is a long way off.  Next month I hope. In
any case should I be seeing these failures ?

--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Peter da Silva-2
Strictly compliant code strictly doesn't need to do anything at all,
conforming to strict standards instead of what compilers actually do is an
interesting intellectual exercise but is not necessarily useful.

On Sat, Nov 23, 2019, 16:27 Dennis Clarke <[hidden email]> wrote:

>
> I may be the only person that does this sort of testing for my own
> reasons and perhaps for sanity checking also. I tend to think that if
> something is written to be compliant with C89/C90 then I should be able
> to run the most strict compliance compiler flags in creation and be
> perfectly happy.
>
> However that is not the case here wwith gcc 9.2.0 on RHEL 7.4 :
>
> ../sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009.compile.log
> /opt/bw/gcc9/bin/gcc  -std=iso9899:1990 -pedantic -Wpedantic
> -pedantic-errors -O0 -m64 -g -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> mksourceid
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:23:25:
>
> error: ISO C90 does not support 'long long' [-Wlong-long]
>     23 |   typedef unsigned long long int u64;
>        |                         ^~~~
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:
>
> In function 'KeccakF1600Step':
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:5:
>
> error: use of C99 long long integer constant [-Wlong-long]
>     74 |     0x0000000000000001ULL,  0x0000000000008082ULL,
>        |     ^~~~~~~~~~~~~~~~~~~~~
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c:74:29:
>
> error: use of C99 long long integer constant [-Wlong-long]
>     74 |     0x0000000000000001ULL,  0x0000000000008082ULL,
>        |                             ^~~~~~~~~~~~~~~~~~~~~
>
> etc etc
>
> If we look :
>
> boe13$ head -80 tool/mksourceid.c | tail
>    u64 C0, C1, C2, C3, C4;
>    u64 D0, D1, D2, D3, D4;
>    static const u64 RC[] = {
>      0x0000000000000001ULL,  0x0000000000008082ULL,
>      0x800000000000808aULL,  0x8000000080008000ULL,
>      0x000000000000808bULL,  0x0000000080000001ULL,
>      0x8000000080008081ULL,  0x8000000000008009ULL,
>      0x000000000000008aULL,  0x0000000000000088ULL,
>      0x0000000080008009ULL,  0x000000008000000aULL,
>      0x000000008000808bULL,  0x800000000000008bULL,
> boe13$
>
> Here I am using some very strict flags and note the -fno-builtin :
>
> boe13$ echo $CFLAGS
> -std=iso9899:1990 -pedantic -Wpedantic -pedantic-errors -O0 -m64
>   -g -march=k8 -mtune=k8 -Wl,-rpath=/opt/bw/lib,--enable-new-dtags
>   -fno-builtin -malign-double
> boe13$
>
> So that clearly isn't going to work here.
>
> So let's try -std=iso9899:1999 and see a different type of failure :
>
> /opt/bw/gcc9/bin/gcc  -std=iso9899:1999 -O0 -m64 -g -pedantic
> -pedantic-errors -Wpedantic -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> mksourceid
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksourceid.c
> tclsh8.7
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mksqlite3h.tcl
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009
>  >sqlite3.h
> /opt/bw/gcc9/bin/gcc  -std=iso9899:1999 -O0 -m64 -g -pedantic
> -pedantic-errors -Wpedantic -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> mkkeywordhash
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/mkkeywordhash.c
> ./mkkeywordhash >keywordhash.h
> /opt/bw/gcc9/bin/gcc  -std=iso9899:1999 -O0 -m64 -g -pedantic
> -pedantic-errors -Wpedantic -march=k8 -mtune=k8
> -Wl,-rpath=/opt/bw/lib,--enable-new-dtags -fno-builtin -malign-double -o
> lemon
>
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:
>
> In function 'main':
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1639:21:
>
> error: ISO C forbids conversion of function pointer to object pointer
> type [-Wpedantic]
>   1639 |     {OPT_FSTR, "d", (char*)&handle_d_option, "Output directory.
>   Default '.'"},
>        |                     ^
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1640:21:
>
> error: ISO C forbids conversion of function pointer to object pointer
> type [-Wpedantic]
>   1640 |     {OPT_FSTR, "D", (char*)handle_D_option, "Define an %ifdef
> macro."},
>        |                     ^
> /opt/bw/build/sqlite_20191121213415_rhel_74_3.10.0-693.el7.x86_64.009/tool/lemon.c:1654:21:
>
> error: ISO C forbids conversion of function pointer to object pointer
> type [-Wpedantic]
>   1654 |     {OPT_FSTR, "T", (char*)handle_T_option, "Specify a template
> file."},
>        |                     ^
>
> OKay so at this point I move over to an entirely separate system and
> architecture wherein I have very strict POSIX compliance at all levels
> and use the Oracle Studio 12.6 compiler tools. Specifically the c99
> compiler there with -Xc strict compliance and a very few other flags.
> This is a very well maintained sparc M-class Oracle/Fujitsu server on
> maintenance contract and it runs very very stable and well :
>
> beta$ pwd
> /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005
> beta$
> beta$ echo $CFLAGS
> -m64 -xarch=sparc -Xc -g -mc -xs -errfmt=error -erroff=%none
> -errshort=full -errtags=yes -errwarn=%none -ftrap=%none -xbuiltin=%none
> -xildoff -xlibmieee -xstrconst -xcode=pic32 -xmemalign=8s -xnolibmil
> -xunroll=1 -xregs=no%appl -xdebugformat=dwarf
> beta$ echo $CC
> /opt/developerstudio12.6/bin/c99
> beta$
>
> I can report that the code compiles clean.
>
> However the testsuite is another matter :
>
>
> /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c:
> "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/ext/userauth/userauth.c",
>
> line 23: warning: empty translation unit (E_EMPTY_TRANSLATION_UNIT)
> /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c:
> "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c",
>
> line 2624: warning: argument #3 is incompatible with prototype:
>          prototype: pointer to long : "/usr/local/include/tclDecls.h",
> line 2866
>          argument : pointer to long long (E_ARG_INCOMPATIBLE_WITH_ARG_L)
> sqlite3.c:
> "sqlite3.c", line 21610: warning: implicit function declaration:
> localtime_r (E_NO_IMPLICIT_DECL_ALLOWED)
> "sqlite3.c", line 53745: warning: statement not reached
> (E_STATEMENT_NOT_REACHED)
> "sqlite3.c", line 87339: warning: statement not reached
> (E_STATEMENT_NOT_REACHED)
> "sqlite3.c", line 154637: warning: statement not reached
> (E_STATEMENT_NOT_REACHED)
> ld: warning: option -Q appears more than once, first setting taken
> Undefined                       first referenced
>   symbol                             in file
> sched_yield                         test4.o
> ld: fatal: symbol referencing errors. No output written to testfixture
> gmake: *** [Makefile:1221: testfixture] Error 2
>
>
> So on different systems with different architectures and compilers I get
> different behavior from very clean compliant code that I can not compile
> with gcc.  This is all very confusing to me.  Is my thinking wrong here
> in that I think that clean code should just compile everywhere with a
> good compiler?
>
> Note that I have not check on IBM Power not FreeBSD with LLVM/Clang but
> that is on my todo list.  Ultimately I am trying to get to FreeBSD on a
> RISC-V platform here but that is a long way off.  Next month I hope. In
> any case should I be seeing these failures ?
>
> --
> Dennis Clarke
> RISC-V/SPARC/PPC/ARM/CISC
> UNIX and Linux spoken
> GreyBeard and suspenders optional
> _______________________________________________
> sqlite-users mailing list
> [hidden email]
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Jan Nijtmans
In reply to this post by Dennis Clarke
Op za 23 nov. 2019 om 23:27 schreef Dennis Clarke:
> /usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c:
> "/usr/local/build/sqlite-src-3300100_Oracle_sparc64vii+.005/src/tclsqlite.c",
> line 2624: warning: argument #3 is incompatible with prototype:
>          prototype: pointer to long : "/usr/local/include/tclDecls.h",
> line 2866


Line 2611 of  tclsqlite.c reads:
      sqlite3_int64 mxSize = 0;
this should have been
      Tcl_WideInt mxSize = 0;

Tcl_WideInt is guaranteed to be at least a 64-bit type, but it might be
"long" or "long long" dependant on Tcl version or platform. So, the
warning is harmless, understandable, and easy to fix.

Regards,
      Jan Nijtmans
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Richard Hipp-3
In reply to this post by Peter da Silva-2
On 11/23/19, Peter da Silva <[hidden email]> wrote:
> Strictly compliant code strictly doesn't need to do anything at all,
> conforming to strict standards instead of what compilers actually do is an
> interesting intellectual exercise but is not necessarily useful.

Right.  So given the choice between

(1) Code that works and does something useful
(2) Code that is standards compliant

I'll always go with (1).  Now, if we can add in (2) as well, without
compromising (1), then so much the better.  But the primary focus is
always on (1).

--
D. Richard Hipp
[hidden email]
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Dennis Clarke
On 11/23/19 11:06 PM, Richard Hipp wrote:
> conforming to strict standards instead of what compilers actually do

My problem here is that the compilers and their ability to comply with
those wonderful cross platform standards is always a moving picture.

Regardless it may be of some value to put a note somewhere on the sqlite
webpages that says "just use GCC and don't specify -std" or something
more helpful.

Having said all that the use-after-free bug is real and we may yet have
other problems in the test harness. I am still working through that and
doing testing on a multitude of architectures ( risc / cisc / big endian
/ little endian and 32 and 64 bit ) which tends to reveal issues.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Simon Slavin-3
In reply to this post by Richard Hipp-3
On 23 Nov 2019, at 11:06pm, Richard Hipp <[hidden email]> wrote:

> given the choice between
>
> (1) Code that works and does something useful
> (2) Code that is standards compliant
>
> I'll always go with (1).

Another problem is that different compilers, or the same compiler with different options, warn about different things.  And that making changes to make one compiler happy can make another compiler unhappy.  Until you end up with

    complicated line here; /* actually does a = b but
                                must keep four compilers happy */
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Gary R. Schmidt
On 24/11/2019 10:35, Simon Slavin wrote:

> On 23 Nov 2019, at 11:06pm, Richard Hipp <[hidden email]> wrote:
>
>> given the choice between
>>
>> (1) Code that works and does something useful
>> (2) Code that is standards compliant
>>
>> I'll always go with (1).
>
> Another problem is that different compilers, or the same compiler with different options, warn about different things.  And that making changes to make one compiler happy can make another compiler unhappy.  Until you end up with
>
>      complicated line here; /* actually does a = b but
> must keep four compilers happy */

Things like this remind me of Donald Knuth's line: "Beware of bugs in
the above code; I have only proved it correct, not tried it."

And over the decades[1] of writing (portable) C code I have sprinkled
many such comments on how, "doing this makes it work on such-and-such a
system" in many, many files.  :-)

        Cheers,
                Gary B-)

1 - I was taught C by kre back in 1982 (or was it 1983?), on a VAX
called "munnari," for those who remember their history  :->
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Dennis Clarke
In reply to this post by Simon Slavin-3
On 11/23/19 11:35 PM, Simon Slavin wrote:

> On 23 Nov 2019, at 11:06pm, Richard Hipp <[hidden email]> wrote:
>
>> given the choice between
>>
>> (1) Code that works and does something useful
>> (2) Code that is standards compliant
>>
>> I'll always go with (1).
>
> Another problem is that different compilers, or the same compiler with different options, warn about different things.  And that making changes to make one compiler happy can make another compiler unhappy.  Until you end up with
>
>      complicated line here; /* actually does a = b but
> must keep four compilers happy */


Thanks !!  I needed that.  I have been pouring over this for two weeks
  and the real issue is test suite.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Dennis Clarke
In reply to this post by Gary R. Schmidt

> 1 - I was taught C by kre back in 1982 (or was it 1983?), on a VAX
> called "munnari," for those who remember their history  :->

I remember you however I started on BSD implementaions in 83 or 84 with
the first real big workstations I had being the Apollo DN1000 and DN3000
boxen. Those things ran something called aegis which was essentially
BSD. These were followed rapidly by the first big deskside Sun boxens on
the old hypersparc or ross type chips in VME bus enclosures. Anyone
recall the sweeping cpu led lights on the back of the cpu boards? Those
were the early hardware implementations of the cylon ( BattleStar
Gallactica and not the cool show either ) red eyes. Which was worth the
price just to see them all going bonkers.

Anyways .. yeah ... C and Fortran ( lots ) and Pascal but we don't talk
about that.


--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional
_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding the whole C89/C90 language compliance debacle ...

Richard Damon
In reply to this post by Simon Slavin-3
On 11/23/19 6:35 PM, Simon Slavin wrote:

> On 23 Nov 2019, at 11:06pm, Richard Hipp <[hidden email]> wrote:
>
>> given the choice between
>>
>> (1) Code that works and does something useful
>> (2) Code that is standards compliant
>>
>> I'll always go with (1).
> Another problem is that different compilers, or the same compiler with different options, warn about different things.  And that making changes to make one compiler happy can make another compiler unhappy.  Until you end up with
>
>     complicated line here; /* actually does a = b but
> must keep four compilers happy */

I consider it an error in specifications if there is a requirement for
no warnings without specifying what compiler/options that requirement
needs to be meet on. It can be shown to be impossible to get totally
warning free code on arbitrary compilers.

As to the original question, if the program uses the type long long,
then it can't be C89/C90 compatible, as the type didn't exist then. It
might be that the program given some option could make a variation that
doesn't use long long for very old systems.

As to the conversion between function pointers and data pointers, this
ability is not specified in the C Standard, and on some machines it
actually can't be done. POSIX compatibility requires that it works in at
least some limited situation as an extension. (Originally, there was
some confusion over if it required a diagnostic in fully conforming mode
or not, of course enabling POSIX would suppress that message).

Sometimes code is just easier to write (or performs better) if you use
extensions provided by an implementation. Doing so limits what compilers
can be used, but some GCC extensions are just so commonly available on a
variety of platforms that the limitation is minor.

--
Richard Damon

_______________________________________________
sqlite-users mailing list
[hidden email]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users