Pacaging/build issues with AIX and vac (dovecot-2.2.25)
Michael Felt
michael at felt.demon.nl
Mon Oct 10 16:46:26 UTC 2016
On 10/10/2016 14:59, Stephan Bosch wrote:
> It should be supported by AIX:
>
> https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.xlcpp1313.aix.doc/language_ref/compound_literals.html
>
>
> I have no idea why it would fail here.
I see it is also in version 11 - so, maybe still syntax:
This is the doc:
The following example passes a constant structure variable of type point
containing two integer members to the function drawline:
drawline((struct point){6,7});
While the code is:
.challenges = (struct http_auth_challenge_test []) {
{ .scheme = "Basic",
.data = NULL,
.params = (struct http_auth_param []) {
{ "realm", "WallyWorld" }, { NULL, NULL }
}
},{
.scheme = NULL
}
The difference I notice is that, much prettier btw, you are also specifying the struct .names, and perhaps, in
Compound literal syntax
.-,----------------.
V |
>>-(--/type_name/--)--{----/initializer_list/-+--}-----------------><
"initializer_list" is exclusive of (additional) declarers.
The messages seem to indicate the parser does not like them being there...
"test-http-auth.c", line 27.27: 1506-022 (S) "scheme" is not a member of "const struct http_auth_challenges_test".
"test-http-auth.c", line 27.37: 1506-196 (W) Initialization between types "struct http_auth_challenge_test* const" and "char*" is not allowed.
"test-http-auth.c", line 28.33: 1506-022 (S) "data" is not a member of "const struct http_auth_challenges_test".
"test-http-auth.c", line 28.41: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 29.33: 1506-022 (S) "params" is not a member of "const struct http_auth_challenges_test".
"test-http-auth.c", line 30.43: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 30.52: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 30.70: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 30.76: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
To understand|study it, I simplified it to:
+7 #include "http-auth.h"
+8
+9 struct http_auth_challenge_test {
+10 const char *scheme;
+11 const char *data;
+12 struct http_auth_param *params;
+13 };
+14
+15 struct http_auth_challenges_test {
+16 const char *challenges_in;
+17 struct http_auth_challenge_test *challenges;
+18 };
+19
+20 /* Valid auth challenges tests */
+21 static struct http_auth_challenges_test
+22 valid_auth_challenges_tests[] = {
+23 { "Basic realm=\"WallyWorld\"",
+24 "Basic",
+25 NULL,
+26 "realm", "WallyWorld",
+27 NULL, NULL
+28 },{
+29 NULL,
+30 NULL,
+31 NULL, NULL
+32 }
+33 };
(lots of experimenting!)
I got it down to these messages:
"test-http-auth.c", line 24.25: 1506-196 (W) Initialization between types "struct http_auth_challenge_test*" and "char*" is not allowed.
"test-http-auth.c", line 25.25: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 26.26: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 26.35: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 27.26: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 27.32: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 31.25: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
"test-http-auth.c", line 31.31: 1506-026 (S) Number of initializers cannot be greater than the number of aggregate members.
As 'it' kept complaining about the unnecessary opening { I am thinking that their design does not leave space fot nesting arrarys of initialization. And I would tend to agree with there being 'lazy'.
That does not fix my problem. Going to look for a - maybe less elegant - but workable (and if found I hope acceptable) work-around.
More information about the dovecot
mailing list