For example,

    int result;
    
    result = 125/100;

or 

    result = 43/100;

Will result always be the floor of the division? What is the defined behavior?

What is the behavior of integer division?

I was browsing through some documentation and questions/answers and saw it mentioned. I read a brief description, stating that it would be basically a promise from the programmer that the pointer won&#39;t be used to point somewhere else. 

Can anyone offer some realistic cases where its worth actually using this?

Realistic usage of the C99 &#39;restrict&#39; keyword?

There is a [well-known][1] [problem][2] with empty args for variadic macros in C99.

example:

    #define FOO(...)       printf(__VA_ARGS__)
    #define BAR(fmt, ...)  printf(fmt, __VA_ARGS__)

    FOO(&quot;this works fine&quot;);
    BAR(&quot;this breaks!&quot;);

The use of `BAR()` above is indeed incorrect according to the C99 standard, since it will expand to:

    printf(&quot;this breaks!&quot;,);

Note the trailing comma - not workable.

Some compilers (eg: Visual Studio 2010) will quietly get rid of that trailing comma for you. Other compilers (eg: GCC) support putting `##` in front of `__VA_ARGS__`, like so:

    #define BAR(fmt, ...)  printf(fmt, ##__VA_ARGS__)

But is there a standards-compliant way to get this behavior?
Perhaps using multiple macros?

Right now, the `##` version seems fairly well-supported (at least on my platforms), but I&#39;d really rather use a standards-compliant solution.

Pre-emptive: I know I could just write a small function. I&#39;m trying to do this using macros.

__Edit__: Here is an example (though simple) of why I would want to use BAR():

    #define BAR(fmt, ...)  printf(fmt &quot;\n&quot;, ##__VA_ARGS__)
    
    BAR(&quot;here is a log message&quot;);
    BAR(&quot;here is a log message with a param: %d&quot;, 42);

This automatically adds a newline to my BAR() logging statements, assuming `fmt` is always a double-quoted C-string. It does NOT print the newline as a separate printf(), which is advantageous if the logging is line-buffered and coming from multiple sources asynchronously.



  [1]: https://stackoverflow.com/questions/4054085/gcc-appending-to-va-args
  [2]: http://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html

Standard alternative to GCC&#39;s ##__VA_ARGS__ trick?

How portable is this conversion. Can I be sure that both assertions pass?

    int x = 4&lt;5;
    assert(x==1);
    
    x = 4&gt;5;
    assert(x==0);

Don&#39;t ask why. I know that it is ugly. Thank you.

bool to int conversion

    static struct fuse_oprations hello_oper = {
      .getattr = hello_getattr,
      .readdir = hello_readdir,
      .open    = hello_open,
      .read    = hello_read,
    };

I don&#39;t understand this C syntax well. I can&#39;t even search because I don&#39;t know the syntax&#39;s name. What&#39;s that?

What does dot (.) mean in a struct initializer?

I have started programming practice on [codechef][1] and have been confused by the **difference between C and C99. What does C mean here? Is it C89?** Check the languages at the bottom of [this submit][2]. It contains both C and C99.

I found on the internet something called GNU C. Is there a different C for linux/unix systems? Are these compliant to the C standards by ANSI? I have also read in some places &quot;C99 strict&quot;. What is this?

Are there any other different standards of C in use? Is there something called C 4.3.2 or is it the gcc version in current use?

EDIT:&lt;br/&gt;

 [This][3], [This][4], [This][5] helped. I&#39;ll search more and edit the things that are left unanswered.

I am not a programming newbie. I know what C language is. I know that there are the different C standards by ANSI like C89, C99 and C11.


  [1]: http://www.codechef.com/problems/easy?sort_by=SuccessfulSubmission&amp;sorting_order=desc
  [2]: http://www.codechef.com/submit/TEST
  [3]: https://stackoverflow.com/a/3783805/2235567
  [4]: https://stackoverflow.com/questions/1739656/c99-backward-compatibility
  [5]: http://www.linuxquestions.org/questions/programming-9/gnu-c-and-ansi-c-520509/

What is the difference between C, C99, ANSI C and GNU C?

Is there a `printf` width specifier which can be applied to a floating point specifier that would automatically format the output to the necessary number of *significant digits* such that when scanning the string back in, the original floating point value is acquired?

For example, suppose I print a `float` to a precision of `2` decimal places:

    float foobar = 0.9375;
    printf(&quot;%.2f&quot;, foobar);    // prints out 0.94

When I scan the output `0.94`, I have no standards-compliant guarantee that I&#39;ll get the original `0.9375` floating-point value back (in this example, I probably won&#39;t).

I would like a way tell `printf` to automatically print the floating-point value to the necessary number of *significant digits* to ensure that it can be scanned back to the original value passed to `printf`.

I could use some of the macros in `float.h` to [derive the maximum width](https://stackoverflow.com/a/1701272/1806289) to pass to `printf`, but is there already a specifier to automatically print to the necessary number of *significant digits* -- or at least to the maximum width?

Printf width specifier to maintain precision of floating-point value

Consider:

    struct Person
    {
        int height;
        int weight;
        int age;
    };

    int main()
    {
        Person p { .age = 18 };
    }

The code above is legal in C99, but not legal in C++11.

**What was the [tag:c++11] standard committee&#39;s rationale for excluding support for such a handy feature?**


Why does C++11 not support designated initializer lists as C99?

I have found a function that calculates square of a number:

    int p(int n) {
        int a[n]; //works on C99 and above
	    return (&amp;a)[n] - a;
    }

It returns value of n&lt;sup&gt;2&lt;/sup&gt;. Question is, how does it do that? After a little testing, I found that between `(&amp;a)[k]` and `(&amp;a)[k+1]` is `sizeof(a)`/`sizeof(int)`. Why is that?

Can&#39;t understand this way to calculate the square of a number

I&#39;ve found this C program from the web:

    #include &lt;stdio.h&gt;
    
    int main(){
        
        printf(&quot;C%d\n&quot;,(int)(90-(-4.5//**/
        -4.5)));
        
        return 0;
    }

The interesting thing with this program is that when it is compiled and run in C89 mode, it prints `C89` and when it is compiled and run in C99 mode, it prints `C99`. But I am not able to figure out how this program works.

Can you explain how the second argument of `printf` works in the above program?

How does the below program output `C89` when compiled in C89 mode and `C99` when compiled in C99 mode?

To my amazement I just discovered that the C99 stdint.h is missing from MS Visual Studio 2003 upwards.  I&#39;m sure they have their reasons, but does anyone know where I can download a copy?  Without this header I have no definitions for useful types such as uint32_t, etc.

C99 stdint.h header and MS Visual Studio

When I try to build this code

    inline void f() {}
    
    int main()
    {
        f();
    }

using the command line

    gcc -std=c99 -o a a.c

I get a linker error (undefined reference to `f`).  The error vanishes if I use `static inline` or `extern inline` instead of just `inline`, or if I compile with `-O` (so the function is actually inlined).

This behaviour seems to be defined in paragraph 6.7.4 (6) of the C99 standard:
&gt; If all of the file scope declarations for a function in a translation unit include the `inline` function specifier without `extern`, then the definition in that translation unit is an inline definition. An inline definition does not provide an external definition for the function, and does not forbid an external definition in another translation unit. An inline definition provides an alternative to an external definition, which a translator may use to implement any call to the function in the same translation unit. It is unspecified whether a call to the function uses the inline definition or the external definition.

If I understand all this correctly, a compilation unit with a function defined `inline` as in the above example only compiles consistently if there is also an external function with the same name, and I never know if my own function or the external function is called.

Isn&#39;t this behaviour completely daft? Is it ever useful to define a function `inline` without `static` or `extern` in C99?  Am I missing something?

## Summary of answers

Of course I was missing something, and the behaviour isn&#39;t daft. :)

As [Nemo explains](https://stackoverflow.com/questions/6312597/is-inline-without-static-or-extern-ever-useful-in-c99/6312813#6312813), the idea is to put the *definition* of the function

    inline void f() {}

in the header file and only a *declaration*

    extern inline void f();

in the corresponding .c file.  Only the `extern` declaration triggers the generation of externally visible binary code.  And there is indeed no use of `inline` in a .c file -- it&#39;s only useful in headers.

As the [rationale of the C99 committee quoted in Jonathan&#39;s answer](https://stackoverflow.com/questions/6312597/is-inline-without-static-or-extern-ever-useful-in-c99/6312854#6312854) explicates, `inline` is all about compiler optimisations that require the definition of a function to be visible at the site of a call.  This can only be achieved by putting the definition in the header, and of course a definition in a header must not emit code every time it is seen by the compiler.  But since the compiler is not forced to actually inline a function, an external definition must exist somewhere.

Is &quot;inline&quot; without &quot;static&quot; or &quot;extern&quot; ever useful in C99?

Are there machines (or compilers), where `sizeof(char) != 1`?

Does **C99 standard** says that `sizeof(char)` on standard compliance implementation MUST be exactly 1? If it does, please, give me section number and citation.

*Update:*
If I have a machine (CPU), which can&#39;t address bytes (minimal read is 4 bytes, aligned), but only 4-s of bytes (`uint32_t`), &lt;strike&gt;can compiler for this machine define `sizeof(char)` to 4?&lt;/strike&gt; *`sizeof(char)` will be 1, but char will have 32 bits* (`CHAR_BIT` macros)

*Update2:* 
But sizeof result is NOT a BYTES ! it is the size of CHAR. And char can be 2 byte, or (may be) 7 bit?

*Update3:*
Ok. All machines have `sizeof(char) == 1`. But what machines have `CHAR_BIT &gt; 8` ?

Are there machines, where sizeof(char) != 1, or at least CHAR_BIT &gt; 8?

I keep reading about C99 and C++11 and all these totally sweet things that are getting added to the language standard that might be nice to use someday. However, we currently languish in the land of writing C++ in Visual Studio.

Will any of the new stuff in the standard ever get added to visual studio, or is Microsoft more interested in adding new C# variants to do that?

Edit: In addition to the accepted answer, I found the Visual C++ team blog:

http://blogs.msdn.com/vcblog/

And specifically, this post in it:

https://web.archive.org/web/20190109064523/https://blogs.msdn.microsoft.com/vcblog/2008/02/22/tr1-slide-decks/

Very useful. Thanks!

Visual Studio support for new C / C++ standards?

What&#39;s the C99 boolean data type and how to use it?

C99 boolean data type?

Is it undefined behavior to print null pointers with the `%p` conversion specifier?

&lt;!-- language: C --&gt;

    #include &lt;stdio.h&gt;
    
    int main(void) {
        void *p = NULL;
        
        printf(&quot;%p&quot;, p);
        
        return 0;
    }
    

The question applies to the C standard, and not to C implementations.

Printing null pointers with %p is undefined behavior?

The C99 standard introduces the following datatypes. The documentation can be found [here][1] for the AVR stdint library.


 - `uint8_t` means it&#39;s an 8-bit unsigned type.
 - `uint_fast8_t`  means it&#39;s the fastest unsigned int with at least 8
   bits.
 - `uint_least8_t` means it&#39;s an unsigned int with at least 8 bits.

I understand `uint8_t` and what is `uint_fast8_t`( I don&#39;t know how it&#39;s implemented in register level).

1.Can you explain what is the meaning of &quot;it&#39;s an `unsigned int` with at least 8 bits&quot;? 

2.How `uint_fast8_t` and `uint_least8_t` help increase efficiency/code space compared to the `uint8_t`?


  [1]: http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html#ga8f075c759c74e109e8184306c663809d

Difference between uint8_t, uint_fast8_t and uint_least8_t

I was wondering if it is possible to iterate over arguments passed to a variadic macro in C99 or using any GCC extensions ?

For e.g. is it possible to write a generic macro that takes a structure and its fields passed as arguments and prints offset of each field within the structure ?

Something like this:

&lt;pre&gt;
struct a {
    int a;
    int b;
    int c;
};

/* PRN_STRUCT_OFFSETS will print offset of each of the fields 
   within structure passed as the first argument.
*/

int main(int argc, char *argv[])
{
    PRN_STRUCT_OFFSETS(struct a, a, b, c);

    return 0;
}
&lt;/pre&gt;

Is it possible to iterate over arguments in variadic macros?

I am just wondering if anyone know of some good tutorials on the Internet for developing state machines. Or ebooks?

I am starting working on state machines and just need something general to get me started.



state machines tutorials

Is the difference of two non-void pointer variables defined (per C99 and/or C++98) if they are both `NULL` valued?

For instance, say I have a buffer structure that looks like this:

    struct buf {
      char *buf;
      char *pwrite;
      char *pread;
    } ex;

Say, `ex.buf` points to an array or some malloc&#39;ed memory. If my code always ensures that `pwrite` and `pread` point within that array or one past it, then I am fairly confident that `ex.pwrite - ex.pread` will always be defined. However, what if `pwrite` and `pread` are both NULL. Can I just expect subtracting the two is defined as `(ptrdiff_t)0` or does strictly compliant code need to test the pointers for NULL? Note that the only case I am interested in is when *both* pointers are NULL (which represents a buffer not initialized case). The reason has to do with a fully compliant &quot;available&quot; function given the preceding assumptions are met:

    size_t buf_avail(const struct s_buf *b)
    {     
        return b-&gt;pwrite - b-&gt;pread;
    }


Is the behavior of subtracting two NULL pointers defined?

[C99][1] has been around for over 10 years, but support for it has been slow coming, so most developers have stuck with C89. Even today, I&#39;m sometimes mildly surprised when I come across C99 features in C code.

Now that most major compilers support C99 (MSVC being a notable exception, and some embedded compilers also lagging behind), I feel that developers who work with C probably ought to know about what C99 features are available to them. Some of the features are just common features that were never standardized before (`snprintf`, for instance), or are familiar from C++ (flexible variable declaration placement, or single-line `//` comments), but some of the new features were first introduced in C99 and are unfamiliar to many programmers.

What do you find the most useful new features in C99?

For reference, [the C99 standard][3] (labelled as a draft, but identical to the updated standard, as far as I know), the [list of new features][4], and the [GCC C99 implementation status][5].

One feature per answer, please; feel free to leave multiple answers. Short code examples demonstrating new features are encouraged.


  [1]: http://en.wikipedia.org/wiki/C99
  [3]: http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
  [4]:  http://www.open-std.org/jtc1/sc22/wg14/www/newinc9x.htm
  [5]: http://gcc.gnu.org/c99status.html

What are the most useful new features in C99?

I learned today that there are digraphs in C99 and C++.  The following is a valid program:

    %:include &lt;stdio.h&gt;

    %:ifndef BUFSIZE
     %:define BUFSIZE  512
    %:endif

    void copy(char d&lt;::&gt;, const char s&lt;::&gt;, int len)
    &lt;%
        while (len-- &gt;= 0)
        &lt;%
            d&lt;:len:&gt; = s&lt;:len:&gt;;
        %&gt;
    %&gt;

My question is: why do they exist?

Why are there digraphs in C and C++?

I was wondering if there were any files in which I could set the `-std=c99` flag, so that I would not have to set it for every compilation. I am using GCC 4.4 on Ubuntu.

Setting std=c99 flag in GCC

`void func()`

In practice, an empty parameter means any argument is accepted.

`void func(void)` accepts no argument.

But in Standard C99, I find such lines:

&gt;**[6.7.5.3 Function declarators (including prototypes)](http://port70.net/~nsz/c/c99/n1256.html#6.7.5.3p14)**&lt;br&gt;
14 An identifier list declares only the identifiers of the parameters of the function. **An empty list in a function declarator that is part of a definition of that function specifies that the function has no parameters.** The empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.

According to the standard, are `func()` and `func(void)` the same?









func() vs func(void) in C99

How do I printf `long long int` and also `unsigned long long int` in C99 using GCC? 

I have searched the other posts which suggest to use `%lld` but it gives these warnings:

&gt; warning#1: unknown conversion type character &#39;l&#39; in format [-Wformat]|  
&gt; warning#2: too many arguments for format [-Wformat-extra-args]|

For the following attempt:

    #include &lt;stdio.h&gt;
    
    int main()
    {
       long long int x = 0;
       unsigned long long int y = 0;
       printf(&quot;%lld\n&quot;, x);
       printf(&quot;%llu\n&quot;, y);
    }

Printf long long int in C with GCC?

I read several questions in stackoverflow about `inline` in C but still am not clear about it.

 1. `static inline void f(void) {}` has no practical difference with `static void f(void) {}`.
 2. `inline void f(void) {}` in C doesn&#39;t work as the C++ way. How does it work in C?
 3. What actually does `extern inline void f(void);` do?

I never really found a use of the `inline` keyword in my C programs, and when I see this keyword in other people&#39;s code, it&#39;s almost always `static inline`, in which I see no difference with just `static`.

What is the use of the `inline` keyword in C?

When I ask to see the current version of cc I get this.

    $ cc --version
    cc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
    Copyright (C) 2012 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
    
    $ 


What I would like to know is which of c89, c90, c99 or c11 is being used.

What is the default C -std standard version for the current GCC (especially on Ubuntu)?

I wrote a C program that accepts integer input from the user, that is used as the size of an integer array, and using that value it declares an array of given size, and I am confirming it by checking the size of the array.

Code:
 

    #include &lt;stdio.h&gt;
	int main(int argc, char const *argv[])
	{
		int n;
		scanf(&quot;%d&quot;,&amp;n);
		int k[n];
		printf(&quot;%ld&quot;,sizeof(k));
		return 0;
	}

and surprisingly it is correct! The program is able to create the array of required size.     
But all static memory allocation is done at compile time, and during compile time the value of `n` is not known, so how come the compiler is able to allocate memory of required size?

If we can allocate the required memory just like that then what is the use of dynamic allocation using `malloc()` and `calloc()`?

How does the compiler allocate memory without knowing the size at compile time?

A number of answers for the Stack Overflow question https://stackoverflow.com/questions/11638091/getting-the-ieee-single-precision-bits-for-a-float suggest using a `union` structure for type punning (e.g.: turning the bits of a `float` into a `uint32_t`):

    union {
        float f;
        uint32_t u;
    } un;
    un.f = your_float;
    uint32_t target = un.u;

However, the value of the `uint32_t` member of the union appears to be unspecified according to the C99 standard (at least draft n1124), where section 6.2.6.1.7 states: 
&gt; When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values.

At least one footnote of the C11 n1570 draft seems to imply that this is no longer the case (see footnote 95 in 6.5.2.3):
&gt;If the member used to read the contents of a union object is not the same as the member last used to
store a value in the object, the appropriate part of the object representation of the value is reinterpreted
as an object representation in the new type as described in 6.2.6 (a process sometimes called ‘‘type
punning’’). This might be a trap representation.

However, the text to section 6.2.6.1.7 is the same in the C99 draft as in the C11 draft.

Is this behavior actually unspecified under C99?  Has it become specified in C11?  I realize that most compilers seem to support this, but it would be nice to know if it&#39;s specified in the standard, or just a very common extension.

Is type-punning through a union unspecified in C99, and has it become specified in C11?

I defined my function in .c (without header declaration) as here:

    inline int func(int i) {
     return i+1;
    }

Then in the same file below I use it:

    ...
    i = func(i);

And during the linking I got &quot;undefined reference to &#39;func&#39;&quot;. Why?

C99 inline function in .c file

Assuming you&#39;re using a compiler that supports C99 (or even just stdint.h), is there any reason not to use fixed-width integer types such as uint8_t?

One reason that I&#39;m aware of is that it makes much more sense to use `char`s when dealing with characters instead of using `(u)int8_t`s, as mentioned in [this question][1].

But if you are planning on storing a number, when would you want to use a type that you don&#39;t know how big it is? I.e. In what situation would you want to store a number in an `unsigned short` without knowing if it is 8, 16, or even 32 bits, instead of using a `uint16t`?

Following on from this, is it considered better practice to use fixed-width integers, or to use the normal integer types and just never assume anything and use `sizeof` wherever you need to know how many bytes they are using?


  [1]: https://stackoverflow.com/questions/1725855/uint8-t-vs-unsigned-char

Is there any reason not to use fixed width integer types (e.g. uint8_t)?

Consider this (horrible, terrible, no good, very bad) code structure:

    #define foo(x) // commented out debugging code

    // Misformatted to not obscure the point
    if (a)
    foo(a);
    bar(a);

I&#39;ve seen two compilers&#39; preprocessors generate different results on this code:

    if (a)
    bar(a);

and

    if (a)
    ;
    bar(a);

Obviously, this is a bad thing for a portable code base.

My question: What is the preprocessor supposed to do with this? Elide comments first, or expand macros first?

Does the C preprocessor strip comments or expand macros first?

When you have string in C, you can add direct hex code inside.

    char str[] = &quot;abcde&quot;; // &#39;a&#39;, &#39;b&#39;, &#39;c&#39;, &#39;d&#39;, &#39;e&#39;, 0x00
    char str2[] = &quot;abc\x12\x34&quot;; // &#39;a&#39;, &#39;b&#39;, &#39;c&#39;, 0x12, 0x34, 0x00

Both examples have 6 bytes in memory. Now the problem exists if you want to add value `[a-fA-F0-9]` after hex entry.

    //I want: &#39;a&#39;, &#39;b&#39;, &#39;c&#39;, 0x12, &#39;e&#39;, 0x00
    //Error, hex is too big because last e is treated as part of hex thus becoming 0x12e
    char problem[] = &quot;abc\x12e&quot;;

Possible solution is to replace after definition.

    //This will work, bad idea
    char solution[6] = &quot;abcde&quot;;
    solution[3] = 0x12;

This can work, but it will fail, if you put it as `const`.

    //This will not work
    const char solution[6] = &quot;abcde&quot;;
    solution[3] = 0x12; //Compilation error!

How to properly insert `e` after `\x12` without triggering error?

---
Why I&#39;m asking? When you want to build *UTF-8* string as constant, you have to use hex values of character if it is larger than ASCII table can hold.

How to properly add hex escapes into a string-literal?

This question was triggered by replie(s) to a [post by Herb Sutter][1] where he explained MS&#39;s decision to not support/make a C99 compiler but just go with the C(99) features that are in the C++(11) standard anyway.

One [commenter replied][2]: 

&gt; (...) C is important and deserves at least a little bit of attention.
&gt; 
&gt; There is a LOT of existing code out there that is valid C but is not
&gt; valid C++. That code is not likely to be rewritten (...) 

Since I only program in MS C++, I really don&#39;t know &quot;pure&quot; C that well, i.e. I have no ready picture of what details of the C++-language I&#39;m using are not in C(99) and I have little clues where some C99 code would not work as-is in a C++ compiler. 

Note that I know about the C99 only `restrict` keyword which to me *seems* to have very narrow application and about variable-length-arrays (of which I&#39;m not sure how widespread or important they are).

Also, I&#39;m very interested whether there are any important semantic differences or gotchas, that is, C(99) code that will *compile* under C++(11) but do something differently with the C++ compiler than with the C compiler.

----
Quick links: External resources from the answers:

* [Wikipedia page][3] 
* [David R. Tribble&#39;s comparison][4] (from 2001) 
* C++11 standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf (section C.1)


  [1]: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/
  [2]: http://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/#comment-5446
  [3]: http://en.wikipedia.org/wiki/Compatibility_of_C_and_C++
  [4]: http://david.tribble.com/text/cdiffs.htm

What are the incompatible differences between C(99) and C++(11)?

Does this C99 code produce undefined behavior?

    #include &lt;stdio.h&gt;
    
    int main() {
      int a[3] = {0, 0, 0};
      a[a[0]] = 1;
      printf(&quot;a[0] = %d\n&quot;, a[0]);
      return 0;
    }

In the statement `a[a[0]] = 1;` , `a[0]` is both read and modified.

I looked n1124 draft of ISO/IEC 9899. It says (in 6.5 Expressions):

&gt; Between the previous and next sequence point an object shall have its stored value modified at most once by the evaluation of an expression. Furthermore, the prior value shall be read only to determine the value to be stored.

It does not mention reading an object to determine the object itself to be modified. Thus this statement might produce undefined behavior.

However, I feel it strange. Does this actually produce undefined behavior?

(I also want to know about this problem in other ISO C versions.)

Does a[a[0]] = 1 produce undefined behavior?

This is inspired by [this question][1] 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..][2]

&gt; strncpy does not null-terminate, and
&gt; does null-pad the whole remainder of
&gt; the destination buffer, which is a
&gt; huge waste of time. You can work
&gt; around the former by adding your own
&gt; null padding, but not the latter. It
&gt; was never intended for use as a &quot;safe
&gt; string handling&quot; function, but for
&gt; working with fixed-size fields in Unix
&gt; directory tables and database files.
&gt; snprintf(dest, n, &quot;%s&quot;, src) is the
&gt; only correct &quot;safe strcpy&quot; in standard
&gt; C, but it&#39;s likely to be a lot slower.
&gt; By the way, truncation in itself can
&gt; be a major bug and in some cases might
&gt; lead to privilege elevation or DoS, so
&gt; throwing &quot;safe&quot; string functions that
&gt; truncate their output at a problem is
&gt; not a way to make it &quot;safe&quot; or
&gt; &quot;secure&quot;. Instead, you should ensure
&gt; that the destination buffer is the
&gt; right size and simply use strcpy (or
&gt; better yet, memcpy if you already know
&gt; the source string length).

And from [Jonathan Leffler][3]

&gt; Note that strncat() is even more
&gt; confusing in its interface than
&gt; strncpy() - what exactly is that
&gt; length argument, again? It isn&#39;t what
&gt; you&#39;d expect based on what you supply
&gt; strncpy() etc - so it is more error
&gt; prone even than strncpy(). For copying
&gt; strings around, I&#39;m increasingly of
&gt; the opinion that there is a strong
&gt; argument that you only need memmove()
&gt; because you always know all the sizes
&gt; ahead of time and make sure there&#39;s
&gt; enough space ahead of time. Use
&gt; memmove() in preference to any of
&gt; strcpy(), strcat(), strncpy(),
&gt; strncat(), memcpy().

So, I&#39;m clearly a little rusty on the C standard library. Therefore, I&#39;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).
 - &quot;I prefer x over y&quot; - preference is ok, we all have them but I&#39;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&#39;m flagging for community wiki straight away.

I am also working as per C99.

  [1]: https://stackoverflow.com/questions/4580329/string-handling-practices-in-c
  [2]: https://stackoverflow.com/users/379897/r
  [3]: https://stackoverflow.com/users/15168/jonathan-leffler

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

I, and I think many others, have had great success using smart pointers to wrap up unsafe memory operations in C++, using things like RAII, et cetera. However, wrapping memory management is easier to implement when you have destructors, classes, operator overloading, et cetera.

For someone writing in raw C99, where could you point (no pun intended) to help with safe memory management?

Thanks.

Smart pointers/safe memory management for C?

I used to think that in C99, even if the side-effects of functions `f` and `g` interfered, and although the expression `f() + g()` does not contain a sequence point, `f` and `g` would contain some, so the behavior would be unspecified: either f() would be called before g(), or g() before f().

I am no longer so sure. What if the compiler inlines the functions (which the compiler may decide to do even if the functions are not declared `inline`) and then reorders instructions? May one get a result different of the above two? In other words, is this undefined behavior?

This is not because I intend to write this kind of thing, this is to choose the best label for such a statement in a static analyzer. 


In C99, is f()+g() undefined or merely unspecified?

I have recently discovered existence of standard _fastest_ type, mainly [int_fast32_t][1] and [int_fast64_t][2].

I was always told that, for normal use on mainstream architecture, one should better use classical _int_ &amp; _long_ which should always fit to the processor default reading capacity and so avoid useless numeric conversions.

In the C99 Standard, it says in &#167;7.18.1.3p2 : 
&gt; &quot;The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N.&quot;

And there is also a quote about it in &#167;7.18.1.3p1 :
&gt; &quot;The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements.&quot;

It&#39;s unclear to me what _fastest_ really means. I do not understand when I should use this type and when I should not. 

I have googled a little on this and found that some [open][3] [source][4] [projects][5] have changed some of their functions to it, but not all of them. They didn&#39;t really explain why they have changed a part, and _only_ a part, of their code to it.

Do you know what are the specific cases/usages when int_fastXX_t are _really_ faster than the classical ones ? 


  [1]: http://www.linuxbase.org/navigator/browse/type_single.php?cmd=display&amp;Tid=16619
  [2]: http://www.linuxbase.org/navigator/browse/type_single.php?cmd=display&amp;Tid=16620
  [3]: http://lists.gnu.org/archive/html/qemu-devel/2011-03/msg00454.html
  [4]: http://cekirdek.pardus.org.tr/~ismail/ffmpeg-docs/simple__idct__alpha_8c.html
  [5]: http://patchwork.ozlabs.org/patch/85610/

What is the difference between intXX_t and int_fastXX_t?

What type for array index in C99 should be used? It have to work on LP32, ILP32, ILP64, LP64, LLP64 and more. It doesn&#39;t have to be a C89 type.

I have found 5 candidates:

* `size_t`
* `ptrdiff_t`
* `intptr_t` / `uintptr_t`
* `int_fast*_t` / `uint_fast*_t`
* `int_least*_t` / `uint_least*_t`

There is simple code to better illustrate problem. What is the best type for `i` and `j` in these two particular loops. If there is a good reason, two different types are fine too.

    for (i=0; i&lt;imax; i++) {
            do_something(a[i]);
    }
    /* jmin can be less than 0 */
    for (j=jmin; j&lt;jmax; j++) {
            do_something(a[j]);
    }

P.S.
In the first version of question I had forgotten about negative indexes.

P.P.S.
I am not going to write a C99 compiler. However any answer from a compiler programmer would be very valuable for me.

Similar question:

* https://stackoverflow.com/questions/1464174/size-t-vs-intptr-t  
The context of this question if different though.

What is the correct type for array indexes in C?

here is very simplified code of problem I have:

&lt;pre&gt;
enum node_type {
    t_int, t_double
};

struct int_node {
    int value;
};

struct double_node {
    double value;
};

struct node {
    enum node_type type;
    &lt;b&gt;union {
        struct int_node int_n;
        struct double_node double_n;
    };&lt;/b&gt;
};

int main(void) {
    struct int_node i;
    i.value = 10;
    struct node n;
    n.type = t_int;
    n.&lt;b&gt;int_n&lt;/b&gt; = i;
    return 0;
}
&lt;/pre&gt;

And what I don&#39;t undestand is this:

&lt;pre&gt;
$ cc us.c 
$ cc -std=c99 us.c 
us.c:18:4: warning: declaration does not declare anything
us.c: In function ‘main’:
us.c:26:4: error: ‘struct node’ has no member named ‘int_n’
&lt;/pre&gt;

Using `GCC` without `-std` option compiles code above without any problems (and the similar code is working pretty well), but it seems that `c99`  does not permit this technique. Why is it so and is it possible to make is `c99` (or `c89`, `c90`) compatible? Thanks.

Anonymous union within struct not in c99?

It is nearly impossible(*) to provide strict IEEE 754 semantics at reasonable cost when the only floating-point instructions one is allowed to used are the 387 ones. It is particularly hard when one wishes to keep the FPU working on the full 64-bit significand so that the `long double` type is available for extended precision. The usual “solution” is to do intermediate computations at the only available precision, and to convert to the lower precision at more or less well-defined occasions.

Recent versions of GCC handle excess precision in intermediate computations according to the interpretation laid out by Joseph S. Myers in a [2008 post to the GCC mailing list][2]. This description makes a program compiled with `gcc -std=c99 -mno-sse2 -mfpmath=387` completely predictable, to the last bit, as far as I understand. And if by chance it doesn&#39;t, it is a bug and it will be fixed: Joseph S. Myers&#39; stated intention in his post is to make it predictable.

Is it documented how Clang handles excess precision (say when the option `-mno-sse2` is used), and where?

(*) EDIT: this is an exaggeration. It is [slightly annoying but not that difficult][1] to emulate binary64 when one is allowed to configure the x87 FPU to use a 53-bit significand.

----------

Following a comment by R.. below, here is the log of a short interaction of mine with the most recent version of Clang I have :

    Hexa:~ $ clang -v
    Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
    Target: x86_64-apple-darwin12.4.0
    Thread model: posix
    Hexa:~ $ cat fem.c
    #include &lt;stdio.h&gt;
    #include &lt;math.h&gt;
    #include &lt;float.h&gt;
    #include &lt;fenv.h&gt;
    
    double x;
    double y = 2.0;
    double z = 1.0;
    
    int main(){
      x = y + z;
      printf(&quot;%d\n&quot;, (int) FLT_EVAL_METHOD);
    }
    Hexa:~ $ clang -std=c99 -mno-sse2 fem.c
    Hexa:~ $ ./a.out 
    0
    Hexa:~ $ clang -std=c99 -mno-sse2 -S fem.c
    Hexa:~ $ cat fem.s 
    …
    	movl	$0, %esi
    	fldl	_y(%rip)
    	fldl	_z(%rip)
    	faddp	%st(1)
    	movq	_x@GOTPCREL(%rip), %rax
    	fstpl	(%rax)
    …


  [1]: https://stackoverflow.com/questions/18496560/how-do-java-runtimes-targeting-pre-sse2-processors-implement-floating-point-basi
  [2]: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html

Is there a document describing how Clang handles excess floating-point precision?

To be truly standards-compliant, must all functions in C (except for main) have a prototype, even if they are only used after their definition in the same translation unit?

All C99 Solutions on Gang of Coders

Total of 43 C99 Solutions