Are there any platforms where using structure copy on an fd_set (for select() or pselect()) causes problems?

by

Since struct fd_set is just a regular C structure, that should always be fine. I personally don’t like doing structure copying via the = operator, since I’ve worked on plenty of platforms that didn’t have access to the normal set of compiler intrinsics. Using memcpy() explicitly rather than having the compiler insert a function call is a better way to go, in my book.

From the C spec, section 6.5.16.1 Simple assignment (edited here for brevity):

One of the following shall hold:

…

  • the left operand has a qualified or unqualified version of a structure or union type compatible with the type of the right;

…

In simple assignment (=), the value of the right operand is converted to the type of the assignment expression and replaces the value stored in the object designated by the left operand.

If the value being stored in an object is read from another object that overlaps in any way the storage of the first object, then the overlap shall be exact and the two objects shall have qualified or unqualified versions of a compatible type; otherwise, the behavior is undefined.

So there you go, as long as struct fd_set is a actually a regular C struct, you’re guaranteed success. It does depend, however, on your compiler emitting some kind of code to do it, or relying on whatever memcpy() intrinsic it uses for structure assignment. If your platform can’t link against the compiler’s intrinsic libraries for some reason, it may not work.

You will have to play some tricks if you have more open file descriptors than will fit into struct fd_set. The linux man page says:

An fd_set is a fixed size buffer. Executing FD_CLR() or FD_SET() with a value of fd that is negative or is equal to or larger than FD_SETSIZE will result in undefined behavior. Moreover, POSIX requires fd to be a valid file descriptor.

As mentioned below, it might not be worth the effort to prove that your code is safe on all systems. FD_COPY() is provided for just such a use, and is, presumably, always guaranteed:

FD_COPY(&fdset_orig, &fdset_copy) replaces an already allocated &fdset_copy file descriptor set with a copy of &fdset_orig.

More Related Contents:

  1. How can I convert a file pointer ( FILE* fp ) to a file descriptor (int fd)?
  2. How do I make this Linux program compile? [closed]
  3. printf anomaly after “fork()”
  4. How to make child process die after parent exits?
  5. What is the equivalent to Posix popen() in the Win32 API?
  6. How to capture Control+D signal?
  7. Why does this program print “forked!” 4 times?
  8. In C how do you redirect stdin/stdout/stderr to files when making an execvp() or similar call?
  9. stdout thread-safe in C on Linux?
  10. What does the brk() system call do?
  11. Why does ENOENT mean “No such file or directory”?
  12. POSIX API call to list all the pthreads running in a process
  13. Merge multiple .so shared libraries
  14. Re-opening stdout and stdin file descriptors after closing them
  15. Turn a simple socket into an SSL socket
  16. How do I get a thread ID from an arbitrary pthread_t?
  17. After forking, are global variables shared?
  18. Set environment variables in C
  19. Are file descriptors shared when fork()ing?
  20. Detecting 64bit compile in C
  21. How to get the current time in milliseconds from C in Linux?
  22. Recursive mkdir() system call on Unix
  23. fd leak, custom Shell
  24. Is there an equivalent to WinAPI’s MAX_PATH under linux/unix?
  25. Linux/POSIX equivalent for Win32’s CreateEvent, SetEvent, WaitForSingleObject
  26. Questions about putenv() and setenv()
  27. In C, what’s the size of stdout buffer?
  28. What can cause a “Resource temporarily unavailable” on sock send() command
  29. Linux shared memory: shmget() vs mmap()?
  30. How to know if a Linux system call is restartable or not?

Leave a Comment