[MacPorts] #46623: procmail @3.22 on OS X Yosemite hits "Abort trap: 6" if variable assignment uses backticks

[MacPorts]

#46623: procmail @3.22 on OS X Yosemite hits "Abort trap: 6" if variable assignment
uses backticks
-------------------------+--------------------------------
  Reporter:  macports@…  |      Owner:  macports-tickets@…
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.3.3
Resolution:  fixed       |   Keywords:
      Port:  procmail    |
-------------------------+--------------------------------

Comment (by csanchezdll):

 Just for completeness, I did a small experiment with this program:
 {{{
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>

 #define STRING "test"

 int
 main (int argc, char *argv[])
 {
   char p[sizeof (STRING)] = STRING;
   char *q = p;

   strlcpy (q, p, sizeof (STRING));

   puts (p);

   exit (EXIT_SUCCESS);
 }
 }}}

 Under NetBSD, it works ok and prints "test" (I do not have access to a
 FreeBSD box at the moment).

 Under OS X, it aborts ("Abort trap: 6", same as procmail). As an
 interesting side note, if I change {{{sizeof (STRING)}}} by {{{strlen (p)
 + 1}}} I get the following warning (only under OS X):
 {{{
 test.c:13:26: warning: size argument in '__builtin___strlcpy_chk' call
 appears
       to be size of the source; expected the size of the destination
       [-Wstrlcpy-strlcat-size]
   strlcpy (q, p, strlen (p) + 1);
                  ~~~~~~~~^~~~~~
 /usr/include/secure/_string.h:108:34: note: expanded from macro 'strlcpy'
                 __builtin___strlcpy_chk (dest, __VA_ARGS__,
 __darwin_obs...
                                                ^~~~~~~~~~~
 1 warning generated.
 }}}
 This suggests OS X compiler has some built-in for {{{strlcpy}}} that might
 have a different behavior than BSD libraries.

 I agree OS X behavior is correct, as the man page says overlapping buffers
 yield undefined behavior. This should really be fixed upstream in
 procmail. But it has been unmaintained for years and the code for parsing
 is really difficult to follow. So using the provided replacement just gets
 the work done.

-- 
Ticket URL: <https://trac.macports.org/ticket/46623#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS