search for: c90

On 1/14/19 6:15 AM, Richard W.M. Jones wrote: > When an ANSI/C90 plugin compiled with ‘-pedantic’ uses > NBDKIT_HANDLE_NOT_NEEDED it gets the error: > > ISO C forbids conversion of function pointer to object pointer type While POSIX requires it to work. But such is life. > > This is because the existing macro worked by returning a function &...

...xtension to C compilers of > + * the period. > + * > + * Therefore we rely here on the order of fields in struct > + * nbdkit_plugin. But that's OK because of nbdkit's stable ABI > + * guarantee. > + * > + * If you are really writing an nbdkit plugin which can only use C90 > + * then you are advised to find the extension to your compiler which > + * allows you to initialize named fields. > + */ > +static struct nbdkit_plugin plugin = { > + 0, 0, 0, I'd typically use NULL for pointers, but using 0 is strictly portable, so I'm fine with it. &g...

When an ANSI/C90 plugin compiled with ‘-pedantic’ uses NBDKIT_HANDLE_NOT_NEEDED it gets the error: ISO C forbids conversion of function pointer to object pointer type This is because the existing macro worked by returning a function pointer but in C90 function pointers cannot be cast to data pointers since on s...

On Fri, Jan 18, 2019 at 08:36:07AM -0600, Eric Blake wrote: > On 1/14/19 6:15 AM, Richard W.M. Jones wrote: > > When an ANSI/C90 plugin compiled with ‘-pedantic’ uses > > NBDKIT_HANDLE_NOT_NEEDED it gets the error: > > > > ISO C forbids conversion of function pointer to object pointer type > > While POSIX requires it to work. But such is life. > > > > > This is because the existin...

On 1/18/19 8:47 AM, Richard W.M. Jones wrote: > On Fri, Jan 18, 2019 at 08:36:07AM -0600, Eric Blake wrote: >> On 1/14/19 6:15 AM, Richard W.M. Jones wrote: >>> When an ANSI/C90 plugin compiled with ‘-pedantic’ uses >>> NBDKIT_HANDLE_NOT_NEEDED it gets the error: >>> >>> ISO C forbids conversion of function pointer to object pointer type >> >> While POSIX requires it to work. But such is life. >> >>> >>> This...

We previously discussed allowing the plugin API to be consumed by non-GCC/non-Clang/old compilers. This implements a test. Rich.

...labels. However it was a common extension to C compilers of + * the period. + * + * Therefore we rely here on the order of fields in struct + * nbdkit_plugin. But that's OK because of nbdkit's stable ABI + * guarantee. + * + * If you are really writing an nbdkit plugin which can only use C90 + * then you are advised to find the extension to your compiler which + * allows you to initialize named fields. + */ +static struct nbdkit_plugin plugin = { + 0, 0, 0, + "ansic", + 0, + PACKAGE_VERSION, + 0, + ansi_c_load, + 0, + 0, 0, 0, + ansi_c_open, + 0, + ansi_c_get_size,...

...]; /* COMPLICATED RECURSIVE ALGORITHM IN WHICH PP IS FILLED SNIPPED */ for(i=0 ; i < *n ; i++){ p[i] = (double) pp[i]; } } This compiles fine with "gcc -Wall" (and illustrates my point!) but R CMD check reports partitions.c:180: warning: ISO C90 does not support 'long long' partitions.c:181: warning: ISO C90 does not support 'long long' I really want long long integers here. What are my options? [the same happens with signed long long integers] -- Robin Hankin Uncertainty Analyst National Oceanography Centre, Sou...

...ns/CMakeFiles/clang_rt.builtins-x86_64.dir/x86_64/floatdidf.c.o In file included from /home/tthtlc/llvm/llvm/projects/compiler-rt/lib/builtins/x86_64/floatdidf.c:9:0: /home/tthtlc/llvm/llvm/projects/compiler-rt/lib/builtins/x86_64/../int_lib.h:131:8: error: C++ style comments are not allowed in ISO C90 [-Werror] #endif // defined(_MSC_VER) && !defined(__clang__) ^ /home/tthtlc/llvm/llvm/projects/compiler-rt/lib/builtins/x86_64/../int_lib.h:131:8: error: (this will be reported only once per input file) [-Werror] cc1: all warnings being treated as errors make[2]: *** [projects/comp...

Hi all. I've recently uploaded a package (bnlearn) to CRAN. It builds fine on both Linux (32 and 64 bit) and Windows, but fails on MacOSX ix86 because of C90 vs C99 issues: http://www.r-project.org/nosvn/R.check/r-patched-macosx-ix86/bnlearn-00install.html Since I've no MacOSX machine at hand, I would like to ask you: why is C99 not the default for gcc on MacOSX ix86? Is it safe to force gcc to use C99 with either -std=c99 o -std=gnu99? Thanks i...

...e Delta test or Polly), but oh so much more useful. Multi-dimensional VLAs happen, especially in scientific code. How are we going to express DGEMM (matrix multiplication)? We could do it by manually linearizing all the array references, or we could do it the way god intended when he standardized C90, with VLAs. I'm arguing that it would be wonderful to be able to analyze such code accurately. Regardest, Preston

...but oh so much more useful. > > Multi-dimensional VLAs happen, especially in scientific code. How are > we going to express DGEMM (matrix multiplication)? We could do it by > manually linearizing all the array references, or we could do it the > way god intended when he standardized C90, with VLAs. I'm arguing that > it would be wonderful to be able to analyze such code accurately. this would be a radical change to GEP, and as such would mean a huge amount of work. That said, being able to describe affine functions with locally constant multipliers in a nice and effective...

...for that. I do > think dropping "as fast as macros" from the "inline" description would > be a good idea, that's pure propaganda: sometimes it's true and > sometimes it isn't. I completely agree with you here. It looks like the GCC docs were written vs C90 not C99. That whole section of the documentation was more useful when there were a lot of GCC features we didn't support. Now it looks like it can be ripped out and we can just keep a list of things that don't work in our own words. Lets do this for the llvm 2.3 release notes tho...

Hi, I was trying to write printk statements in x86_emulate.c and I am getting following error. cc1: warnings being treated as errors x86_emulate.c: In function ''x86_emulate'': x86_emulate.c:2913: warning: ISO C90 forbids mixed declarations and code x86_emulate.c:2939: warning: ISO C90 forbids mixed declarations and code Yes, I know probably I can make changes in Makefile to remove strict checking option. Is there any work around for the same. -John _______________________________________________ Xen-use...

Hi, I was trying to write printk statements in x86_emulate.c and I am getting following error. cc1: warnings being treated as errors x86_emulate.c: In function ''x86_emulate'': x86_emulate.c:2913: warning: ISO C90 forbids mixed declarations and code x86_emulate.c:2939: warning: ISO C90 forbids mixed declarations and code Yes, I know probably I can make changes in Makefile to remove strict checking option. Is there any work around for the same. -John _______________________________________________ Xen-use...

...4 -I/usr/include/gdbm - I/usr/local/lib/perl5/5.8.8/i686-linux-thread-multi/CORE - I/usr/src/bristuff-0.3.0-PRE-1l/asterisk-1.2.4/ - I/usr/src/bristuff-0.3.0-PRE-1l/asterisk-1.2.4//include -I. -c AstAPIBase.c AstAPIBase.c: In function `asterisk_recordfile': AstAPIBase.c:435: warning: ISO C90 forbids mixed declarations and code AstAPIBase.c: In function `asterisk_request_and_dial': AstAPIBase.c:813: warning: passing arg 6 of `ast_request_and_dial' makes integer from pointer without a cast AstAPIBase.c:813: error: too few arguments to function `ast_request_and_dial' AstAP...

$ gcc -O2 -c -Woverlength-strings stupid.c stupid.c: In function ?insert_lf_record?: stupid.c:22: warning: string length ?7394? is greater than the length ?509? ISO C90 compilers are required to support Without -O2 the error message goes away. Even ISO C99 compilers don't help - they raise the limit to a mere 4095 bytes. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler....

...****************************************************** !! self.initialize_options() In file included from /usr/include/python3.12/Python.h:44, from xen/lowlevel/xc/xc.c:8: /usr/include/python3.12/object.h: In function ?Py_SIZE?: /usr/include/python3.12/object.h:233:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement] 233 | PyVarObject *var_ob = _PyVarObject_CAST(ob); | ^~~~~~~~~~~ In file included from /usr/include/python3.12/Python.h:53: /usr/include/python3.12/cpython/longintrepr.h: In function ?_PyLong_CompactValue?: /u...

...t;register" keyword, because > "I know what I am doing and you don't.....". What isn't kosher, is making side effects disappear from a C program. I'm not going to bother quoting C99 5.1.2.3/2,3 verbatim, as we already have Word of God (Duncan Sands) that the C99 (and C90) standard's requirements on volatile are intentionally being violated. Kenneth

The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible a...