[SOLVED] cstdlib not able to resolve using ::wcstombs

Issue

I upgraded my system to fedora 33 after which I observed that stdlib.h was not able to resolve some data structures:

In file included from /usr/include/c++/10/cstdlib:75,
                 from /usr/include/c++/10/ext/string_conversions.h:41,
                 from /usr/include/c++/10/bits/basic_string.h:6545,
                 from /usr/include/c++/10/string:55,
                 from /home/ideepika/ceph5/ceph/src/rocksdb/include/rocksdb/cache.h:27,
                 from /home/ideepika/ceph5/ceph/src/rocksdb/cache/clock_cache.h:12,
                 from /home/ideepika/ceph5/ceph/src/rocksdb/cache/clock_cache.cc:10:
/usr/include/stdlib.h:935:5: error: expected initializer before ‘__attr_access’
  935 |     __attr_access ((__read_only__, 2));
      |     ^~~~~~~~~~~~~
/usr/include/stdlib.h:940:3: error: expected initializer before ‘__attr_access’
  940 |   __attr_access ((__write_only__, 1, 3)) __attr_access ((__read_only__, 2));
      |   ^~~~~~~~~~~~~
/usr/include/stdlib.h:994:30: error: expected initializer before ‘__attr_access’
  994 |      __THROW __nonnull ((2)) __attr_access ((__write_only__, 2, 3));
      |                              ^~~~~~~~~~~~~
In file included from /usr/include/c++/10/ext/string_conversions.h:41,
                 from /usr/include/c++/10/bits/basic_string.h:6545,
                 from /usr/include/c++/10/string:55,
                 from /home/ideepika/ceph5/ceph/src/rocksdb/include/rocksdb/cache.h:27,
                 from /home/ideepika/ceph5/ceph/src/rocksdb/cache/clock_cache.h:12,
                 from /home/ideepika/ceph5/ceph/src/rocksdb/cache/clock_cache.cc:10:
/usr/include/c++/10/cstdlib:154:11: error: ‘mbstowcs’ has not been declared in ‘::’
  154 |   using ::mbstowcs;
      |           ^~~~~~~~
/usr/include/c++/10/cstdlib:171:11: error: ‘wcstombs’ has not been declared in ‘::’
  171 |   using ::wcstombs;
      |           ^~~~~~~~

the source of error is merely because of #include and hence the source code from rocksdb doesn't looks suspicious.

Investigating... will update with relevant details, let me know if more details need to added

Solution

turns out there is recent patch added to cstdlib: https://www.cygwin.com/bugzilla/attachment.cgi?id=12133

that might have been uncaught, I did not investigate the related files right now, but the adding the minimal changes patchset if someone else bumps to this issue...

diff --git a/stdlib.h b/stdlib.h
index f255e4a..d88ef89 100644
--- a/stdlib.h
+++ b/stdlib.h
@@ -931,10 +931,11 @@ extern int wctomb (char *__s, wchar_t __wchar) __THROW;
 
 /* Convert a multibyte string to a wide char string.  */
 extern size_t mbstowcs (wchar_t *__restrict  __pwcs,
-                       const char *__restrict __s, size_t __n) __THROW
+                       const char *__restrict __s, size_t __n) __THROW;
 /* Convert a wide char string to multibyte string.  */
 extern size_t wcstombs (char *__restrict __s,
-                       const wchar_t *__restrict __pwcs, size_t __n) __THROW
+                       const wchar_t *__restrict __pwcs, size_t __n)
+     __THROW;
 
 #ifdef __USE_MISC
 /* Determine whether the string value of RESPONSE matches the affirmation
@@ -988,7 +989,7 @@ extern char *ptsname (int __fd) __THROW __wur;
    terminal associated with the master FD is open on in BUF.
    Return 0 on success, otherwise an error number.  */
 extern int ptsname_r (int __fd, char *__buf, size_t __buflen)
-     __THROW __nonnull ((2))
+     __THROW __nonnull ((2));

Answered By - Deepika Upadhyay

Answer Checked By - David Goodson (WPSolving Volunteer)