[QUOTE=Dubslow;300021]A somewhat better rendering of the middle glyph (as if any of us really need it).[/QUOTE]

Aha. very funny. I guess that was meant for me. Actually might be agreeing with it?

[QUOTE=R.D. Silverman;299989]Language holy wars serve no useful purpose. Combatants never reach a
resolution. As a former colleague once said "It is possible to write Fortran
in any language".[/QUOTE]

For the record it is worth noting that he must have said this at a time when Fortran was very different from the Fortran we have today (or he didn't know much about Fortran).

Brian

[QUOTE=jcrombie;300037]Aha. very funny. I guess that was meant for me. Actually might be agreeing with it?[/QUOTE]

Point taken. Thanks (really) for not leaving me oblivious. And please carry on.

I felt the discussion was valuable.

First it did a good job discussing various views of intent and implementation with respect to the various versions of the C standard. I feel it invaluable to be reminded of things like this from time to time.

Second, it had the merit of appropriate timing. When a new driver learns to drive a car it is crucial to, at that exact moment, instill good habits of checking mirrors before changing lanes. Bad habits are hard to break. The best time to start good habits is from the very beginning.

Third, the issues are important. Casts shut up the compiler. Casts hide bugs and are often, often, often the result of blurry thinking instead of truly understanding what is being written. It reminds me of people who add words to a spelling checker dictionary every time it questions a spelling. Sure it shuts up the error but the dictionary becomes worthless. Strings and character handling do have subtle gotchas and are plagued by bad practices and the standards themselves changing.

Finally, the heart was in the right place. It was intended to be helpful. It spun a little out of control because people felt these points were important. It is invaluable to understand what the machine is doing most of the time. Learning that people have issues with the nitty gritty and that it can be important is a good gloss to take from the discussion.

[QUOTE=only_human;300193]I felt the discussion was valuable.

First it did a good job discussing various views of intent and implementation with respect to the various versions of the C standard. I feel it invaluable to be reminded of things like this from time to time.

Second, it had the merit of appropriate timing. When a new driver learns to drive a car it is crucial to, at that exact moment, instill good habits of checking mirrors before changing lanes. Bad habits are hard to break. The best time to start good habits is from the very beginning.

Third, the issues are important. Casts shut up the compiler. Casts hide bugs and are often, often, often the result of blurry thinking instead of truly understanding what is being written. It reminds me of people who add words to a spelling checker dictionary every time it questions a spelling. Sure it shuts up the error but the dictionary becomes worthless. Strings and character handling do have subtle gotchas and are plagued by bad practices and the standards themselves changing.

Finally, the heart was in the right place. It was intended to be helpful. It spun a little out of control because people felt these points were important. It is invaluable to understand what the machine is doing most of the time. Learning that people have issues with the nitty gritty and that it can be important is a good gloss to take from the discussion.[/QUOTE]
:goodposting:



In the meantime, linking is causing me some pain, and though I'm sure I'm making a n00b mistake, I can't find it after a few googles and various combinations.
[code]bill@Gravemind:~/CUDALucas/test∰∂ ls
CUDALucas.cu cuda_safecalls.h Makefile parse.c parse.h [/code]
CUDALucas.cu has [#include "parse.h"] in it, and the functions are defined in parse.c. According to more than one website ([url]http://www.cs.colby.edu/maxwell/courses/tutorials/maketutor/[/url], [url]http://www.network-theory.co.uk/docs/gccintro/gccintro_14.html[/url]), I don't need to do anything other than have parse.o in the command; nonetheless, I get "undefined reference" errors for the functions declared in parse.h and defined in parse.c/o.
[code]bill@Gravemind:~/CUDALucas/test∰∂ cat Makefile
CUDA = /usr/local/cuda

NVCC = $(CUDA)/bin/nvcc
NFLAGS = -O2 -arch=sm_13

LIB = $(CUDA)/lib64

CC = gcc
L = -lcufft -lcudart -lm
CFLAGS = -O2 -fPIC -L$(LIB) -Wall $(L)

CUDALucas: parse.o parse.h CUDALucas.o
$(CC) $(CFLAGS) $^ -o $@

CUDALucas.o: CUDALucas.cu
$(NVCC) $(NFLAGS) -c CUDALucas.cu

parse.o: parse.c parse.h
$(CC) -O2 -c parse.c[/code]
[code]bill@Gravemind:~/CUDALucas/test∰∂ make
gcc -O2 -c parse.c
/usr/local/cuda/bin/nvcc -O2 -arch=sm_13 -c CUDALucas.cu
gcc -O2 -fPIC -L/usr/local/cuda/lib64 -Wall -lcufft -lcudart -lm [U]parse.o[/U] parse.h [U]CUDALucas.o[/U] -o CUDALucas
CUDALucas.o: In function `main':
tmpxft_000061ae_00000000-1_CUDALucas.cudafe1.cpp:(.text+0x4574): undefined reference to `get_next_assignment(char*, int*, char (*) [101], int)'
tmpxft_000061ae_00000000-1_CUDALucas.cudafe1.cpp:(.text+0x46d2): undefined reference to `clear_assignment(char*, int)'
tmpxft_000061ae_00000000-1_CUDALucas.cudafe1.cpp:(.text+0x49af): undefined reference to `valid_assignment(int, int)'
collect2: ld returned 1 exit status
make: *** [CUDALucas] Error 1[/code]

(If any of you who watch the CUDALucas thread are wondering why I can't get it to compile now but I could before: previously the contents of parse.c and parse.h were included inline in CL.cu; however, I'm trying to separate them in preparation for porting .ini features from mfaktc to CUDALucas. Also, it's a good first exercise in linking, though I was not anticipating this benefit :razz:)

New post for character limit
 

[QUOTE=jyb;299986]Here are some data points:

[code]

jyb% cat foo.c
int *Foo(void)
{
int *p;
p = malloc(10 * sizeof(int));
return p;
}
jyb% gcc -c foo.c
foo.c: In function ‘Foo’:
foo.c:4: warning: incompatible implicit declaration of built-in function ‘malloc’
jyb% gcc -c foo.c -Wall
foo.c: In function ‘Foo’:
foo.c:4: warning: implicit declaration of function ‘malloc’
foo.c:4: warning: incompatible implicit declaration of built-in function ‘malloc’
jyb% gcc -c foo.c -std=c89
foo.c: In function ‘Foo’:
foo.c:4: warning: incompatible implicit declaration of built-in function ‘malloc’
jyb% gcc -c foo.c -std=c99
foo.c: In function ‘Foo’:
foo.c:4: warning: implicit declaration of function ‘malloc’
foo.c:4: warning: incompatible implicit declaration of built-in function ‘malloc’
jyb% gcc -v
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2335.15~42/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2335.15~42/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
[/code][/QUOTE]
When I add the cast, -Wall still gives exactly the same warnings. (I haven't yet fiddled with standard.)
[code]bill@Gravemind:~/bin/c∰∂ cat foobar.c
int *Foo(void)
{
int *p;
p = (int* )malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:4:14: warning: incompatible implicit declaration of built-in function ‘malloc’
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:4:3: warning: implicit declaration of function ‘malloc’
foobar.c:4:14: warning: incompatible implicit declaration of built-in function ‘malloc’
bill@Gravemind:~/bin/c∰∂ nano foobar.c
bill@Gravemind:~/bin/c∰∂ cat foobar.c
int *Foo(void)
{
int *p;
p = malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:4:7: warning: incompatible implicit declaration of built-in function ‘malloc’
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:4:3: warning: implicit declaration of function ‘malloc’
foobar.c:4:7: warning: incompatible implicit declaration of built-in function ‘malloc’
bill@Gravemind:~/bin/c∰∂ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
bill@Gravemind:~/bin/c∰∂[/code]
More:
[code]bill@Gravemind:~/bin/c∰∂ cat foobar.c
#include <stdlib.h>

int *Foo(void)
{
int *p;
p = (int)malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:6:7: warning: cast from pointer to integer of different size
foobar.c:6:5: warning: assignment makes pointer from integer without a cast
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:6:7: warning: cast from pointer to integer of different size
foobar.c:6:5: warning: assignment makes pointer from integer without a cast
bill@Gravemind:~/bin/c∰∂ nano foobar.c
bill@Gravemind:~/bin/c∰∂ cat foobar.c
#include <stdlib.h>

int *Foo(void)
{
int p;
p = (int)malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:6:7: warning: cast from pointer to integer of different size
foobar.c:7:3: warning: return makes pointer from integer without a cast
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:6:7: warning: cast from pointer to integer of different size
foobar.c:7:3: warning: return makes pointer from integer without a cast
bill@Gravemind:~/bin/c∰∂ nano foobar.c
bill@Gravemind:~/bin/c∰∂ cat foobar.c
#include <stdlib.h>

int *Foo(void)
{
int p;
p = malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:6:5: warning: assignment makes integer from pointer without a cast
foobar.c:7:3: warning: return makes pointer from integer without a cast
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:6:5: warning: assignment makes integer from pointer without a cast
foobar.c:7:3: warning: return makes pointer from integer without a cast
bill@Gravemind:~/bin/c∰∂ nano foobar.c
bill@Gravemind:~/bin/c∰∂ cat foobar.c
#include <stdlib.h>

int Foo(void)
{
int p;
p = malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:6:5: warning: assignment makes integer from pointer without a cast
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:6:5: warning: assignment makes integer from pointer without a cast
bill@Gravemind:~/bin/c∰∂ nano foobar.c
bill@Gravemind:~/bin/c∰∂ cat foobar.c
#include <stdlib.h>

int Foo(void)
{
int p;
p = (int)malloc(10 * sizeof(int));
return p;
}
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c
foobar.c: In function ‘Foo’:
foobar.c:6:7: warning: cast from pointer to integer of different size
bill@Gravemind:~/bin/c∰∂ gcc -c foobar.c -Wall
foobar.c: In function ‘Foo’:
foobar.c:6:7: warning: cast from pointer to integer of different size
bill@Gravemind:~/bin/c∰∂[/code]
In no case is their a difference between -Wall and nothing, and it warns about non-casts just as much as for explicit-casts-for-disallowed-implicit-conversions. (They are different warnings, but they both appear all the same.)

(PS Are your cat/coreutils/etc GNU or an Apple version that complies with POSIX?)

[QUOTE=Dubslow;300195]
In the meantime, linking is causing me some pain, and though I'm sure I'm making a n00b mistake, I can't find it after a few googles and various combinations.[/QUOTE]

[url]http://forums.nvidia.com/index.php?showtopic=190973[/url]

After a while, I started to suspect it was something about .cu files. Then when I google'd that I got the right answer :smile:

[QUOTE=Dubslow;300196]When I add the cast, -Wall still gives exactly the same warnings. (I haven't yet fiddled with standard.)
[code]bill@Gravemind:~/bin/c∰∂ cat foobar.c
int *Foo(void)
{
int *p;
p = (int* )malloc(10 * sizeof(int));
return p;
}

[deleted some more permutations]

[/QUOTE]
You almost had it the first time. When two errors come together, this can be the thing hardest thing to figure out. Esp. if your only option is trial and error:smile:

The compiler never lies and is your best friend. "implicit declaration" of malloc is the compiler saying you didn't declare it so I'm just going make my best guess as to what you meant and go with that. Generally not a good idea. So declare it by including the correct include file. "man malloc" shows that to be <stdlib.h>.

So "man malloc" will also show malloc returns a "void*". That is what your rhs evaluates to. Your lhs evaluates to an "int*". (Not much evaluating there). So you've got "int* = void*". There is no implicit conversion defined for pointers, so your only option is to cast to "int*" on the rhs.
(Actually I wonder if you could cast on the lhs?)

Cheers

[QUOTE=jcrombie;300297]
So "man malloc" will also show malloc returns a "void*". That is what your rhs evaluates to. Your lhs evaluates to an "int*". (Not much evaluating there). So you've got "int* = void*". There is no implicit conversion defined for pointers, so your only option is to cast to "int*" on the rhs.
(Actually I wonder if you could cast on the lhs?)

Cheers[/QUOTE]
I am perfectly well aware what it [i]should[/i] be; this was an exercise to determine when or not the compiler throws warnings. Furthermore, jyb's whole point in this particular discussion was that [i]the whole point[/i] of void* was [i]to be implicitly convertible with the other pointer types. That's why malloc returns void*.[/i] We're trying to figure out when the cast shuts up the compiler. My examples appear to show that casts do not shut up the compiler, which is equally verbose about all warnings, even without -Wall.

[QUOTE=jcrombie;300297]You almost had it the first time. When two errors come together, this can be the thing hardest thing to figure out. Esp. if your only option is trial and error:smile:

The compiler never lies and is your best friend. "implicit declaration" of malloc is the compiler saying you didn't declare it so I'm just going make my best guess as to what you meant and go with that. Generally not a good idea. So declare it by including the correct include file. "man malloc" shows that to be <stdlib.h>.
[/QUOTE]
Yup, with you so far.

[QUOTE=jcrombie;300297]
So "man malloc" will also show malloc returns a "void*". That is what your rhs evaluates to. Your lhs evaluates to an "int*". (Not much evaluating there). So you've got "int* = void*". There is no implicit conversion defined for pointers, so your only option is to cast to "int*" on the rhs.
[/QUOTE]
No, once again this is just wrong. Jcrombie, please stop making pronouncements about the C type system until you learn something about it. May I suggest again that you read the standard? Or failing that, read a good book about C. The one which Dubslow has linked to has a decent treatment of assignment compatibility between pointers. void * pointers are assignment compatible with int * pointers, so no cast is needed.



[QUOTE=jcrombie;300297]
(Actually I wonder if you could cast on the lhs?)
[/QUOTE]
No, you cannot. Or, to be more precise, doing so is undefined in C. The lhs of an assignment must be an l-value, and a cast expression is not an l-value.

[QUOTE=jyb;300314]
No, once again this is just wrong. Jcrombie, please stop making pronouncements about the C type system until you learn something about it. May I suggest again that you read the standard? Or failing that, read a good book about C. The one which Dubslow has linked to has a decent treatment of assignment compatibility between pointers. void * pointers are assignment compatible with int * pointers, so no cast is needed.
[/QUOTE]
So, no cast is needed. But apparently it does? Well, it's clear you don't think I know what I'm talking about. I'm going to stand by my statement, but no more debates please.

Peace.