b-k / 21st-century-examples Goto Github PK

Hi,

just found that clang (from XCode and from brew) and gcc (from brew) behaves differently on Example 8-7:

% clang --version
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
% clang constfusion.c -o constfusion
constfusion.c:9:17: warning: initializing 'const int **' with an expression of type 'int **' discards qualifiers in nested pointer types
      [-Wincompatible-pointer-types-discards-qualifiers]
    int const **constptr = &var; // the line that sets up the failure
                ^          ~~~~
1 warning generated.
% ./constfusion
x=20 y=30
% /usr/local/opt/llvm/bin/clang --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: /usr/local/opt/llvm/bin
% /usr/local/opt/llvm/bin/clang constfusion.c -o constfusion
constfusion.c:9:17: warning: initializing 'const int **' with an expression of type 'int **' discards qualifiers in nested pointer types
      [-Wincompatible-pointer-types-discards-qualifiers]
    int const **constptr = &var; // the line that sets up the failure
                ^          ~~~~
1 warning generated.
% ./constfusion
x=20 y=30
% /usr/local/bin/gcc-6 --version
gcc-6 (Homebrew gcc 6.2.0 --without-multilib) 6.2.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% /usr/local/bin/gcc-6 constfusion.c -o constfusion
constfusion.c: In function 'main':
constfusion.c:9:28: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
     int const **constptr = &var; // the line that sets up the failure
                            ^
yes@OKEAH:Projects/21st-Century-Examples% ./constfusion
x=30 y=30

So what is the difference in generated code by clang and gcc?

Hello,
I started to read your book - it is nice! Thanks for it.
I stuck with gdb, where your examples on page 45 (GDB Variables) do not work for me. maybe I have too new version? (I downgraded gcc, but gdb my distro does not have packaged gdb lower then 7)
In short I cannot use "*x@3" for an array, here is a self explanatory log

[nix-shell:~/Downloads/test]$ gcc --version
gcc (GCC) 5.4.0
[nix-shell:~/Downloads/test]$ gdb --version
GNU gdb (GDB) 7.12.1
[nix-shell:~/Downloads/test]$ cat test.c
int main() {
    int x[20] = {};
    x[0] = 3;
}
[nix-shell:~/Downloads/test]$ gcc -O0 -g -Wall -std=gnu11 test.c
warning about not using x
[nix-shell:~/Downloads/test]$ gdb a.out 
(gdb) b 4
Breakpoint 1 at 0x400530: file test.c, line 4.
(gdb) r
Starting program: /home/kosh/Downloads/test/a.out 

Breakpoint 1, main () at test.c:4
4	}
(gdb) set $ptr=&x[3]
Attempt to take address of value not located in memory.
(gdb) p x
$1 = {3, <optimized out> <repeats 19 times>}
(gdb) p *x
Attempt to take address of value not located in memory.
(gdb) p *x@1
Attempt to take address of value not located in memory.
(gdb) p x[1]
$2 = <optimized out>
(gdb) p x[0]
$3 = 3

Is the problem with new gdb?

Hi I am getting the following error when running the example 1.3

/gsl_erf: error while loading shared libraries: libgsl.so.0: cannot open shared object file: No such file or directory

In dict_test.c g_test_trap_fork is used to check that "NULL is not a valid key.\n" is sent to stderr if NULL is used as a lookup key for a dict.

g_test_trap_fork is now deprecated in glib2.0 and so this code no longer compiles. It is recommended to use g_test_trap_subprocess instead.

make dict_test
cc -g -Wall -O3 pkg-config --cflags glib-2.0 -I/usr/include/glib-2.0 dict_test.c dict.o keyval.o -o dict_test
dict_test.c: In function ‘test_failure’:
dict_test.c:47:5: warning: ‘g_test_trap_fork’ is deprecated: Use 'g_test_trap_subprocess' instead [-Wdeprecated-declarations]
if (g_test_trap_fork(0, G_TEST_TRAP_SILENCE_STDOUT | G_TEST_TRAP_SILENCE_STDERR)){
^
In file included from /usr/include/glib-2.0/glib.h:82:0,
from dict_test.c:10:
/usr/include/glib-2.0/glib/gtestutils.h:228:10: note: declared here
gboolean g_test_trap_fork (guint64 usec_timeout,
^
/tmp/cchuUz21.o: In function test_failure': /home/wkmanire/Projects/21st-century-examples/dict_test.c:47: undefined reference tog_test_trap_fork'

Hi,
in my understanding, initialization of tally in line 75 of c_factors.c is not C11-compliant:

• if initialized with memset, length of area to set to 0 should be sizeof (_Atomic long int) and not sizeof (long int)
• I bet that initializing an atomic variable with memset gives an undefined behaviour according to C11. I think you should individually initalize each array element with atomic_init

There is a bug on page 190, 2nd edition.
The line:
if(!str)
Should be:
if(!*str)

I also remember another "bug": a semicolon at the end of a one-line-macro, but I do not remember the page.
Regards.

PS:
it's a good book, but some new tips are not so new.
For example, you describe autotools instead of cmake.

First of all thanks for your book. I'm really liking it. I'm running through your examples using a mac, and there's a number of small mis-matches for example

$ make
C99 -g -O0 -Wall -I/opt/X11/include   stddev_bugged.c   -o stddev_bugged
c99: invalid argument `all' to -W
make: *** [stddev_bugged] Error 64

I've been able to get through most of them, like in this example just not using -Wall, but some examples are harder. Sometimes i'm not sure if it's a platform thing or just my user error. Is it useful/helpful for me to document any of these, or would it be noise to you?

Hi
I met a problem when test string_utilities.c, I ran valgrind and found heap leak. But I was unable to locate and solve the problem.

system info

OS: Ubuntu Mate 17.10
Linux version 4.13.0-21-generic
gcc version 7.2.0
valgrind: 3-13.0

reproduce

compile with
gcc string_utilities.c -g -Wall -std=gnu11 -Dtest_ok_array `pkg-config --cflags glib-2.0` `pkg-config --libs glib-2.0` -o string_utilities

run with
valgrind ./string_utilities

report:
==1096== Memcheck, a memory error detector
==1096== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1096== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==1096== Command: ./string_utilities
==1096==
OK.
==1096==
==1096== HEAP SUMMARY:
==1096== in use at exit: 18,604 bytes in 6 blocks
==1096== total heap usage: 14 allocs, 8 frees, 19,802 bytes allocated
==1096==
==1096== LEAK SUMMARY:
==1096== definitely lost: 0 bytes in 0 blocks
==1096== indirectly lost: 0 bytes in 0 blocks
==1096== possibly lost: 0 bytes in 0 blocks
==1096== still reachable: 18,604 bytes in 6 blocks
==1096== suppressed: 0 bytes in 0 blocks
==1096== Rerun with --leak-check=full to see details of leaked memory
==1096==
==1096== For counts of detected and suppressed errors, rerun with: -v
==1096== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)