Your message dated Tue, 23 Dec 2025 13:06:33 +0100
with message-id <[email protected]>
and subject line [email protected]
has caused the Debian Bug report #598225,
regarding SSMTP fails to compile on Solaris 10
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
598225: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=598225
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: ssmtp
Version: 2.64-4
Solaris 10 does not implement strnlen(). The attached patch copies
libc's (eglibc) implementation inline.
After this, it compiles fine using gcc 3.4.x from /usr/sfw/bin/gcc.
Regards,
--
----)(-----
Luis Mondesi
Maestro Debiano
----- START ENCRYPTED BLOCK (Triple-ROT13) ------
Gur Hohagh [Yvahk] qvfgevohgvba oevatf gur fcvevg bs Hohagh gb gur
fbsgjner jbeyq.
----- END ENCRYPTED BLOCK (Triple-ROT13) ------
diff -u ssmtp-2.64-orig/ssmtp.c ssmtp-2.64-sun10/ssmtp.c
--- ssmtp-2.64-orig/ssmtp.c 2010-09-24 15:41:27.045521536 -0400
+++ ssmtp-2.64-sun10/ssmtp.c 2010-09-24 15:39:34.232090226 -0400
@@ -99,6 +99,143 @@
#if defined (__SVR4) && defined (__sun)
/*
+strnlen() - Unimplemented by the Solaris 10 libc.
+*/
+
+/* Find the length of S, but scan at most MAXLEN characters. If no
+ '\0' terminator is found in that many characters, return MAXLEN. */
+size_t
+strnlen (const char *str, size_t maxlen)
+{
+ const char *char_ptr, *end_ptr = str + maxlen;
+ const unsigned long int *longword_ptr;
+ unsigned long int longword, magic_bits, himagic, lomagic;
+
+ if (maxlen == 0)
+ return 0;
+
+ if (__builtin_expect (end_ptr < str, 0))
+ end_ptr = (const char *) ~0UL;
+
+ /* Handle the first few characters by reading one character at a time.
+ Do this until CHAR_PTR is aligned on a longword boundary. */
+ for (char_ptr = str; ((unsigned long int) char_ptr
+ & (sizeof (longword) - 1)) != 0;
+ ++char_ptr)
+ if (*char_ptr == '\0')
+ {
+ if (char_ptr > end_ptr)
+ char_ptr = end_ptr;
+ return char_ptr - str;
+ }
+
+ /* All these elucidatory comments refer to 4-byte longwords,
+ but the theory applies equally well to 8-byte longwords. */
+
+ longword_ptr = (unsigned long int *) char_ptr;
+
+ /* Bits 31, 24, 16, and 8 of this number are zero. Call these bits
+ the "holes." Note that there is a hole just to the left of
+ each byte, with an extra at the end:
+
+ bits: 01111110 11111110 11111110 11111111
+ bytes: AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD
+
+ The 1-bits make sure that carries propagate to the next 0-bit.
+ The 0-bits provide holes for carries to fall into. */
+ magic_bits = 0x7efefeffL;
+ himagic = 0x80808080L;
+ lomagic = 0x01010101L;
+ if (sizeof (longword) > 4)
+ {
+ /* 64-bit version of the magic. */
+ /* Do the shift in two steps to avoid a warning if long has 32 bits. */
+ magic_bits = ((0x7efefefeL << 16) << 16) | 0xfefefeffL;
+ himagic = ((himagic << 16) << 16) | himagic;
+ lomagic = ((lomagic << 16) << 16) | lomagic;
+ }
+ if (sizeof (longword) > 8)
+ abort ();
+
+ /* Instead of the traditional loop which tests each character,
+ we will test a longword at a time. The tricky part is testing
+ if *any of the four* bytes in the longword in question are zero. */
+ while (longword_ptr < (unsigned long int *) end_ptr)
+ {
+ /* We tentatively exit the loop if adding MAGIC_BITS to
+ LONGWORD fails to change any of the hole bits of LONGWORD.
+
+ 1) Is this safe? Will it catch all the zero bytes?
+ Suppose there is a byte with all zeros. Any carry bits
+ propagating from its left will fall into the hole at its
+ least significant bit and stop. Since there will be no
+ carry from its most significant bit, the LSB of the
+ byte to the left will be unchanged, and the zero will be
+ detected.
+
+ 2) Is this worthwhile? Will it ignore everything except
+ zero bytes? Suppose every byte of LONGWORD has a bit set
+ somewhere. There will be a carry into bit 8. If bit 8
+ is set, this will carry into bit 16. If bit 8 is clear,
+ one of bits 9-15 must be set, so there will be a carry
+ into bit 16. Similarly, there will be a carry into bit
+ 24. If one of bits 24-30 is set, there will be a carry
+ into bit 31, so all of the hole bits will be changed.
+
+ The one misfire occurs when bits 24-30 are clear and bit
+ 31 is set; in this case, the hole at bit 31 is not
+ changed. If we had access to the processor carry flag,
+ we could close this loophole by putting the fourth hole
+ at bit 32!
+
+ So it ignores everything except 128's, when they're aligned
+ properly. */
+
+ longword = *longword_ptr++;
+
+ if ((longword - lomagic) & himagic)
+ {
+ /* Which of the bytes was the zero? If none of them were, it was
+ a misfire; continue the search. */
+
+ const char *cp = (const char *) (longword_ptr - 1);
+
+ char_ptr = cp;
+ if (cp[0] == 0)
+ break;
+ char_ptr = cp + 1;
+ if (cp[1] == 0)
+ break;
+ char_ptr = cp + 2;
+ if (cp[2] == 0)
+ break;
+ char_ptr = cp + 3;
+ if (cp[3] == 0)
+ break;
+ if (sizeof (longword) > 4)
+ {
+ char_ptr = cp + 4;
+ if (cp[4] == 0)
+ break;
+ char_ptr = cp + 5;
+ if (cp[5] == 0)
+ break;
+ char_ptr = cp + 6;
+ if (cp[6] == 0)
+ break;
+ char_ptr = cp + 7;
+ if (cp[7] == 0)
+ break;
+ }
+ }
+ char_ptr = end_ptr;
+ }
+
+ if (char_ptr > end_ptr)
+ char_ptr = end_ptr;
+ return char_ptr - str;
+}
+/*
strndup() - Unimplemented by the Solaris libc.
*/
char * strndup(char const *s, size_t n)
--- End Message ---
--- Begin Message ---
This is interesting but not really relevant for Debian. Please file an
upstream bug if you are still interested in this.
--- End Message ---
