Search Results

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

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

• Should I use C(99) booleans ? ( also c++ booleans in c++ ?)

  - by Roman A. Taycher

  I haven't done much c programming but when I do when I need a false I put 0 when I want true I put 1, (ex. while(1)), in other cases I use things like "while(ptr)" or "if(x)". Should I try using C99 booleans, should I recommend them to others if I'm helping people new to programming learn c basics(thinking of cs 1?? students)? I'm pretty sure the Visual Studio compiler supports c99 bools, but do a lot of projects (open source and c apps in industry) compile for c89? If I don't use C bools should I at least do something like #define TRUE 1 #define FALSE 0? Also what about c++ Booleans (for c++)?

  Read the article

• getaddrinfo is not statically compiled

  - by bobby

  I have included the header netdb.h, where getaddrinfo is included, but gcc issues this warning: warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking gcc -m32 -static -s -O2 -std=c99 -D_POSIX_C_SOURCE=200112L myprogram.c How can I statically compile whatever file is missing ?

  Read the article

• C variable declarations after function heading in definition

  - by Yktula

  When reading some FreeBSD source code (See: radix.h lines 158-173), I found variable declarations that followed the "function heading" in the definition. Is this valid in ISO C (C99)? when should this be done in production code instead of just declaring the variables within the "function heading?" Why is it being done here? I refer to the function heading the string that looks like this: int someFunction(int i, int b) {

  Read the article

• MinGW error "undefined reference to 'typeof''"

  - by DSblizzard

  Code: #include <stdio.h> #include <stdlib.h> #include <stddef.h> int main() { typeof(5); return 0; } Version of gcc is 4.3.3, command line is "gcc.exe -std=c99 1.c -o 1.exe". What is the cause of this problem?

  Read the article

• Is the next C standard actively developed?

  - by wwwww

  Is there currently a group working on the next C standard (by next, I mean after C99)? If so, what are the features likely to make it in?

  Read the article

• Which functions in the C standard library commonly encourage bad practice?

  - by Ninefingers

  Hello all, This is inspired by this question and the comments on one particular answer in that I learnt that strncpy is not a very safe string handling function in C and that it pads zeros, until it reaches n, something I was unaware of. Specifically, to quote R.. strncpy does not null-terminate, and does null-pad the whole remainder of the destination buffer, which is a huge waste of time. You can work around the former by adding your own null padding, but not the latter. It was never intended for use as a "safe string handling" function, but for working with fixed-size fields in Unix directory tables and database files. snprintf(dest, n, "%s", src) is the only correct "safe strcpy" in standard C, but it's likely to be a lot slower. By the way, truncation in itself can be a major bug and in some cases might lead to privilege elevation or DoS, so throwing "safe" string functions that truncate their output at a problem is not a way to make it "safe" or "secure". Instead, you should ensure that the destination buffer is the right size and simply use strcpy (or better yet, memcpy if you already know the source string length). And from Jonathan Leffler Note that strncat() is even more confusing in its interface than strncpy() - what exactly is that length argument, again? It isn't what you'd expect based on what you supply strncpy() etc - so it is more error prone even than strncpy(). For copying strings around, I'm increasingly of the opinion that there is a strong argument that you only need memmove() because you always know all the sizes ahead of time and make sure there's enough space ahead of time. Use memmove() in preference to any of strcpy(), strcat(), strncpy(), strncat(), memcpy(). So, I'm clearly a little rusty on the C standard library. Therefore, I'd like to pose the question: What C standard library functions are used inappropriately/in ways that may cause/lead to security problems/code defects/inefficiencies? In the interests of objectivity, I have a number of criteria for an answer: Please, if you can, cite design reasons behind the function in question i.e. its intended purpose. Please highlight the misuse to which the code is currently put. Please state why that misuse may lead towards a problem. I know that should be obvious but it prevents soft answers. Please avoid: Debates over naming conventions of functions (except where this unequivocably causes confusion). "I prefer x over y" - preference is ok, we all have them but I'm interested in actual unexpected side effects and how to guard against them. As this is likely to be considered subjective and has no definite answer I'm flagging for community wiki straight away. I am also working as per C99.

  Read the article

• Microsoft veut rendre Visual C++ conforme aux standards C++, la roadmap de Visual Studio 2013 inclut le support complet de C99, C++11 et C++14

  Microsoft veut rendre Visual Studio conforme aux standards C++ la roadmap de Visual Studio 2013 inclut le support complet de C99, C++11 et C++14 Lors de la conférence Build la semaine dernière, Microsoft a publié une préversion de Visual Studio 2013, la prochaine version majeure de son environnement de développement.Cette version sort pratiquement un an après la publication de Visual Studio 2012, montrant la volonté de Microsoft d'adopter un cycle de libération plus rapide pour l'ensemble de ses produits phares.Ce nouveau cycle de publication permet désormais à l'équipe C++ de fournir rapidement une prise en charge des normes C++. Herb Sutter, président du comité C++ et employé chez Microsoft, ...

  Read the article

• How do I do a game loop in c99?

  - by linitbuff

  I'm having trouble with how to structure a game using c99. I've seen a few tutorials on making a game loop, but they are all done with c++ and classes. My main problem seems to be moving data around between the functions without creating a mess, and what stuff to put in what header files etc. Do I just do something similar to the c++ loops, and create a class-like header with a structure containing all items needed by more than one of the functions, along with the prototypes of said functions, and include the header in each function's header file? Then, in the main function, instantiate the structure and pass a pointer to it to every function in the loop? Is this ok, or is there a better way to do it, and are there any good 'c' specific tutorials available? Cheers

  Read the article

• va_arg with pointers

  - by Yktula

  I want to initialize a linked list with pointer arguments like so: /* * Initialize a linked list using variadic arguments * Returns the number of structures initialized */ int init_structures(struct structure *first, ...) { struct structure *s; unsigned int count = 0; va_list va; va_start(va, first); for (s = first; s != NULL; s = va_arg(va, (struct structure *))) { if ((s = malloc(sizeof(struct structure))) == NULL) { perror("malloc"); exit(EXIT_FAILURE); } count++; } va_end(va); return count; } The problem is that clang errors type name requires a specifier or qualifier at va_arg(va, (struct structure *)), and says that the type specifier defaults to int. It also notes instantiated form at (struct structure *) and struct structure *. This, what seems to be getting assigned to s is int (struct structure *). It compiles fine when parentheses are removed from (struct structure *), but the structures that are supposed to be initialized are inaccessible. Why is int assumed when parentheses are around the type argument passed to va_arg? How can I fix this?

  Read the article

• Is there a general-purpose printf-ish routine defined in any C standard

  - by supercat

  In many C libraries, there is a printf-style routine which is something like the following: int __vgprintf(void *info, (void)(*print_function(void*, char)), const char *format, va_list params); which will format the supplied string and call print_function with the passed-in info value and each character in sequence. A function like fprintf will pass __vgprintf the passed-in file parameter and a pointer to a function which will cast its void* to a FILE* and output the passed-in character to that file. A function like snprintf will create a struct holding a char* and length, and pass the address of that struct to a function which will output each character in sequence, space permitting. Is there any standard for such a function, which could be used if e.g. one wanted a function to output an arbitrary format to a TCP port? A common approach is to allocate a buffer one hopes is big enough, use snprintf to put the data there, and then output the data from the buffer. It would seem cleaner, though, if there were a standard way to to specify that the print formatter should call a user-supplied routine with each character.

  Read the article

• C, reading multiple numbers from single input line (scanf?)

  - by michal

  Hi, I'm writing an app in pure C which expects two line at input: first one, which tells how big an array of int will be, and the second, which contains values, separated by space. So, for the following input 5 1 2 3 4 99 I need to create an array containing {1,2,3,4,99} Now, my question is - what is the fastest (yet easy ;)) way to do so? My problem is "how to read multiple numbers without looping through the whole string checking if it's space or a number" ? Thanks m.

  Read the article

• How to auto-sync Header in Visual Studio ?

  - by fk2

  Do you know if there is a build-in feature or free add-in for Microsoft Visual Studio 2008 that easily generates C-Headers and keeps them in sync with their .c counterparts? I have already looked at Visual Assist X, but I'm not really willing to pay money at the moment.

  Read the article

• Generating 2-dimensional vla ends in segmentation fault

  - by Framester

  Hi, further developing the code from yesterday (seg fault caused by malloc and sscanf in a function), I tried with the help of some tutorials I found on the net to generate a 2-dim vla. But I get a segmentation fault at (*data)[i][j]=atof(p);. The program is supposed to read a matrix out of a text file and load it into a 2d array (cols 1-9) and a 1D array (col 10) [Example code] #include<stdio.h> #include<stdlib.h> #include<math.h> #include<string.h> const int LENGTH = 1024; void read_data(float ***data, int **classes, int *nrow,int *ncol, char *filename){ FILE *pfile = NULL; char line[LENGTH]; if(!( pfile=fopen(filename,"r"))){ printf("Error opening %s.", filename); exit(1); } int numlines=0; int numcols=0; char *p; fgets(line,LENGTH,pfile); p = strtok (line," "); while (p != NULL){ p = strtok (NULL, ", "); numcols++; } while(fgets(line,LENGTH,pfile)){ numlines++; } rewind(pfile); int numfeats=numcols-1; *data=(float**) malloc(numlines*sizeof(float*)); *classes=(int *)malloc(numlines*sizeof(int)); if(*classes == NULL){ printf("\nOut of memory."); exit(1); } int i=0; while(fgets(line,LENGTH,pfile)){ p = strtok (line," "); for(int j=0;j<numfeats;j++) { (data)[i]=malloc(numfeats*sizeof(float)); printf("%i ",i); (*data)[i][j]=atof(p); p = strtok (NULL, ", "); } (*classes)[i]=atoi(p); i++; } fclose(pfile); *nrow=numlines; *ncol=numfeats; } int main() { char *filename="somedatafile.txt"; float **data2; int *classes2; int r,c; read_data(&data2,&classes2, &r, &c,filename) ; for(int i=0;i<r;i++){ printf("\n"); for(int j=0;j<c;j++){ printf("%f",data2[i][j]); } } return 1; } [Content of somedatafile.txt] 50 21 77 0 28 0 27 48 22 2 55 0 92 0 0 26 36 92 56 4 53 0 82 0 52 -5 29 30 2 1 37 0 76 0 28 18 40 48 8 1 37 0 79 0 34 -26 43 46 2 1 85 0 88 -4 6 1 3 83 80 5 56 0 81 0 -4 11 25 86 62 4 55 -1 95 -3 54 -4 40 41 2 1 53 8 77 0 28 0 23 48 24 4 37 0 101 -7 28 0 64 73 8 1 ...

  Read the article

• Variable Length Array

  - by corinaf

  Hello, I would like to know how a variable length array is managed (what extra variables or data structures are kept on the stack in order to have variable length arrays). Thanks a lot.

  Read the article

• C1x : future version du langage C, le nouveau Release 4.6 de GCC intègre déjà certaines de ses fonctionnalités

  C1x : future version du langage C Le nouveau Release de GCC intègre déjà certaines de ses fonctionnalités La nouvelle ne date pas d'hier, mais pour ceux qui ne sont pas encore au courant, une nouvelle version du C est en fait en cours d'élaboration et le dernier release de GCC (du 26 octobre 2011) intègre même déjà certaines de ses fonctionnalités. Ce langage, couramment appelé C1x, est destiné à remplacer le C99, le standard actuel. Il est clair que le C99 a terriblement été un échec, notamment en raison du choix de Microsoft de ne pas le supporter. Mais ce n'est pas tout. Le C99 a peut-être aussi échoué parce qu'il n'apportait rien qui soit véritablement essentiel au langage.

  Read the article

• Use of c89 in GNU software

  - by Federico Culloca

  In GNU coding standard it is said that free software developer should use C89 because C99 is not widespread yet. 1999 Standard C is not widespread yet, so please do not require its features in programs. Reference here. Are they talking about developers knowledge of C99, or about compilers supporting it? Also, is this statement plausible as of today or is it somewhat "obsolete" or at least obsolescent.

  Read the article

• Why do old programming languages continue to be revised?

  - by SunAvatar

  This question is not, "Why do people still use old programming languages?" I understand that quite well. In fact the two programming languages I know best are C and Scheme, both of which date back to the 70s. Recently I was reading about the changes in C99 and C11 versus C89 (which seems to still be the most-used version of C in practice and the version I learned from K&R). Looking around, it seems like every programming language in heavy use gets a new specification at least once per decade or so. Even Fortran is still getting new revisions, despite the fact that most people using it are still using FORTRAN 77. Contrast this with the approach of, say, the typesetting system TeX. In 1989, with the release of TeX 3.0, Donald Knuth declared that TeX was feature-complete and future releases would contain only bug fixes. Even beyond this, he has stated that upon his death, "all remaining bugs will become features" and absolutely no further updates will be made. Others are free to fork TeX and have done so, but the resulting systems are renamed to indicate that they are different from the official TeX. This is not because Knuth thinks TeX is perfect, but because he understands the value of a stable, predictable system that will do the same thing in fifty years that it does now. Why do most programming language designers not follow the same principle? Of course, when a language is relatively new, it makes sense that it will go through a period of rapid change before settling down. And no one can really object to minor changes that don't do much more than codify existing pseudo-standards or correct unintended readings. But when a language still seems to need improvement after ten or twenty years, why not just fork it or start over, rather than try to change what is already in use? If some people really want to do object-oriented programming in Fortran, why not create "Objective Fortran" for that purpose, and leave Fortran itself alone? I suppose one could say that, regardless of future revisions, C89 is already a standard and nothing stops people from continuing to use it. This is sort of true, but connotations do have consequences. GCC will, in pedantic mode, warn about syntax that is either deprecated or has a subtly different meaning in C99, which means C89 programmers can't just totally ignore the new standard. So there must be some benefit in C99 that is sufficient to impose this overhead on everyone who uses the language. This is a real question, not an invitation to argue. Obviously I do have an opinion on this, but at the moment I'm just trying to understand why this isn't just how things are done already. I suppose the question is: What are the (real or perceived) advantages of updating a language standard, as opposed to creating a new language based on the old?

  Read the article

• Division by zero: Undefined Behavior or Implementation Defined in C and/or C++ ?

  - by SiegeX

  Regarding division by zero, the standards say: C99 6.5.5p5 - The result of the / operator is the quotient from the division of the first operand by the second; the result of the % operator is the remainder. In both operations, if the value of the second operand is zero, the behavior is undefined. C++03 5.6.4 - The binary / operator yields the quotient, and the binary % operator yields the remainder from the division of the first expression by the second. If the second operand of / or % is zero the behavior is undefined. If we were to take the above paragraphs at face value, the answer is clearly Undefined Behavior for both languages. However, if we look further down in the C99 standard we see the following paragraph which appears to be contradictory(1): C99 7.12p4 - The macro INFINITY expands to a constant expression of type float representing positive or unsigned infinity, if available; Do the standards have some sort of golden rule where Undefined Behavior cannot be superseded by a (potentially) contradictory statement? Barring that, I don't think it's unreasonable to conclude that if your implementation defines the INFINITY macro, division by zero is defined to be such. However, if your implementation does not define such a macro, the behavior is Undefined. I'm curious what the consensus on this matter for each of the two languages. Would the answer change if we are talking about integer division int i = 1 / 0 versus floating point division float i = 1.0 / 0.0 ? Note (1) The C++03 standard talks about the library which includes the INFINITY macro.

  Read the article

• gcc, strict-aliasing, and casting through a union

  - by Joseph Quinsey

  About a year ago the following paragraph was added to the GCC Manual, version 4.3.4, regarding -fstrict-aliasing: Similarly, access by taking the address, casting the resulting pointer and dereferencing the result has undefined behavior [emphasis added], even if the cast uses a union type, e.g.: union a_union { int i; double d; }; int f() { double d = 3.0; return ((union a_union *)&d)->i; } Does anyone have an example to illustrate this undefined behavior? Note this question is not about what the C99 standard says, or does not say. It is about the actual functioning of gcc, and other existing compilers, today. My simple, naive, attempt fails. For example: #include <stdio.h> union a_union { int i; double d; }; int f1(void) { union a_union t; t.d = 3333333.0; return t.i; // gcc manual: 'type-punning is allowed, provided ...' } int f2(void) { double d = 3333333.0; return ((union a_union *)&d)->i; // gcc manual: 'undefined behavior' } int main(void) { printf("%d\n", f1()); printf("%d\n", f2()); return 0; } works fine, giving on CYGWIN: -2147483648 -2147483648 Also note that taking addresses is obviously wrong (or right, if you are trying to illustrate undefined behavior). For example, just as we know this is wrong: extern void foo(int *, double *); union a_union t; t.d = 3.0; foo(&t.i, &t.d); // UD behavior so is this wrong: extern void foo(int *, double *); double d = 3.0; foo(&((union a_union *)&d)->i, &d); // UD behavior For background discussion about this, see for example: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf http://gcc.gnu.org/ml/gcc/2010-01/msg00013.html http://davmac.wordpress.com/2010/02/26/c99-revisited/ http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule http://stackoverflow.com/questions/2771023/c99-strict-aliasing-rules-in-c-gcc/2771041#2771041 The first link, draft minutes of an ISO meeting seven months ago, notes in section 4.16: Is there anybody that thinks the rules are clear enough? No one is really able to interpret tham.

  Read the article

• Correct redirect after posting comment - django comments framework

  - by Sachin

  I am using django comments framework for allowing users to comment on my site, but there is a problem with the url to which user is redirected after posting the comment. If I render my comment form as {% with comment.content_object.get_absolute_url as next %} {% render_comment_form for comment.content_object %} {% endwith %} Then the url to which it is redirected after the comment is posted is <comment.content_object.get_absolute_url/?c=<comment.id> For example I posted a comment on a post with url /post/256/a-new-post/ then the url to which I am redirected after posting the comment is /post/256/a-new-post/?c=99 where assume 99 is the id comment just posted. Instead what I want is something like this /post/256/a-new-post/#c99. Secondly when I do comment.get_absolute_url() I do not get the proper url instead I get a url like /comments/cr/58/14/#c99 and this link is broken. How can I get the correct url as mentioned in the documentation. Am i doing something wrong. Any help is appreciated.

  Read the article

• Compatible types and structures in C

  - by Oli Charlesworth

  I have the following code: int main(void) { struct { int x; } a, b; struct { int x; } c; struct { int x; } *p; b = a; /* OK */ c = a; /* Doesn't work */ p = &a; /* Doesn't work */ return 0; } which fails to compile under GCC (3.4.6), with the following error: test.c:8: error: incompatible types in assignment test.c:9: warning: assignment from incompatible pointer type Now, from what I understand (admittedly from the C99 standard), is that a and c should be compatible types, as they fulfill all the criteria in section 6.2.7, paragraph 1. I've tried compiling with std=c99, to no avail. Presumably my interpretation of the standard is wrong?

  Read the article

• What you cant do in C that you can do in Objective-C?

  - by Ole Jak

  What you cant do in C (C99 standard) that you can do in Objectivee-C? (with code example if you please)

  Read the article

• Error compiling GLib in Ubuntu 14.04 (trying to install GimpShop)

  - by Nicolás Salvarrey

  I'm kinda new in Linux, so please take it easy on the most complicated stuff. I'm trying to install GimpShop. Installation guide asks me to install GLib first, and when I try to compile it using the make command I get errors. When I run the ./configure --prefix=/usr command, I get this: checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether to enable maintainer-specific portions of Makefiles... no checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for the BeOS... no checking for Win32... no checking whether to enable garbage collector friendliness... no checking whether to disable memory pools... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of gcc... gcc3 checking for c++... no checking for g++... no checking for gcc... gcc checking whether we are using the GNU C++ compiler... no checking whether gcc accepts -g... no checking dependency style of gcc... gcc3 checking for gcc option to accept ANSI C... none needed checking for a BSD-compatible install... /usr/bin/install -c checking for special C compiler options needed for large files... no checking for _FILE_OFFSET_BITS value needed for large files... no checking for _LARGE_FILES value needed for large files... no checking for pkg-config... /usr/bin/pkg-config checking for gawk... (cached) mawk checking for perl5... no checking for perl... perl checking for indent... no checking for perl... /usr/bin/perl checking for iconv_open... yes checking how to run the C preprocessor... gcc -E checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes checking for ngettext in libc... yes checking for dgettext in libc... yes checking for bind_textdomain_codeset... yes checking for msgfmt... /usr/bin/msgfmt checking for dcgettext... yes checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for catalogs to be installed... am ar az be bg bn bs ca cs cy da de el en_CA en_GB eo es et eu fa fi fr ga gl gu he hi hr id is it ja ko lt lv mk mn ms nb ne nl nn no or pa pl pt pt_BR ro ru sk sl sq sr sr@ije sr@Latn sv ta tl tr uk vi wa xh yi zh_CN zh_TW checking for a sed that does not truncate output... /bin/sed checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for /usr/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for epcf90... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for gfortran... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/nm -B output from gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if gcc static flag works... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc supports -c -o file.o... yes checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool appending configuration tag "F77" to libtool checking for extra flags to get ANSI library prototypes... none needed checking for extra flags for POSIX compliance... none needed checking for ANSI C header files... (cached) yes checking for vprintf... yes checking for _doprnt... no checking for working alloca.h... yes checking for alloca... yes checking for atexit... yes checking for on_exit... yes checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for long... yes checking size of long... 8 checking for int... yes checking size of int... 4 checking for void *... yes checking size of void *... 8 checking for long long... yes checking size of long long... 8 checking for __int64... no checking size of __int64... 0 checking for format to printf and scanf a guint64... %llu checking for an ANSI C-conforming const... yes checking if malloc() and friends prototypes are gmem.h compatible... no checking for growing stack pointer... yes checking for __inline... yes checking for __inline__... yes checking for inline... yes checking if inline functions in headers work... yes checking for ISO C99 varargs macros in C... yes checking for ISO C99 varargs macros in C++... no checking for GNUC varargs macros... yes checking for GNUC visibility attribute... yes checking whether byte ordering is bigendian... no checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking float.h usability... yes checking float.h presence... yes checking for float.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking pwd.h usability... yes checking pwd.h presence... yes checking for pwd.h... yes checking sys/param.h usability... yes checking sys/param.h presence... yes checking for sys/param.h... yes checking sys/poll.h usability... yes checking sys/poll.h presence... yes checking for sys/poll.h... yes checking sys/select.h usability... yes checking sys/select.h presence... yes checking for sys/select.h... yes checking for sys/types.h... (cached) yes checking sys/time.h usability... yes checking sys/time.h presence... yes checking for sys/time.h... yes checking sys/times.h usability... yes checking sys/times.h presence... yes checking for sys/times.h... yes checking for unistd.h... (cached) yes checking values.h usability... yes checking values.h presence... yes checking for values.h... yes checking for stdint.h... (cached) yes checking sched.h usability... yes checking sched.h presence... yes checking for sched.h... yes checking langinfo.h usability... yes checking langinfo.h presence... yes checking for langinfo.h... yes checking for nl_langinfo... yes checking for nl_langinfo and CODESET... yes checking whether we are using the GNU C Library 2.1 or newer... yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for setlocale... yes checking for size_t... yes checking size of size_t... 8 checking for the appropriate definition for size_t... unsigned long checking for lstat... yes checking for strerror... yes checking for strsignal... yes checking for memmove... yes checking for mkstemp... yes checking for vsnprintf... yes checking for stpcpy... yes checking for strcasecmp... yes checking for strncasecmp... yes checking for poll... yes checking for getcwd... yes checking for nanosleep... yes checking for vasprintf... yes checking for setenv... yes checking for unsetenv... yes checking for getc_unlocked... yes checking for readlink... yes checking for symlink... yes checking for C99 vsnprintf... yes checking whether printf supports positional parameters... yes checking for signed... yes checking for long long... (cached) yes checking for long double... yes checking for wchar_t... yes checking for wint_t... yes checking for size_t... (cached) yes checking for ptrdiff_t... yes checking for inttypes.h... yes checking for stdint.h... yes checking for snprintf... yes checking for C99 snprintf... yes checking for sys_errlist... yes checking for sys_siglist... yes checking for sys_siglist declaration... yes checking for fd_set... yes, found in sys/types.h checking whether realloc (NULL,) will work... yes checking for nl_langinfo (CODESET)... yes checking for OpenBSD strlcpy/strlcat... no checking for an implementation of va_copy()... yes checking for an implementation of __va_copy()... yes checking whether va_lists can be copied by value... no checking for dlopen... no checking for NSLinkModule... no checking for dlopen in -ldl... yes checking for dlsym in -ldl... yes checking for RTLD_GLOBAL brokenness... no checking for preceeding underscore in symbols... no checking for dlerror... yes checking for the suffix of shared libraries... .so checking for gspawn implementation... gspawn.lo checking for GIOChannel implementation... giounix.lo checking for platform-dependent source... checking whether to compile timeloop... yes checking if building for some Win32 platform... no checking for thread implementation... posix checking thread related cflags... -pthread checking for sched_get_priority_min... yes checking thread related libraries... -pthread checking for localtime_r... yes checking for posix getpwuid_r... yes checking size of pthread_t... 8 checking for pthread_attr_setstacksize... yes checking for minimal/maximal thread priority... sched_get_priority_min(SCHED_OTHER)/sched_get_priority_max(SCHED_OTHER) checking for pthread_setschedparam... yes checking for posix yield function... sched_yield checking size of pthread_mutex_t... 40 checking byte contents of PTHREAD_MUTEX_INITIALIZER... 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 checking whether to use assembler code for atomic operations... x86_64 checking value of POLLIN... 1 checking value of POLLOUT... 4 checking value of POLLPRI... 2 checking value of POLLERR... 8 checking value of POLLHUP... 16 checking value of POLLNVAL... 32 checking for EILSEQ... yes configure: creating ./config.status config.status: creating glib-2.0.pc config.status: creating glib-2.0-uninstalled.pc config.status: creating gmodule-2.0.pc config.status: creating gmodule-no-export-2.0.pc config.status: creating gmodule-2.0-uninstalled.pc config.status: creating gthread-2.0.pc config.status: creating gthread-2.0-uninstalled.pc config.status: creating gobject-2.0.pc config.status: creating gobject-2.0-uninstalled.pc config.status: creating glib-zip config.status: creating glib-gettextize config.status: creating Makefile config.status: creating build/Makefile config.status: creating build/win32/Makefile config.status: creating build/win32/dirent/Makefile config.status: creating glib/Makefile config.status: creating glib/libcharset/Makefile config.status: creating glib/gnulib/Makefile config.status: creating gmodule/Makefile config.status: creating gmodule/gmoduleconf.h config.status: creating gobject/Makefile config.status: creating gobject/glib-mkenums config.status: creating gthread/Makefile config.status: creating po/Makefile.in config.status: creating docs/Makefile config.status: creating docs/reference/Makefile config.status: creating docs/reference/glib/Makefile config.status: creating docs/reference/glib/version.xml config.status: creating docs/reference/gobject/Makefile config.status: creating docs/reference/gobject/version.xml config.status: creating tests/Makefile config.status: creating tests/gobject/Makefile config.status: creating m4macros/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing default-1 commands config.status: executing glibconfig.h commands config.status: glibconfig.h is unchanged config.status: executing chmod-scripts commands nsalvarrey@Delleuze:~/glib-2.6.3$ ^C nsalvarrey@Delleuze:~/glib-2.6.3$ And then, with the make command, I get this: galias.h:83:39: error: 'g_ascii_digit_value' aliased to undefined symbol 'IA__g_ascii_digit_value' extern __typeof (g_ascii_digit_value) g_ascii_digit_value __attribute((alias("IA__g_ascii_digit_value"), visibility("default"))); ^ In file included from garray.c:35:0: galias.h:31:35: error: 'g_allocator_new' aliased to undefined symbol 'IA__g_allocator_new' extern __typeof (g_allocator_new) g_allocator_new __attribute((alias("IA__g_allocator_new"), visibility("default"))); ^ make[4]: *** [garray.lo] Error 1 make[4]: se sale del directorio «/home/nsalvarrey/glib-2.6.3/glib» make[3]: *** [all-recursive] Error 1 make[3]: se sale del directorio «/home/nsalvarrey/glib-2.6.3/glib» make[2]: *** [all] Error 2 make[2]: se sale del directorio «/home/nsalvarrey/glib-2.6.3/glib» make[1]: *** [all-recursive] Error 1 make[1]: se sale del directorio «/home/nsalvarrey/glib-2.6.3» make: *** [all] Error 2 nsalvarrey@Delleuze:~/glib-2.6.3$ (it's actually a lot longer) Can somebody help me?

  Read the article

• What is meant by Scope of a variable?

  - by Appy

  I think of the scope of a variable as - "The scope of a particular variable is the range within a program's source code in which that variable is recognized by the compiler". That statement is from "Scope and Lifetime of Variables in C++", which I read many months ago. Recently I came across this in LeMoyne-Owen College courses: What exactly is the difference between the scope of variables in C# and (C99, C++, Java) when However a variable still must be declared before it can be used

  Read the article

• Using macro to check null values [migrated]

  - by poliron

  My C code contains many functions with pointers to different structs as parameteres which shouldn't be NULL pointers. To make my code more readable, I decided to replace this code: if(arg1==NULL || arg2==NULL || arg3==NULL...) { return SOME_ERROR; } With that macro: NULL_CHECK(arg1,arg2,...) How should I write it, if the number of args is unknown and they can point to different structs?(I work in C99)

  Read the article

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