The `man pages` and programmer documentations for the socket options `SO_REUSEADDR` and `SO_REUSEPORT` are different for different operating systems and often highly confusing. Some operating systems don&#39;t even have the option `SO_REUSEPORT`. The WEB is full of contradicting information regarding this subject and often you can find information that is only true for one socket implementation of a specific operating system, which may not even be explicitly mentioned in the text.

So how exactly is `SO_REUSEADDR` different than `SO_REUSEPORT`?

Are systems without `SO_REUSEPORT` more limited?

And what exactly is the expected behavior if I use either one on different operating systems?

How do SO_REUSEADDR and SO_REUSEPORT differ?

What is a portable way (e.g. for Linux and Windows) to get the current user&#39;s username? Something similar to `os.getuid()` would be nice:

    &gt;&gt;&gt; os.getuid()
    42
    
    &gt;&gt;&gt; os.getusername()
    &#39;slartibartfast&#39;

The [`pwd`][1] module works for Unix only. Some people suggest that getting the username under Windows can be complicated in certain circumstances (e.g., running as a Windows service).


  [1]: https://docs.python.org/3/library/pwd.html

Is there a portable way to get the current username in Python?

I posted a question with my code whose only `#include` directive was the following:

    #include &lt;bits/stdc++.h&gt;

My teacher told me to do this, but in the comments section I was informed that I shouldn&#39;t.

Why?

Why should I not #include &lt;bits/stdc++.h&gt;?

I was looking through the `strlen` code [here](http://www.stdlib.net/~colmmacc/strlen.c.html) and I was wondering if the optimizations used in the code are really needed? For example, why wouldn&#39;t something like the following work equally good or better?

    unsigned long strlen(char s[]) {
        unsigned long i;
        for (i = 0; s[i] != &#39;\0&#39;; i++)
            continue;
        return i;
    }

Isn&#39;t simpler code better and/or easier for the compiler to optimize?

The code of `strlen` on the page behind the link looks like this:

&gt;     /* Copyright (C) 1991, 1993, 1997, 2000, 2003 Free Software Foundation, Inc.
&gt;        This file is part of the GNU C Library.
&gt;        Written by Torbjorn Granlund (tege@sics.se),
&gt;        with help from Dan Sahlin (dan@sics.se);
&gt;        commentary by Jim Blandy (jimb@ai.mit.edu).
&gt;     
&gt;        The GNU C Library is free software; you can redistribute it and/or
&gt;        modify it under the terms of the GNU Lesser General Public
&gt;        License as published by the Free Software Foundation; either
&gt;        version 2.1 of the License, or (at your option) any later version.
&gt;     
&gt;        The GNU C Library is distributed in the hope that it will be useful,
&gt;        but WITHOUT ANY WARRANTY; without even the implied warranty of
&gt;        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
&gt;        Lesser General Public License for more details.
&gt;     
&gt;        You should have received a copy of the GNU Lesser General Public
&gt;        License along with the GNU C Library; if not, write to the Free
&gt;        Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
&gt;        02111-1307 USA.  */
&gt;     
&gt;     #include &lt;string.h&gt;
&gt;     #include &lt;stdlib.h&gt;
&gt;     
&gt;     #undef strlen
&gt;
&gt;     /* Return the length of the null-terminated string STR.  Scan for
&gt;        the null terminator quickly by testing four bytes at a time.  */
&gt;     size_t
&gt;     strlen (str)
&gt;          const char *str;
&gt;     {
&gt;       const char *char_ptr;
&gt;       const unsigned long int *longword_ptr;
&gt;       unsigned long int longword, magic_bits, himagic, lomagic;
&gt;     
&gt;       /* Handle the first few characters by reading one character at a time.
&gt;          Do this until CHAR_PTR is aligned on a longword boundary.  */
&gt;       for (char_ptr = str; ((unsigned long int) char_ptr
&gt;                 &amp; (sizeof (longword) - 1)) != 0;
&gt;            ++char_ptr)
&gt;         if (*char_ptr == &#39;\0&#39;)
&gt;           return char_ptr - str;
&gt;     
&gt;       /* All these elucidatory comments refer to 4-byte longwords,
&gt;          but the theory applies equally well to 8-byte longwords.  */
&gt;     
&gt;       longword_ptr = (unsigned long int *) char_ptr;
&gt;     
&gt;       /* Bits 31, 24, 16, and 8 of this number are zero.  Call these bits
&gt;          the &quot;holes.&quot;  Note that there is a hole just to the left of
&gt;          each byte, with an extra at the end:
&gt;     
&gt;          bits:  01111110 11111110 11111110 11111111
&gt;          bytes: AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD
&gt;     
&gt;          The 1-bits make sure that carries propagate to the next 0-bit.
&gt;          The 0-bits provide holes for carries to fall into.  */
&gt;       magic_bits = 0x7efefeffL;
&gt;       himagic = 0x80808080L;
&gt;       lomagic = 0x01010101L;
&gt;       if (sizeof (longword) &gt; 4)
&gt;         {
&gt;           /* 64-bit version of the magic.  */
&gt;           /* Do the shift in two steps to avoid a warning if long has 32 bits.  */
&gt;           magic_bits = ((0x7efefefeL &lt;&lt; 16) &lt;&lt; 16) | 0xfefefeffL;
&gt;           himagic = ((himagic &lt;&lt; 16) &lt;&lt; 16) | himagic;
&gt;           lomagic = ((lomagic &lt;&lt; 16) &lt;&lt; 16) | lomagic;
&gt;         }
&gt;       if (sizeof (longword) &gt; 8)
&gt;         abort ();
&gt;     
&gt;       /* Instead of the traditional loop which tests each character,
&gt;          we will test a longword at a time.  The tricky part is testing
&gt;          if *any of the four* bytes in the longword in question are zero.  */
&gt;       for (;;)
&gt;         {
&gt;           /* We tentatively exit the loop if adding MAGIC_BITS to
&gt;          LONGWORD fails to change any of the hole bits of LONGWORD.
&gt;     
&gt;          1) Is this safe?  Will it catch all the zero bytes?
&gt;          Suppose there is a byte with all zeros.  Any carry bits
&gt;          propagating from its left will fall into the hole at its
&gt;          least significant bit and stop.  Since there will be no
&gt;          carry from its most significant bit, the LSB of the
&gt;          byte to the left will be unchanged, and the zero will be
&gt;          detected.
&gt;     
&gt;          2) Is this worthwhile?  Will it ignore everything except
&gt;          zero bytes?  Suppose every byte of LONGWORD has a bit set
&gt;          somewhere.  There will be a carry into bit 8.  If bit 8
&gt;          is set, this will carry into bit 16.  If bit 8 is clear,
&gt;          one of bits 9-15 must be set, so there will be a carry
&gt;          into bit 16.  Similarly, there will be a carry into bit
&gt;          24.  If one of bits 24-30 is set, there will be a carry
&gt;          into bit 31, so all of the hole bits will be changed.
&gt;     
&gt;          The one misfire occurs when bits 24-30 are clear and bit
&gt;          31 is set; in this case, the hole at bit 31 is not
&gt;          changed.  If we had access to the processor carry flag,
&gt;          we could close this loophole by putting the fourth hole
&gt;          at bit 32!
&gt;     
&gt;          So it ignores everything except 128&#39;s, when they&#39;re aligned
&gt;          properly.  */
&gt;     
&gt;           longword = *longword_ptr++;
&gt;     
&gt;           if (
&gt;     #if 0
&gt;           /* Add MAGIC_BITS to LONGWORD.  */
&gt;           (((longword + magic_bits)
&gt;     
&gt;             /* Set those bits that were unchanged by the addition.  */
&gt;             ^ ~longword)
&gt;     
&gt;            /* Look at only the hole bits.  If any of the hole bits
&gt;               are unchanged, most likely one of the bytes was a
&gt;               zero.  */
&gt;            &amp; ~magic_bits)
&gt;     #else
&gt;           ((longword - lomagic) &amp; himagic)
&gt;     #endif
&gt;           != 0)
&gt;         {
&gt;           /* Which of the bytes was the zero?  If none of them were, it was
&gt;              a misfire; continue the search.  */
&gt;     
&gt;           const char *cp = (const char *) (longword_ptr - 1);
&gt;     
&gt;           if (cp[0] == 0)
&gt;             return cp - str;
&gt;           if (cp[1] == 0)
&gt;             return cp - str + 1;
&gt;           if (cp[2] == 0)
&gt;             return cp - str + 2;
&gt;           if (cp[3] == 0)
&gt;             return cp - str + 3;
&gt;           if (sizeof (longword) &gt; 4)
&gt;             {
&gt;               if (cp[4] == 0)
&gt;             return cp - str + 4;
&gt;               if (cp[5] == 0)
&gt;             return cp - str + 5;
&gt;               if (cp[6] == 0)
&gt;             return cp - str + 6;
&gt;               if (cp[7] == 0)
&gt;             return cp - str + 7;
&gt;             }
&gt;         }
&gt;         }
&gt;     }
&gt;     libc_hidden_builtin_def (strlen)

Why does this version run quickly?

Isn&#39;t it doing a lot of unnecessary work?

Why does glibc&#39;s strlen need to be so complicated to run quickly?

I&#39;m porting a relatively simple console program written for Unix to the Windows platform ([Visual C++ 8.0][1]). All the source files include &quot;unistd.h&quot;, which doesn&#39;t exist.  Removing it, I get complaints about misssing prototypes for &#39;srandom&#39;, &#39;random&#39;, and &#39;getopt&#39;.
I know I can replace the random functions, and I&#39;m pretty sure I can find/hack-up a getopt implementation.  

But I&#39;m sure others have run into the same challenge. 
My question is: is there a port of &quot;unistd.h&quot; to Windows? At least one containg those functions which do have a native Windows implementation - I don&#39;t need pipes or forking.

**EDIT**:

I know I can create my very own &quot;unistd.h&quot; which contains replacements for the things I need - especially in this case, since it is a limited set. But since it seems like a common problem, I was wondering if someone had done the work already for a bigger subset of the functionality.
  
Switching to a different compiler or environment isn&#39;t possible at work - I&#39;m stuck with Visual Studio.

  [1]: http://en.wikipedia.org/wiki/Visual_C++#32-bit_versions


Is there a replacement for unistd.h for Windows (Visual C)?

I&#39;m trying to print types like `off_t` and `size_t`.  What is the correct placeholder for `printf()` *that is portable*?

Or is there a completely different way to print those variables?

How should I print types like off_t and size_t?

Using only ANSI C, is there any way to measure time with milliseconds precision or more? I was browsing time.h but I only found second precision functions.


How to measure time in milliseconds using ANSI C?

I am a beginner to CMAKE. Below is a simple cmake file which works well in mingw environment windows. The problem is clearly with `target_link_libraries()` function of CMAKE where I am linking libwsock32.a. In windows this works and I get the results. 

However, as expected, in Linux, the `/usr/bin/ld` will look for `-lwsock32` which is NOT there on the Linux OS. 

My Problem is: How do I instruct CMAKE to avoid linking wsock32 library in Linux OS???

Any help will be greatly appreciated. 

My Simple CMake file: 

     PROJECT(biourl)
     set (${PROJECT_NAME}_headers ./BioSocketAddress.h  ./BioSocketBase.h ./BioSocketBuffer.h ./BioSocketCommon.h  ./BioSocketListener.h  ./BioSocketPrivate.h  ./BioSocketStream.h ./BioUrl.h BioDatabase.h )

    set (${PROJECT_NAME}_sources BioSocketAddress.C  BioSocketBase.C  BioSocketCommon.C BioSocketStream.C  BioUrl.C BioDatabase.C )

    add_library(${PROJECT_NAME} STATIC ${${PROJECT_NAME}_headers} ${${PROJECT_NAME}_sources} )

    # linkers
    #find_library(ws NAMES wsock32 PATHS ${PROJECT_SOURCE_DIR} NO_SYSTEM_ENVIRONMENT_PATH NO_DEFAULT_PATH)

    target_link_libraries(${PROJECT_NAME} bioutils wsock32)

    install (TARGETS ${PROJECT_NAME}
           RUNTIME DESTINATION bin
           LIBRARY DESTINATION lib
           ARCHIVE DESTINATION lib/archive )


OS specific instructions in CMAKE: How to?

I&#39;d like to prepare a little educational tool for SO which should help beginners (and intermediate) programmers to recognize and challenge their unwarranted assumptions in C, C++ and their platforms.

Examples: 

* &quot;integers wrap around&quot;
* &quot;everyone has ASCII&quot;
* &quot;I can store a function pointer in a void*&quot;

I figured that a small test program could be run on various platforms, which runs the &quot;plausible&quot; assumptions which are, from our experience in SO, usually made by many inexperienced/semiexperienced mainstream developers and record the ways they break on diverse machines.

The goal of this is not to prove that it is &quot;safe&quot; to do something (which would be impossible to do, the tests prove only anything if they break), but instead to demonstrate to even the most uncomprehending individual **how the most inconspicuous expression break on a different machine, if it has a undefined or implementation defined behavior.**. 

To achieve this I would like to ask you:

* How can this idea be improved?
* Which tests would be good and how should they look like?
* Would you run the tests on the platforms you can get your hands on and post the results, so that we end up with a database of platforms, how they differ and why this difference is allowed?

----
Here&#39;s the current version for the test toy:

    #include &lt;stdio.h&gt;
    #include &lt;limits.h&gt;
    #include &lt;stdlib.h&gt;
    #include &lt;stddef.h&gt;
    int count=0;
    int total=0;
    void expect(const char *info, const char *expr)
    {
        printf(&quot;..%s\n   but &#39;%s&#39; is false.\n&quot;,info,expr);
        fflush(stdout);
        count++;
    }
    #define EXPECT(INFO,EXPR) if (total++,!(EXPR)) expect(INFO,#EXPR)
    
    /* stack check..How can I do this better? */
    ptrdiff_t check_grow(int k, int *p)
    {
        if (p==0) p=&amp;k;
        if (k==0) return &amp;k-p;
        else return check_grow(k-1,p);
    }
    #define BITS_PER_INT (sizeof(int)*CHAR_BIT)
    
    int bits_per_int=BITS_PER_INT;
    int int_max=INT_MAX;
    int int_min=INT_MIN;
    
    /* for 21 - left to right */
    int ltr_result=0;
    unsigned ltr_fun(int k)
    {
        ltr_result=ltr_result*10+k;
        return 1;
    }
    
    int main()
    {
        printf(&quot;We like to think that:\n&quot;);
        /* characters */
        EXPECT(&quot;00 we have ASCII&quot;,(&#39;A&#39;==65));
        EXPECT(&quot;01 A-Z is in a block&quot;,(&#39;Z&#39;-&#39;A&#39;)+1==26);
        EXPECT(&quot;02 big letters come before small letters&quot;,(&#39;A&#39;&lt;&#39;a&#39;));
        EXPECT(&quot;03 a char is 8 bits&quot;,CHAR_BIT==8);
        EXPECT(&quot;04 a char is signed&quot;,CHAR_MIN==SCHAR_MIN);
    
        /* integers */
        EXPECT(&quot;05 int has the size of pointers&quot;,sizeof(int)==sizeof(void*));
        /* not true for Windows-64 */
        EXPECT(&quot;05a long has at least the size of pointers&quot;,sizeof(long)&gt;=sizeof(void*));
    
        EXPECT(&quot;06 integers are 2-complement and wrap around&quot;,(int_max+1)==(int_min));
        EXPECT(&quot;07 integers are 2-complement and *always* wrap around&quot;,(INT_MAX+1)==(INT_MIN));
        EXPECT(&quot;08 overshifting is okay&quot;,(1&lt;&lt;bits_per_int)==0);
        EXPECT(&quot;09 overshifting is *always* okay&quot;,(1&lt;&lt;BITS_PER_INT)==0);
        {
            int t;
            EXPECT(&quot;09a minus shifts backwards&quot;,(t=-1,(15&lt;&lt;t)==7));
        }
        /* pointers */
        /* Suggested by jalf */
        EXPECT(&quot;10 void* can store function pointers&quot;,sizeof(void*)&gt;=sizeof(void(*)()));
        /* execution */
        EXPECT(&quot;11 Detecting how the stack grows is easy&quot;,check_grow(5,0)!=0);
        EXPECT(&quot;12 the stack grows downwards&quot;,check_grow(5,0)&lt;0);
    
        {
            int t;
            /* suggested by jk */
            EXPECT(&quot;13 The smallest bits always come first&quot;,(t=0x1234,0x34==*(char*)&amp;t));
        }
        {
            /* Suggested by S.Lott */
            int a[2]={0,0};
            int i=0;
            EXPECT(&quot;14 i++ is strictly left to right&quot;,(i=0,a[i++]=i,a[0]==1));
        }
        {
            struct {
                char c;
                int i;
            } char_int;
            EXPECT(&quot;15 structs are packed&quot;,sizeof(char_int)==(sizeof(char)+sizeof(int)));
        }
        {
            EXPECT(&quot;16 malloc()=NULL means out of memory&quot;,(malloc(0)!=NULL));
        }
    
        /* suggested by David Thornley */
        EXPECT(&quot;17 size_t is unsigned int&quot;,sizeof(size_t)==sizeof(unsigned int));
        /* this is true for C99, but not for C90. */
        EXPECT(&quot;18 a%b has the same sign as a&quot;,((-10%3)==-1) &amp;&amp; ((10%-3)==1));
    
        /* suggested by nos */
        EXPECT(&quot;19-1 char&lt;short&quot;,sizeof(char)&lt;sizeof(short));
        EXPECT(&quot;19-2 short&lt;int&quot;,sizeof(short)&lt;sizeof(int));
        EXPECT(&quot;19-3 int&lt;long&quot;,sizeof(int)&lt;sizeof(long));
        EXPECT(&quot;20 ptrdiff_t and size_t have the same size&quot;,(sizeof(ptrdiff_t)==sizeof(size_t)));
    #if 0
        {
            /* suggested by R. */
            /* this crashed on TC 3.0++, compact. */
            char buf[10];
            EXPECT(&quot;21 You can use snprintf to append a string&quot;,
                   (snprintf(buf,10,&quot;OK&quot;),snprintf(buf,10,&quot;%s!!&quot;,buf),strcmp(buf,&quot;OK!!&quot;)==0));
        }
    #endif
    
        EXPECT(&quot;21 Evaluation is left to right&quot;,
               (ltr_fun(1)*ltr_fun(2)*ltr_fun(3)*ltr_fun(4),ltr_result==1234));
    		   
    	{
    	#ifdef __STDC_IEC_559__
    	int STDC_IEC_559_is_defined=1;
    	#else 
    	/* This either means, there is no FP support
    	 *or* the compiler is not C99 enough to define  __STDC_IEC_559__
    	 *or* the FP support is not IEEE compliant. */
    	int STDC_IEC_559_is_defined=0;
    	#endif
        EXPECT(&quot;22 floating point is always IEEE&quot;,STDC_IEC_559_is_defined);
    	}
    	
        printf(&quot;From what I can say with my puny test cases, you are %d%% mainstream\n&quot;,100-(100*count)/total);
        return 0;
    }

----

Oh, and I made this community wiki right from the start because I figured that people want to edit my blabber when they read this.

**UPDATE** Thanks for your input. I&#39;ve added a few cases from your answers and will see if I can set up a github for this like Greg suggested.

**UPDATE**:
I&#39;ve created a github repo for this, the file is &quot;gotcha.c&quot;: 

* http://github.com/lutherblissett/disenchanter

Please answer here with patches or new ideas, so they can be discussed or clarified here. I will merge them into gotcha.c then.



What belongs in an educational tool to demonstrate the unwarranted assumptions people make in C/C++?

I have a project that currently uses C++11/14, but it requires something like `std::filesystem`, which is only available in C++17, and hence I don&#39;t have a chance to currently use it. I see, however, that it&#39;s available in my current compiler as `std::experimental::filesystem`. Is it a good idea to use experimental features, assuming that I could in the future add something like:

    #ifdef CXX17 //if this is C++17
    std::filesystem::something ...;
    #else
    std::experimental::filesystem::something ...;
    #endif

My concerns are:

**1. Is it guaranteed that all compliant compilers have the same experimental features?**

**2. Are experimental features prone to big changes that make them unreliable?**

Maybe there&#39;s more things to wonder about. Why should I or should I not use them? I&#39;m puzzled with a new project and don&#39;t know what to decide.


Are the experimental features of modern C++ reliable for long-term projects?

I have Launch4J on my computer and it&#39;s a great program. One of its features I&#39;m interested in is the ability to bundle a JRE in the general .EXE file. However, I can&#39;t find any documentation that describes how to go about doing this.

How do I bundle a JRE with the EXE? Plus, where do I get a compact, portable JRE to run? The download links on Oracle are for the installer packages.

How to bundle a JRE with Launch4j?

On my Linux (and OS X) machines, the `iconv()` function has this prototype:

    size_t iconv (iconv_t, char **inbuf...

while on FreeBSD it looks like this:

    size_t iconv (iconv_t, const char **inbuf...

I would like my C++ code to build on both platforms. With C compilers, passing a `char**` for a `const char**` parameter (or vice versa) typically emits a mere warning; however in C++ it&#39;s a fatal error. So if I pass a `char**`, it won&#39;t compile on BSD, and if I pass a `const char**` it won&#39;t compile on Linux / OS X. How can I write code that compiles on both, without resorting to trying to detect the platform?

One (failed) idea I had was to provide a local prototype that overrides any provided by the header:

    void myfunc(void) {
        size_t iconv (iconv_t, char **inbuf);
        iconv(foo, ptr);
    }

This fails because `iconv` needs C linkage, and you cannot put `extern &quot;C&quot;` within a function (why not?)

The best working idea I&#39;ve come up with is to cast the function pointer itself:

    typedef void (*func_t)(iconv_t, const char **);
    ((func_t)(iconv))(foo, ptr);

but this has the potential to mask other, more serious errors.

How can I portably call a C++ function that takes a char** on some platforms and a const char** on others?

What&#39;s the best way to declare an integer type which is always 4 byte on any platforms? I don&#39;t worry about certain device or old machines which has 16-bit `int`.



How to Declare a 32-bit Integer in C

I have a small Django project I received from a friend. The code works perfectly on his system. However, on my system I get the following error message when running the server:

&gt; **TemplateSyntaxError at /**
&gt;
&gt; &#39;current_tags&#39; is not a valid tag library: Template library current_tags not found, tried django.templatetags.current_tags

The problem is with a line in an html file:

    {% load current_tags %}

This exact same code works on his system with no errors. What could that be?




Django: &#39;current_tags&#39; is not a valid tag library

How do I type a floating point infinity literal in python?

I have heard 
     
     inf = float(&#39;inf&#39;)

is non portable.  Thus, I have had the following recommended:

     inf = 1e400

Is either of these standard, or portable?  What is best practice?

How do I type a floating point infinity literal in python

In order to get an environment variable in a `C` program, one could use the following:

 - `getenv()`  
 - `extern char **environ;`

But other than the above mentioned, is using `char *envp[]` as a third argument to `main()` to get the environment variables considered part of the standard?

    #include &lt;stdio.h&gt;
    
    int main(int argc, char *argv[], char *envp[])
    {
        while(*envp)
            printf(&quot;%s\n&quot;,*envp++);
    }

Is `char *envp[]` portable?


Is char *envp[] as a third argument to main() portable

In MSVC, [DebugBreak()][2] or [\_\_debugbreak][3] cause a debugger to break. On x86 it is equivalent to writing &quot;_asm int 3&quot;, on x64 it is something different. When compiling with gcc (or any other standard compiler) I want to do a break into debugger, too. Is there a platform independent function or intrinsic? I saw the [XCode question][1] about that, but it doesn&#39;t seem portable enough.

Sidenote: I mainly want to implement ASSERT with that, and I understand I can use assert() for that, but I also want to write DEBUG_BREAK or something into the code.


  [1]: https://stackoverflow.com/questions/37299/xcode-equivalent-of-asm-int-3-debugbreak-halt
  [2]: http://msdn.microsoft.com/en-us/library/ms679297.aspx
  [3]: http://msdn.microsoft.com/fr-fr/library/f408b4et.aspx

Is there a portable equivalent to DebugBreak()/__debugbreak?

I&#39;m working on an implementation of the memcache protocol which, at some points, uses 64 bits integer values. These values must be stored in &quot;network byte order&quot;.

I wish there was some `uint64_t htonll(uint64_t value)` function to do the change, but unfortunately, if it exist, I couldn&#39;t find it.

So I have 1 or 2 questions:

 * Is there any **portable** (Windows, Linux, AIX) standard function to do this ?
 * If there is no such function, how would you implement it ?

I have in mind a basic implementation but I don&#39;t know how to check the endianness at compile-time to make the code portable. So your help is more than welcome here ;)

Thank you.

&lt;hr/&gt;

Here is the final solution I wrote, thanks to Brian&#39;s solution.

	uint64_t htonll(uint64_t value)
	{
		// The answer is 42
		static const int num = 42;

		// Check the endianness
		if (*reinterpret_cast&lt;const char*&gt;(&amp;num) == num)
		{
			const uint32_t high_part = htonl(static_cast&lt;uint32_t&gt;(value &gt;&gt; 32));
			const uint32_t low_part = htonl(static_cast&lt;uint32_t&gt;(value &amp; 0xFFFFFFFFLL));

			return (static_cast&lt;uint64_t&gt;(low_part) &lt;&lt; 32) | high_part;
		} else
		{
			return value;
		}
	}

Is there any &quot;standard&quot; htonl-like function for 64 bits integers in C++?

What is the correct way in the post C++11 world for setting the priority of an instance of std::thread


Is there a portable way of doing this that works at least in Windows and POSIX (Linux) environments?


Or is it a matter of getting a handle and using whatever native calls are available for the particular OS?



Portable way of setting std::thread priority in C++11

You can use ftplib for full FTP support in Python. However the preferred way of getting a directory listing is:

    # File: ftplib-example-1.py
    
    import ftplib
    
    ftp = ftplib.FTP(&quot;www.python.org&quot;)
    ftp.login(&quot;anonymous&quot;, &quot;ftplib-example-1&quot;)
    
    data = []
    
    ftp.dir(data.append)
    
    ftp.quit()
    
    for line in data:
        print &quot;-&quot;, line

Which yields:

    $ python ftplib-example-1.py
    - total 34
    - drwxrwxr-x  11 root     4127         512 Sep 14 14:18 .
    - drwxrwxr-x  11 root     4127         512 Sep 14 14:18 ..
    - drwxrwxr-x   2 root     4127         512 Sep 13 15:18 RCS
    - lrwxrwxrwx   1 root     bin           11 Jun 29 14:34 README -&gt; welcome.msg
    - drwxr-xr-x   3 root     wheel        512 May 19  1998 bin
    - drwxr-sr-x   3 root     1400         512 Jun  9  1997 dev
    - drwxrwxr--   2 root     4127         512 Feb  8  1998 dup
    - drwxr-xr-x   3 root     wheel        512 May 19  1998 etc
    ...

I guess the idea is to parse the results to get the directory listing. However this listing is directly dependent on the FTP server&#39;s way of formatting the list. It would be very messy to write code for this having to anticipate all the different ways FTP servers might format this list.

Is there a portable way to get an array filled with the directory listing?

(The array should only have the folder names.)

Using Python&#39;s ftplib to get a directory listing, portably

Any portable code that uses bitfields seems to distinguish between little- and big-endian platforms. See the [declaration of struct iphdr in linux kernel](http://lxr.linux.no/#linux+v2.6.38/include/linux/ip.h) for an example of such code. I fail to understand why bit endianness is an issue at all.

As far as I understand, bitfields are purely compiler constructs, used to facilitate bit level manipulations.

For instance, consider the following bitfield:
&lt;code&gt;&lt;pre&gt;
struct ParsedInt {
    unsigned int f1:1;
    unsigned int f2:3;
    unsigned int f3:4;
};
uint8_t i;
struct ParsedInt *d = &amp;i;
&lt;/pre&gt;&lt;/code&gt;
Here, writing &lt;code&gt;d-&gt;f2&lt;/code&gt; is simply a compact and readable way of saying &lt;code&gt;(i&gt;&gt;1) &amp;  (1&lt;&lt;4 - 1)&lt;/code&gt;.

However, bit operations are well-defined and work regardless of the architecture. So, how come bitfields are not portable?

Why bit endianness is an issue in bitfields?

I&#39;m usually using the following shebang declaration in my Python scripts:

    #!/usr/bin/python

Recently, I&#39;ve came across this shebang declaration:

    #!/usr/bin/env python

In the script documentation, it was noted that using this form is &quot;more portable&quot;.

What does this declaration mean? How come there&#39;s a space in the middle of the path? Does it actually contribute to protability?

Proper shebang for Python script

Just encountered decrement of `end()` iterator in my company source codes and it looks strange for me. As far as I remember this was working on some platforms, but not for the others. Maybe I&#39;m wrong, however I couldn&#39;t find anything useful in standard about that. Standard only says that `end()` returns an iterator which is the past-the-end value, but is it guaranteed to be decrementable? How does code like that match the standard?

    std::list&lt;int&gt;::iterator it = --l.end();

Thanks in advance.

how portable is end iterator decrement?

I&#39;ve just bought a new 4GB USB thumb drive and I&#39;m trying to decide what to put on it. I&#39;m thinking about one of the webserver on a stick packages, a C/C++ IDE (leaning toward Code::Blocks; had Dev-C++ on my old USB drive) and Python. 

What development related tools do you carry around with you on yours?

**Update**

I&#39;ve added categories. 



&lt;center&gt;
IDEs
----
&lt;/center&gt;

[Code::Blocks][1] Open source, cross platform C/C++ IDE  
  
  - Supports several compilers (that you must supply) but you can also download a version that includes MingW.
  - (There&#39;s [a FAQ question][2] on their website explaining how to make
    it portable)  

[Codelite][35]  -- Open-source, cross platform C/C++ IDE   
[Eclipse][38]  -- Open-source, cross platform Java IDE  
[NetBeans][31]  -- Open-source, cross platform  Java IDE  
[JCreator][53] -- Java IDE  
[MSVC6][34]  -- Microsoft&#39;s pre-.NET C/C++ environment    
  
&lt;center&gt;
Languages &amp; Compilers
---------------------
&lt;/center&gt;

[Portable Python][3]  -- Interpreter for the Python programming language  

  - Includes SciTE (editor) and [Django][4] (web framework)  
  
[Strawberry Perl][32]  -- &quot;A 100% Open Source CPAN-capable Perl for Windows&#174; computer that works exactly the same as Perl everywhere else.&quot;   
[Py3k][39]  -- Newest version of the Python programming language  
[Stackless Python][51]  
[Lua][52] -- Scripting language  
[MinGW][33]  -- Sort of a Windows port of GCC  

  - &quot;MinGW provides a complete Open Source programming tool set which is suitable for the development of native Windows programs that do not depend on any 3rd-party C runtime DLLs.&quot; 

&lt;center&gt;
Editors
-------
&lt;/center&gt;
[Notepad++][14] (after so many recommendations, I had to try it)  
[UltraEdit][36] -- &quot;text, hex, HTML, PHP, Java, Javascript, Perl, and programmer&#39;s editor.&quot;  
[VIM][23]  -- &quot;highly configurable text editor built to enable efficient text editing&quot;

  - Major rival to emacs  

[HEdit][21]  -- Hex editor  
[XVI32][11] (Hex Editor)  
[e text editor][40] -- &quot;The Power of Textmate on Windows&quot;  
[Intype text editor][41] -- Code editor for Windows  
[ConTEXT][54] -- Code and text editor  
[Editpad Pro][47] -- &quot;powerful and versatile text editor or word processor.&quot;  

&lt;center&gt;
Discovery
-------
&lt;/center&gt;

[Dependency Walker][8]  -- Allows you to see what DLLs a program or DLL depends on and what functions they export.  
[Reflector][10]  -- Allows you to look into and decompile .Net assemblies  
Spy++  
[DbWin32][20]  -- Lets you see Windows debug and trace messages  

  - Similar to DebugView  

DebugView -- Lets you see Windows debug and trace messages

&lt;center&gt;
Web &amp; Network
-------------
&lt;/center&gt;
[Firefox Portable][12] (with [Firebug][13])  
[OperaUSB][15]  -- Web browser  
[XamppLite][28]  -- Package that includes Apache, PHP, MySQL, phpMyAdmin, OpenSSL &amp; SQLite   
[PuTTY][17]  -- telnet and SSH client  
[Wireshark][18]  -- network protocol analyzer (packet sniffer)   
[WinSCP][25]  -- SFTP, FTP and SCP client for Windows  

&lt;center&gt;
Diff/Merge
----------
&lt;/center&gt;

[SourceGear DiffMerge][9] -- Compare two files side by side and merge if needed.   
[WinDiff][22]  -- File comparison tool  
[Winmerge][30]  -- &quot;Open Source differencing and merging tool for Windows.&quot;  

&lt;center&gt;
Unix-like Tools
---------------
&lt;/center&gt;
[GNU Utilities for Win32][16]  -- Windows version of several Unix/Linux tools  
[Cygwin][24]  -- Port of a Unix type environment to Windows  
[PowerGREP][49]  -- GREP tool  

&lt;center&gt;
Visual Studio &amp; .NET
--------------------
&lt;/center&gt;
[NUnit][42] -- Unit testing for .NET  
[TestDriven.NET][43] -- Easily run your unit tests from Visual Studio  
[AnkSVN][45]  -- Subversion plugin for Visual Studio  
[LINQPad][26]  -- Tool to interactively develop [Linq][27] queries.   

  - &quot;lets you interactively query SQL databases in a modern query language: LINQ&quot;

&lt;center&gt;
Regular Expression Tools
------------------------
&lt;/center&gt;
[Expresso][46] -- Regular Expression tool  
[RegexBuddy][48]  -- Regular Expression tool  

&lt;center&gt;
Misc
----
&lt;/center&gt;

[The Sysinterals Suite][5] (includes [DebugView][6], [Process Explorer][7], &amp; more)  
[WinZip][19]  
DosHere   
[7-zip][29]  -- Open source file archiver  
[Scrollbar fix for VB6][44]   
[puretext][50] -- Paste w/ formatting removed  
[VirtualBox][37]  -- Open source virtualization product. 

  - Similar to VMWare or VirtualPC  

 


  [1]: http://www.codeblocks.org/
  [2]: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_make_Code::Blocks_portable.3F
  [3]: http://www.portablepython.com/
  [4]: http://www.djangoproject.com/
  [5]: http://technet.microsoft.com/en-us/sysinternals/0e18b180-9b7a-4c49-8120-c47c5a693683.aspx
  [6]: http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
  [7]: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
  [8]: http://www.dependencywalker.com/
  [9]: http://www.sourcegear.com/diffmerge/
  [10]: http://www.red-gate.com/products/reflector/
  [11]: http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm
  [12]: http://portableapps.com/apps/internet/firefox_portable
  [13]: http://https://addons.mozilla.org/en-US/firefox/addon/1843
  [14]: http://notepad-plus.sourceforge.net/uk/site.htm
  [15]: http://www.opera-usb.com/operausben.htm
  [16]: http://unxutils.sourceforge.net/
  [17]: http://www.chiark.greenend.org.uk/~sgtatham/putty/
  [18]: http://www.wireshark.org/
  [19]: http://www.winzip.com/
  [20]: http://grantschenck.tripod.com/dbwinv2.htm
  [21]: http://www.yurisw.com/HEdit.htm
  [22]: http://www.grigsoft.com/download-windiff.htm
  [23]: http://www.vim.org/
  [24]: http://www.cygwin.com/
  [25]: http://winscp.net/
  [26]: http://www.linqpad.net
  [27]: http://en.wikipedia.org/wiki/Language_Integrated_Query
  [28]:  http://www.apachefriends.org/en/xampp-windows.html#646
  [29]: http://www.7-zip.org
  [30]: http://winmerge.org
  [31]: http://www.netbeans.org
  [32]: http://strawberryperl.com/
  [33]: http://www.mingw.org/
  [34]: https://stackoverflow.com/questions/352600/how-to-run-msvc-6-0-off-a-usb-drive-as-a-portable-app
  [35]: http://codelite.org/Main/ReadMore
  [36]: http://www.ultraedit.com/
  [37]: http://virtualbox.org/
  [38]: http://eclipse.org/
  [39]: http://python.org/
  [40]: http://www.e-texteditor.com/
  [41]: http://intype.info/home/index.php
  [42]: http://www.nunit.org/
  [43]: http://www.testdriven.net/
  [44]: http://www.joebott.com/vb6scrollwheel.htm
  [45]: http://ankhsvn.open.collab.net/
  [46]: http://www.ultrapico.com/Expresso.htm
  [47]: http://www.editpadpro.com/
  [48]: http://www.regexbuddy.com/
  [49]: http://www.powergrep.com/
  [50]: http://www.stevemiller.net/puretext/
  [51]: http://www.stackless.com/
  [52]: http://www.lua.org/
  [53]: http://www.jcreator.com/
  [54]: http://www.contexteditor.org/

What development tools do you carry on your USB drive?

I know that the #warning directive is not standard **C**/C++, but several compilers support it, including gcc/g++.  But for those that don&#39;t support it, will they silently ignore it or will it result in a compile failure?  In other words, can I safely use it in my project without breaking the build for compilers that don&#39;t support it?

Portability of #warning preprocessor directive

Why is this a warning? I think there are many cases when is more clear to use multi-char int constants instead of &quot;no meaning&quot; numbers or instead of defining const variables with same value. When parsing wave/tiff/other file types is more clear to compare the read values with some &#39;EVAW&#39;, &#39;data&#39;, etc instead of their corresponding values.

Sample code:

    int waveHeader = &#39;EVAW&#39;;

Why does this give a warning?

Multi-character constant warnings

How can I change my current working directory in C++ in a platform-agnostic way?

I found the `direct.h` header file, which is Windows compatible, and the `unistd.h`, which is UNIX/POSIX compatible.

Change the current working directory in C++

I have some class libraries with a non-trivial amount of existing code. The class libraries currently target .NET 4.0. Is there any guidance on how to convert these libraries to be portable libraries? From looking at the .csproj, it doesn&#39;t appear that there are a lot of differences:

    &lt;Import Project=&quot;$(MSBuildExtensionsPath32)\Microsoft\Portable\$(TargetFrameworkVersion)\Microsoft.Portable.CSharp.targets&quot; /&gt;

and

    &lt;ProjectTypeGuids&gt;{786C830F-07A1-408B-BD7F-6EE04809D6DB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}&lt;/ProjectTypeGuids&gt;

Is it a good or bad idea to try converting an existing class library to be a portable library?



Is there any guidance on converting existing .NET class libraries to portable libraries?

I need to write code that should run equally well in Octave and on MATLAB. Problem is that it needs to do some GUI stuff, which MATLAB and Octave handle completely differently.

Is there a way I can detect if I&#39;m running MATLAB or Octave, in order to call the right function?

How do I detect if I&#39;m running MATLAB or Octave?

I would like to use some  gcc warning switchs that aren&#39;t available in older gcc versions (eg. -Wtype-limits).

Is there an easy way to check the gcc version and only add those extra options if a recent gcc is used ?


All Portability Solutions on Gang of Coders

Total of 30 Portability Solutions