Search Results

Search found 122 results on 5 pages for 'c99'.

Page 4/5 | < Previous Page | 1 2 3 4 5  | Next Page >

• Pros and Cons of Different macro function / inline methods in C

  - by Robert S. Barnes

  According to the C FAQ, there are basically 3 practical methods for "inlining" code in C: #define MACRO(arg1, arg2) do { \ /* declarations */ \ stmt1; \ stmt2; \ /* ... */ \ } while(0) /* (no trailing ; ) */ or #define FUNC(arg1, arg2) (expr1, expr2, expr3) To clarify this one, the arguments are used in the expressions, and the comma operator returns the value of the last expression. or using the inline declaration which is supported as an extension to gcc and in the c99 standard. The do { ... } while (0) method is widely used in the Linux kernel, but I haven't encountered the other two methods very often if at all. I'm referring specifically to multi-statement "functions", not single statement ones like MAX or MIN. What are the pros and cons of each method, and why would you choose one over the other in various situations?

  Read the article

• Makefile to compile both C and Java programs at the same time

  - by user342745

  I have three programs that need to be compiled at the same time, 2 written in C and 1 in java. I had all three working with the Makefile when they were in C, but then switched one of them to java... is there a way to compile all 3 at once with the same makefile? Here is my current Makefile: CC=gcc JC=javac JFLAGS= -g CFLAGS= -Wall -g -std=c99 LDFLAGS= -lm .SUFFIXES: .java .class .java.class: $(JC) $(JFLAGS) $*.java CLASSES = kasiski.java kentry.java ALL= ic ftable kasiski all: $(ALL) ic: ic.o kasiski: $(CLASSES:.java=.class) ftable: ftable.o ic.o: ic.c ic.h ftable.o: ftable.c ftable.h .PHONY: clean clean: rm -rf core* *.class *.o *.gch $(ALL)

  Read the article

• Controlling read and write access width to memory mapped registers in C

  - by srking

  I'm using and x86 based core to manipulate a 32-bit memory mapped register. My hardware behaves correctly only if the CPU generates 32-bit wide reads and writes to this register. The register is aligned on a 32-bit address and is not addressable at byte granularity. What can I do to guarantee that my C (or C99) compiler will only generate full 32-bit wide reads and writes in all cases? For example, if I do a read-modify-write operation like this: volatile uint32_t* p_reg = 0xCAFE0000; *p_reg |= 0x01; I don't want the compiler to get smart about the fact that only the bottom byte changes and generate 8-bit wide read/writes. Since the machine code is often more dense for 8-bit operations on x86, I'm afraid of unwanted optimizations. Disabling optimizations in general is not an option.

  Read the article

• C++0x implementation guesstimates?

  - by dsimcha

  The C++0x standard is on its way to being complete. Until now, I've dabbled in C++, but avoided learning it thoroughly because it seems like it's missing a lot of modern features that I've been spoiled by in other languages. However, I'd be very interested in C++0x, which addresses a lot of my complaints. Any guesstimates, after the standard is ratified, as to how long it will take for major compiler vendors to provide reasonably complete, production-quality implementations? Will it happen soon enough to reverse the decline in C++'s popularity, or is it too little, too late? Do you believe that C++0x will become "the C++" within a few years, or do you believe that most people will stick to the earlier standard in practice and C++0x will be somewhat of a bastard stepchild, kind of like C99?

  Read the article

• Similar code detector

  - by Let_Me_Be

  I'm search for a tool that could compare source codes for similarity. We have a very trivial system right now that has huge amount of false positives and the real positives can easily get buried in them. My requirements are: reasonably small amount of false positives good detection rate (yeah these are going against each other) ideally with a more complex output than just a single value usable for C (C99) and C++ (C++03 and optimally C++11) still maintained usable for comparing two source files against each other usable in non-interactive mode EDIT: To avoid confusion, the following two code snippets are identical and should be detected as such: for (int i = 0; i < 10; i++) { bla; } int i; while (i < 10) { bla; i++; } The same here: int x = 10; y = x + 5; int a = 10; y = a + 5;

  Read the article

• Pointer aliasing- in C++0x

  - by DeadMG

  I'm thinking about (just as an idea) disjointed pointer aliasing in C++0x. I was thinking about seeing if it could be implemented similarly to const correctness- that is, enforced by the compiler. What would be the requirements for such a thing? As this is more of a thought experiment, I'm perfectly happy to look at solutions that destroy legacy code or redefine half the language and that kind of thing. What I'd really rather not do is have, say, restrict from C99 where the programmer just promises it. It should be enforced.

  Read the article

• Unexpected output on initializing array by using both `element-by-element` & `designated` technique

  - by haccks

  C99 provides a feature to initialize arrays by using both element-by-element & designated method together as: int a[] = {2,1,[3] = 5,[5] = 9,6,[8] = 4}; On running the code: #include <stdio.h> int main() { int a[] = {2,1,[3] = 5,[0] = 9,4,[6] = 25}; for(int i = 0; i < sizeof(a)/sizeof(a[0]); i++) printf("%d ",a[i]); return 0; } (Note that Element 0 is initialized to 2 and then again initialised by designator [0] to 9) I was expecting that element 0(which is 2) will be replaced by 9(as designator [0] = 9) and hence o/p will become 9 1 0 5 4 0 25 Unfortunately I was wrong as o/p came; 9 4 0 5 0 0 25 Any explanation for unexpected o/p?

  Read the article

• Why would I learn C++11, having known C and C++?

  - by Shahbaz

  I am a programmer in C and C++, although I don't stick to either language and write a mixture of the two. Sometimes having code in classes, possibly with operator overloading, or templates and the oh so great STL is obviously a better way. Sometimes use of a simple C function pointer is much much more readable and clear. So I find beauty and practicality in both languages. I don't want to get into the discussion of "If you mix them and compile with a C++ compiler, it's not a mix anymore, it's all C++" I think we all understand what I mean by mixing them. Also, I don't want to talk about C vs C++, this question is all about C++11. C++11 introduces what I think are significant changes to how C++ works, but it has introduced many special cases that change how different features behave in different circumstances, placing restrictions on multiple inheritance, adding lambda functions, etc. I know that at some point in the future, when you say C++ everyone would assume C++11. Much like when you say C nowadays, you most probably mean C99. That makes me consider learning C++11. After all, if I want to continue writing code in C++, I may at some point need to start using those features simply because my colleagues have. Take C for example. After so many years, there are still many people learning and writing code in C. Why? Because the language is good. What good means is that, it follows many of the rules to create a good programming language. So besides being powerful (which easy or hard, almost all programming languages are), C is regular and has few exceptions, if any. C++11 however, I don't think so. I'm not sure that the changes introduced in C++11 are making the language better. So the question is: Why would I learn C++11? Update: My original question in short was: "I like C++, but the new C++11 doesn't look good because of this and this and this. However, deep down something tells me I need to learn it. So, I asked this question here so that someone would help convince me to learn it." However, the zealous people here can't tolerate pointing out a flaw in their language and were not at all constructive in this manner. After the moderator edited the question, it became more like a "So, how about this new C++11?" which was not at all my question. Therefore, in a day or too I am going to delete this question if no one comes up with an actual convincing argument. P.S. If you are interested in knowing what flaws I was talking about, you can edit my question and see the previous edits.

  Read the article

• Configuring SASL support in libmemcached

  - by John Keyes

  I'm trying to build libmemcached with SASL support on OS X Mountain Lion. I have built memcached (1.4.15) with SASL support: $ memcached -S -vv Initialized SASL. slab class 1: chunk size 96 perslab 10922 ... slab class 42: chunk size 1048576 perslab 1 <17 server listening (binary) <18 server listening (binary) <19 send buffer was 9216, now 3728270 <20 send buffer was 9216, now 3728270 <19 server listening (udp) <20 server listening (udp) ... I am trying to build libmemcached with SASL support too. I have tried the following: $ ./configure --prefix=/usr/local \ --with-memcached-sasl=/usr/local/bin/memcached ... $ ./configure --prefix=/usr/local \ --with-memcached-sasl="/usr/local/bin/memcached -S" ... But the resulting configuration summary is the same for both: Configuration summary for libmemcached version 1.0.11 * Installation prefix: /usr/local * System type: apple-darwin12.2.0 * Host CPU: x86_64 * C Compiler: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) * C Flags: -O2 -Werror -Wall -Wextra -std=c99 -Wbad-function-cast -Wmissing-prototypes -Wnested-externs -Woverride-init * C++ Compiler: i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) * C++ Flags: -O2 -Werror -Wall -Wextra -Wpragmas -D_FORTIFY_SOURCE=2 -Waddress -Wchar-subscripts -Wcomment -Wctor-dtor-privacy -Wfloat-equal -Wformat=2 -Wmissing-field-initializers -Wmissing-noreturn -Wnon-virtual-dtor -Wnormalized=id -Woverloaded-virtual -Wpointer-arith -Wredundant-decls -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wstrict-overflow=1 -Wswitch-enum -Wundef -Wunused-variable -Wwrite-strings -fwrapv -ggdb * CPP Flags: -I/usr/local/include * Assertions enabled: no * Debug enabled: no * Warnings as failure: no * SASL support: Am I doing something incorrectly? Thanks.

  Read the article

• Undefined reference to 'glib'

  - by dali1985

  I would like to parse a config file using glib in Codeblocks which I use. So I want to do exactly the example which is described here first. I have a file named myconfig.cfg and and a code programming.c. I just copy and paste the code to see if glib works but unfortunately it does not work. I did the installation of glib2.0 using sudo apt-get, I found where are the libs in glibs using pkg-config --cflags --libs glib-2.0 and in this path project->Build Options->Compiler Settings-> Other Options I added -I/usr/include/glib-2.0 -I/usr/lib/arm-linuxgnuebihf/glib-2.0/include When I build and run the programming.c I have these errors -------------- Build: Debug in programming --------------- gcc -Wall -g -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabihf/glib-2.0/include -std=c99 -c /home/pi/Desktop/programming/main.c -o obj/Debug/main.o g++ -o bin/Debug/programming obj/Debug/main.o /usr/lib/libmysqlclient.so.16 obj/Debug/main.o: In function `main': /home/pi/Desktop/programming/main.c:22: undefined reference to `g_key_file_new' /home/pi/Desktop/programming/main.c:26: undefined reference to `g_key_file_load_from_file' /home/pi/Desktop/programming/main.c:28: undefined reference to `g_log' /home/pi/Desktop/programming/main.c:34: undefined reference to `g_slice_alloc' /home/pi/Desktop/programming/main.c:37: undefined reference to `g_key_file_get_string' /home/pi/Desktop/programming/main.c:39: undefined reference to `g_key_file_get_locale_string' /home/pi/Desktop/programming/main.c:41: undefined reference to `g_key_file_get_boolean_list' /home/pi/Desktop/programming/main.c:43: undefined reference to `g_key_file_get_integer_list' /home/pi/Desktop/programming/main.c:45: undefined reference to `g_key_file_get_string_list' /home/pi/Desktop/programming/main.c:47: undefined reference to `g_key_file_get_integer' /home/pi/Desktop/programming/main.c:49: undefined reference to `g_key_file_get_double_list' collect2: ld returned 1 exit status Process terminated with status 1 (0 minutes, 6 seconds) 11 errors, 0 warnings Am I missing something? I tried also to do in the same way with libconfig but again I have undefined reference. Is the problem the path?

  Read the article

• valgrind complains doing a very simple strtok in c

  - by monkeyking

  Hi I'm trying to tokenize a string by loading an entire file into a char[] using fread. For some strange reason it is not always working, and valgrind complains in this very small sample program. Given an input like test.txt first second And the following program #include <stdio.h> #include <string.h> #include <stdlib.h> #include <sys/stat.h> //returns the filesize in bytes size_t fsize(const char* fname){ struct stat st ; stat(fname,&st); return st.st_size; } int main(int argc, char *argv[]){ FILE *fp = NULL; if(NULL==(fp=fopen(argv[1],"r"))){ fprintf(stderr,"\t-> Error reading file:%s\n",argv[1]); return 0; } char buffer[fsize(argv[1])]; fread(buffer,sizeof(char),fsize(argv[1]),fp); char *str = strtok(buffer," \t\n"); while(NULL!=str){ fprintf(stderr,"token is:%s with strlen:%lu\n",str,strlen(str)); str = strtok(NULL," \t\n"); } return 0; } compiling like gcc test.c -std=c99 -ggdb running like ./a.out test.txt thanks

  Read the article

• Using stdint.h and ANSI printf?

  - by nn

  Hi, I'm writing a bignum library, and I want to use efficient data types to represent the digits. Particularly integer for the digit, and long (if strictly double the size of the integer) for intermediate representations when adding and multiplying. I will be using some C99 functionality, but trying to conform to ANSI C. Currently I have the following in my bignum library: #include <stdint.h> #if defined(__LP64__) || defined(__amd64) || defined(__x86_64) || defined(__amd64__) || defined(__amd64__) || defined(_LP64) typedef uint64_t u_w; typedef uint32_t u_hw; #define BIGNUM_DIGITS 2048 #define U_HW_BITS 16 #define U_W_BITS 32 #define U_HW_MAX UINT32_MAX #define U_HW_MIN UINT32_MIN #define U_W_MAX UINT64_MAX #define U_W_MIN UINT64_MIN #else typedef uint32_t u_w; typedef uint16_t u_hw; #define BIGNUM_DIGITS 4096 #define U_HW_BITS 16 #define U_W_BITS 32 #define U_HW_MAX UINT16_MAX #define U_HW_MIN UINT16_MIN #define U_W_MAX UINT32_MAX #define U_W_MIN UINT32_MIN #endif typedef struct bn { int sign; int n_digits; // #digits should exclude carry (digits = limbs) int carry; u_hw tab[BIGNUM_DIGITS]; } bn; As I haven't written a procedure to write the bignum in decimal, I have to analyze the intermediate array and printf the values of each digit. However I don't know which conversion specifier to use with printf. Preferably I would like to write to the terminal the digit encoded in hexadecimal. The underlying issue is, that I want two data types, one that is twice as long as the other, and further use them with printf using standard conversion specifiers. It would be ideal if int is 32bits and long is 64bits but I don't know how to guarantee this using a preprocessor, and when it comes time to use functions such as printf that solely rely on the standard types I no longer know what to use.

  Read the article

• Making a 64 bit shared library that dynamically links to a 32 bit library on Mac OS X Snow Leopard

  - by carneades

  Update: After some more reading I see that this problem is totally general, you can't mix architectures in the same process, so 64 bit Java cannot dlopen() a 32 bit library like FMOD. Is there any possible workaround for this, keeping in mind I'm writing my own C interface to the FMOD library? I need to make a 64-bit dylib on Max OS X because Java Native Access only likes 64-bit libraries on 64-bit machines. The problem is, my C source code dynamically includes FMOD which on Mac only provides 32-bit dylibs. When I try to compile without the -m32 option (since I must output a 64-bit dylib) I get the following error: gcc -dynamiclib -std=c99 -pedantic -Wall -O3 -fPIC -pthread -o ../bin/libpenntotalrecall_fmod.dylib ../../src/libpenntotalrecall_fmod.c -lfmodex -L../../lib/osx/ ld: warning: in /usr/lib/libfmodex.dylib, missing required architecture x86_64 in file Undefined symbols: "_FMOD_System_CreateSound", referenced from: _startPlayback in ccJnlwrd.o "_FMOD_Channel_GetPosition", referenced from: _streamPosition in ccJnlwrd.o "_FMOD_System_Create", referenced from: _startPlayback in ccJnlwrd.o "_FMOD_System_PlaySound", referenced from: _startPlayback in ccJnlwrd.o "_FMOD_Sound_Release", referenced from: _stopPlayback in ccJnlwrd.o "_FMOD_Channel_IsPlaying", referenced from: _playbackInProgress in ccJnlwrd.o "_FMOD_System_Update", referenced from: _streamPosition in ccJnlwrd.o _startPlayback in ccJnlwrd.o "_FMOD_Channel_SetPaused", referenced from: _startPlayback in ccJnlwrd.o "_FMOD_System_Release", referenced from: _stopPlayback in ccJnlwrd.o "_FMOD_System_Init", referenced from: _startPlayback in ccJnlwrd.o "_FMOD_Channel_SetVolume", referenced from: _startPlayback in ccJnlwrd.o "_FMOD_System_Close", referenced from: _stopPlayback in ccJnlwrd.o "_FMOD_Channel_SetCallback", referenced from: _startPlayback in ccJnlwrd.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [all] Error 1 Shouldn't it be possible to get a 64 bit dylib from my source code that dynamically includes 32 bit libraries?!

  Read the article

• int considered harmful?

  - by Chris Becke

  Working on code meant to be portable between Win32 and Win64 and Cocoa, I am really struggling to get to grips with what the @#$% the various standards committees involved over the past decades were thinking when they first came up with, and then perpetuated, the crime against humanity that is the C native typeset - char, short, int and long. On the one hand, as a old-school c++ programmer, there are few statements that were as elegant and/or as simple as for(int i=0; i<some_max; i++) but now, it seems that, in the general case, this code can never be correct. Oh sure, given a particular version of MSVC or GCC, with specific targets, the size of 'int' can be safely assumed. But, in the case of writing very generic c/c++ code that might one day be used on 16 bit hardware, or 128, or just be exposed to a particularly weirdly setup 32/64 bit compiler, how does use int in c++ code in a way that the resulting program would have predictable behavior in any and all possible c++ compilers that implemented c++ according to spec. To resolve these unpredictabilities, C99 and C++98 introduced size_t, uintptr_t, ptrdiff_t, int8_t, int16_t, int32_t, int16_t and so on. Which leaves me thinking that a raw int, anywhere in pure c++ code, should really be considered harmful, as there is some (completely c++xx conforming) compiler, thats going to produce an unexpected or incorrect result with it. (and probably be a attack vector as well)

  Read the article

• Trouble compiling C/C++ project in NetBeans 6.8 with MinGW on Windows

  - by dontoo

  I am learning C and because VC++ 2008 doesn't support C99 features I have just installed NetBeans and configure it to work with MinGW. I can compile single file project ( main.c) and use debugger but when I add new file to project I get error "undefined reference to ... function(code) in that file..". Obviously MinGW does't link my files or I don't know how properly add them to my project (c standard library files work fine). /bin/make -f nbproject/Makefile-Debug.mk SUBPROJECTS= .build-conf make[1]: Entering directory `/c/Users/don/Documents/NetBeansProjects/CppApplication_7' /bin/make -f nbproject/Makefile-Debug.mk dist/Debug/MinGW-Windows/cppapplication_7.exe make[2]: Entering directory `/c/Users/don/Documents/NetBeansProjects/CppApplication_7' mkdir -p dist/Debug/MinGW-Windows gcc.exe -o dist/Debug/MinGW-Windows/cppapplication_7 build/Debug/MinGW-Windows/main.o build/Debug/MinGW-Windows/main.o: In function `main': C:/Users/don/Documents/NetBeansProjects/CppApplication_7/main.c:5: undefined reference to `X' collect2: ld returned 1 exit status make[2]: *** [dist/Debug/MinGW-Windows/cppapplication_7.exe] Error 1 make[2]: Leaving directory `/c/Users/don/Documents/NetBeansProjects/CppApplication_7' make[1]: *** [.build-conf] Error 2 make[1]: Leaving directory `/c/Users/don/Documents/NetBeansProjects/CppApplication_7' make: *** [.build-impl] Error 2 BUILD FAILED (exit value 2, total time: 1s) main.c #include "header.h" int main(int argc, char** argv) { X(); return (EXIT_SUCCESS); } header.h #ifndef _HEADER_H #define _HEADER_H #include <stdio.h> #include <stdlib.h> void X(void); #endif source.c #include "header.h" void X(void) { printf("dsfdas"); }

  Read the article

• C: 8x8 -> 16 bit multiply precision guaranteed by integer promotions?

  - by craig-blome

  I'm trying to figure out if the C Standard (C90, though I'm working off Derek Jones' annotated C99 book) guarantees that I will not lose precision multiplying two unsigned 8-bit values and storing to a 16-bit result. An example statement is as follows: unsigned char foo; unsigned int foo_u16 = foo * 10; Our Keil 8051 compiler (v7.50 at present) will generate a MUL AB instruction which stores the MSB in the B register and the LSB in the accumulator. If I cast foo to a unsigned int first: unsigned int foo_u16 = (unsigned int)foo * 10; then the compiler correctly decides I want a unsigned int there and generates an expensive call to a 16x16 bit integer multiply routine. I would like to argue beyond reasonable doubt that this defensive measure is not necessary. As I read the integer promotions described in 6.3.1.1, the effect of the first line shall be as if foo and 10 were promoted to unsigned int, the multiplication performed, and the result stored as unsigned int in foo_u16. If the compiler knows an instruction that does 8x8-16 bit multiplications without loss of precision, so much the better; but the precision is guaranteed. Am I reading this correctly? Best regards, Craig Blome

  Read the article

• gcc, strict-aliasing, and horror stories

  - by Joseph Quinsey

  In http://stackoverflow.com/questions/2906365/gcc-strict-aliasing-and-casting-through-a-union I asked whether anyone had encountered problems with union punning through pointers. So far, the answer seems to be No. This question is broader: do you have any horror stories about gcc and strict-aliasing? Background: Quoting from AndreyT's answer in http://stackoverflow.com/questions/2771023/c99-strict-aliasing-rules-in-c-gcc/2771041#2771041: "Strict aliasing rules are rooted in parts of the standard that were present in C and C++ since the beginning of [standardized] times. The clause that prohibits accessing object of one type through a lvalue of another type is present in C89/90 (6.3) as well as in C++98 (3.10/15). ... It is just that not all compilers wanted (or dared) to enforce it or rely on it." Well, gcc is now daring to do so, with its -fstrict-aliasing switch. And this has caused some problems. See, for example, the excellent article http://davmac.wordpress.com/2009/10/ about a Mysql bug, and the equally excellent discussion in http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html. Some other less-relevant links: http://stackoverflow.com/questions/1225741/performance-impact-of-fno-strict-aliasing http://stackoverflow.com/questions/754929/strict-aliasing http://stackoverflow.com/questions/262379/when-is-char-safe-for-strict-pointer-aliasing http://stackoverflow.com/questions/725138/how-to-detect-strict-aliasing-at-compile-time So to repeat, do you have a horror story of your own? Problems not indicated by -Wstrict-aliasing would, of course, be preferred. And other C compilers are also welcome.

  Read the article

• fesetround with MSVC x64

  - by mr grumpy

  I'm porting some code to Windows (sigh) and need to use fesetround. MSVC doesn't support C99, so for x86 I copied an implementation from MinGW and hacked it about: //__asm__ volatile ("fnstcw %0;": "=m" (_cw)); __asm { fnstcw _cw } _cw &= ~(FE_TONEAREST | FE_DOWNWARD | FE_UPWARD | FE_TOWARDZERO); _cw |= mode; //__asm__ volatile ("fldcw %0;" : : "m" (_cw)); __asm { fldcw _cw } if (has_sse) { unsigned int _mxcsr; //__asm__ volatile ("stmxcsr %0" : "=m" (_mxcsr)); __asm { stmxcsr _mxcsr } _mxcsr &= ~ 0x6000; _mxcsr |= (mode << __MXCSR_ROUND_FLAG_SHIFT); //__asm__ volatile ("ldmxcsr %0" : : "m" (_mxcsr)); __asm { ldmxcsr _mxcsr } } The commented lines are the originals for gcc; uncommented for msvc. This appears to work. However the x64 cl.exe doesn't support inline asm, so I'm stuck. Is there some code out there I can "borrow" for this? (I've spent hours with Google). Or will I have to go on a 2 week detour to learn some assembly and figure out how to get/use MASM? Any advice is appreciated. Thank you.

  Read the article

• scanf segfaults and various other anomalies inside while loop

  - by Shadow

  while(1){ //Command prompt char *command; printf("%s>",current_working_directory); scanf("%s",command);<--seg faults after input has been received. printf("\ncommand:%s\n",command); } I am getting a few different errors and they don't really seem reproducible(except for the segfault at this point .<). This code worked fine about 10 minutes ago, then it infinite looped the printf command and now it seg faults on the line mentioned above. The only thing I changed was scanf("%s",command); to what it currently is. If I change the command variable to be an array it works, obviously this is because the storage is set aside for it. 1) I got prosecuted about telling someone that they needed to malloc a pointer* (But that usually seems to solve the problem such as making it an array) 2) the command I am entering is "magic" 5 characters so there shouldn't be any crazy stack overflow. 3) I am running on mac OSX 10.6 with newest version of xCode(non-OS4) and standard gcc 4) this is how I compile the program: gcc --std=c99 -W sfs.c Just trying to figure out what is going on. Being this is for a school project I am never going to have to see again, I will just code some noob work around that would make my boss cry :) But for afterwards I would love to figure out why this is happening and not just make some fix for it, and if there is some fix for it why that fix works.

  Read the article

• Boost's "cstdint" Usage

  - by patt0h

  Boost's C99 stdint implementation is awfully handy. One thing bugs me, though. They dump all of their typedefs into the boost namespace. This leaves me with three choices when using this facility: Use "using namespace boost" Use "using boost::[u]<type><width>_t" Explicitly refer to the target type with the boost:: prefix; e.g., boost::uint32_t foo = 0; Option ? 1 kind of defeats the point of namespaces. Even if used within local scope (e.g., within a function), things like function arguments still have to be prefixed like option ? 3. Option ? 2 is better, but there are a bunch of these types, so it can get noisy. Option ? 3 adds an extreme level of noise; the boost:: prefix is often = to the length of the type in question. My question is: What would be the most elegant way to bring all of these types into the global namespace? Should I just write a wrapper around boost/cstdint.hpp that utilizes option ? 2 and be done with it? Also, wrapping the header like so didn't work on VC++ 10 (problems with standard library headers): namespace Foo { #include <boost/cstdint.hpp> using namespace boost; } using namespace Foo; Even if it did work, I guess it would cause ambiguity problems with the ::boost namespace.

  Read the article

• Would making plain int 64-bit break a lot of reasonable code?

  - by R..

  Until recently, I'd considered the decision by most systems implementors/vendors to keep plain int 32-bit even on 64-bit machines a sort of expedient wart. With modern C99 fixed-size types (int32_t and uint32_t, etc.) the need for there to be a standard integer type of each size 8, 16, 32, and 64 mostly disappears, and it seems like int could just as well be made 64-bit. However, the biggest real consequence of the size of plain int in C comes from the fact that C essentially does not have arithmetic on smaller-than-int types. In particular, if int is larger than 32-bit, the result of any arithmetic on uint32_t values has type signed int, which is rather unsettling. Is this a good reason to keep int permanently fixed at 32-bit on real-world implementations? I'm leaning towards saying yes. It seems to me like there could be a huge class of uses of uint32_t which break when int is larger than 32 bits. Even applying the unary minus or bitwise complement operator becomes dangerous unless you cast back to uint32_t. Of course the same issues apply to uint16_t and uint8_t on current implementations, but everyone seems to be aware of and used to treating them as "smaller-than-int" types.

  Read the article

• What limits scaling in this simple OpenMP program?

  - by Douglas B. Staple

  I'm trying to understand limits to parallelization on a 48-core system (4xAMD Opteron 6348, 2.8 Ghz, 12 cores per CPU). I wrote this tiny OpenMP code to test the speedup in what I thought would be the best possible situation (the task is embarrassingly parallel): // Compile with: gcc scaling.c -std=c99 -fopenmp -O3 #include <stdio.h> #include <stdint.h> int main(){ const uint64_t umin=1; const uint64_t umax=10000000000LL; double sum=0.; #pragma omp parallel for reduction(+:sum) for(uint64_t u=umin; u<umax; u++) sum+=1./u/u; printf("%e\n", sum); } I was surprised to find that the scaling is highly nonlinear. It takes about 2.9s for the code to run with 48 threads, 3.1s with 36 threads, 3.7s with 24 threads, 4.9s with 12 threads, and 57s for the code to run with 1 thread. Unfortunately I have to say that there is one process running on the computer using 100% of one core, so that might be affecting it. It's not my process, so I can't end it to test the difference, but somehow I doubt that's making the difference between a 19~20x speedup and the ideal 48x speedup. To make sure it wasn't an OpenMP issue, I ran two copies of the program at the same time with 24 threads each (one with umin=1, umax=5000000000, and the other with umin=5000000000, umax=10000000000). In that case both copies of the program finish after 2.9s, so it's exactly the same as running 48 threads with a single instance of the program. What's preventing linear scaling with this simple program?

  Read the article

• Can isdigit legitimately be locale dependent in C

  - by cdev

  In the section covering setlocale, the ANSI C standard states in a footnote that the only ctype.h functions whose behaviour is not affected by the current locale are isdigit and isxdigit. The Microsoft implementation of isdigit is locale dependent because, for example, in locales using code page 1250 isdigit only returns non-zero for characters in the range 0x30 ('0') - 0x39 ('9'), whereas in locales using code page 1252 isdigit also returns non-zero for the superscript digits 0xB2 ('²'), 0xB3 ('³') and 0xB9 ('¹'). Is Microsoft in violation of the C standard by making isdigit locale dependent? In this question I am primarily interested in C90, which Microsoft claims to conform to, rather than C99. Additional background: Microsoft's own documentation of setlocale incorrectly states that isdigit is unaffected by the LC_CTYPE part of the locale. The section of the C standard that covers the ctype.h functions contains some wording that I consider ambiguous: "The behavior of these functions is affected by the current locale. Those functions that have locale-specific aspects only when not in the "C" locale are noted below." I consider this ambiguous because it is unclear what it is trying to say about functions such as isdigit for which there are no notes about locale-specific aspects. It might be trying to say that such functions must be assumed to be locale dependent, in which case Microsoft's implementation of isdigit would be OK. (Except that the footnote I mentioned earlier seems to contradict this interpretation.)

  Read the article

• Why are argument substitutions not replaced during rescanning?

  - by James McNellis

  Consider the following macro definitions and invocation: #define x x[0] #define y(arg) arg y(x) This invocation expands to x[0] (tested on Visual C++ 2010, g++ 4.1, mcpp 2.7.2, and Wave). Why? Specifically, why does it not expand to x[0][0]? During macro replacement, A parameter in the replacement list...is replaced by the corresponding argument after all macros contained therein have been expanded. Before being substituted, each argument’s preprocessing tokens are completely macro replaced (C++03 §16.3.1/1). Evaluating the macro invocation, we take the following steps: The function-like macro y is invoked with x as the argument for its arg parameter The x in the argument is macro-replaced to become x[0] The arg in the replacement list is replaced by the macro-replaced value of the argument, x[0] The replacement list after substitution of all the parameters is x[0]. After all parameters in the replacement list have been substituted, the resulting preprocessing token sequence is rescanned...for more macro names to replace (C++03 §16.3.4/1). If the name of the macro being replaced is found during this scan of the replacement list...it is not replaced. Further, if any nested replacements encounter the name of the macro being replaced, it is not replaced (C++03 §16.3.4/2). The replacement list x[0] is rescanned (note that the name of the macro being replaced is y): x is identified as an object-like macro invocation x is replaced by x[0] Replacement stops at this point because of the rule in §16.3.4/2 preventing recursion. The replacement list after rescanning is x[0][0]. I have clearly misinterpreted something since all of the preprocessors I've tested say I am wrong. In addition, this example is a piece of a larger example in the C++0x FCD (at §16.3.5/5) and it too says that the expected replacement is x[0]. Why is x not replaced during rescanning? C99 and C++0x effectively have the same wording as C++03 in the quoted sections.

  Read the article

• Error "initializer element is not constant" when trying to initialize variable with const

  - by tomlogic

  I get an error on line 6 (initialize my_foo to foo_init) of the following program and I'm not sure I understand why. typedef struct foo_t { int a, b, c; } foo_t; const foo_t foo_init = { 1, 2, 3 }; foo_t my_foo = foo_init; int main() { return 0; } Keep in mind this is a simplified version of a larger, multi-file project I'm working on. The goal was to have a single constant in the object file, that multiple files could use to initialize a state structure. Since it's an embedded target with limited resources and the struct isn't that small, I don't want multiple copies of the source. I'd prefer not to use: #define foo_init { 1, 2, 3 } I'm also trying to write portable code, so I need a solution that's valid C89 or C99. Does this have to do with the ORGs in an object file? That initialized variables go into one ORG and are initialized by copying the contents of a second ORG? Maybe I'll just need to change my tactic, and have an initializing function do all of the copies at startup. Unless there are other ideas out there?

  Read the article

< Previous Page | 1 2 3 4 5  | Next Page >