Thanks, Bernd and Rich! The 1$ etc. are key: that's where the number limitation surely comes in. Those let you reorder substitutions, so if you're doing NLS, you can have the substitutions in the appropriate order for the language you're using. Of course now I can't think of a good, realistic example, but let's say in English the message is:
&1 &2 found e.g. 4 pineapples found and in French, the syntax is "Ananas trouvee sont 4" (I think that's correct French, if probably oddly worded--pretty sure you could say "4 ananas trouvee" just fine, but let's assume you have to reorder). Your message processor uses the %1$d and %2$s: English: &1 &2 found French: &2 trouvee sont &1 Looks like a runtime library bug. Of course I can't report it since I'm not a "real" IBM customer, but at least it's on (some form of) the record now... I'd note that with optimization on and/or just because the original code calling this is a lot more complex, it wasn't just failing to substitute--it was S0C4ing. Nasty. My guy spent a LONG time trying to figure out what he was getting wrong, of course. Thanks again, ...phsiii -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Bernd Oppolzer Sent: Thursday, October 2, 2025 4:52 PM To: [email protected] Subject: Re: Anyone using XL C? I did some tests with the MVS variant of z/OS XL C (V3.1). In the first run, I had problems with snprintf, because it is not part of the ANSI cosmos, which I am accustomed to use, so I changed this to sprintf and omitted the length parameter. Same result. Test msg 10 parm P1: aaaaa P2: bbbbb P3: ccccc P4: ddddd P5: eeeee P6: fffff P7: ggggg P8: hhhhh P9: iiiii P10: P11: < Then I omitted the 1$ flags etc., because they seem strange to me; I don't know what they are doing. I simply used %s everywhere. The parameter strings are NULL-terminated, after all. Now I get: Test msg 10 parm P1: aaaaa P2: bbbbb P3: cccccP4: ddddd P5: eeeee P6: fffff P7: ggggg P8: hhhhh P9: iiiii P10: jjjjj P11: kkkkk < Here the modified source code: #include<stdio.h> int main( int argc, char **argv ){ char b[4096]; sprintf (b, "Test msg 10 parm P1: %s P2: %s P3: %s" "P4: %s P5: %s \n P6: %s P7: %s P8: %s P9: %s " "P10: %s P11: %s <", "aaaaa","bbbbb","ccccc","ddddd","eeeee","fffff", "ggggg","hhhhh","iiiii","jjjjj","kkkkk"); printf( "%s\n", b ); return 0; } HTH, kind regards Bernd Test msg 10 parm P1: aaaaa P2: bbbbb P3: cccccP4: ddddd P5: eeeee P6: fffff P7: ggggg P8: hhhhh P9: iiiii P10: jjjjj P11: kkkkk < Am 02.10.2025 um 22:21 schrieb Phil Smith III: > If so, can you try this trivial program from USS (or the MVS side, I don't > care, but it's easier from USS): > > ------------------- > #include<stdio.h> > int main( int argc, char **argv ){ > char b[4096]; > snprintf( b, 4096, "Test msg 10 parm P1: %1$s P2: %2$s P3: %3$s P4: %4$s > P5: %5$s P6: %6$s P7: %7$s P8: %8$s P9: %9$s P10: %10$s P11: %11$s > <","aaaaa","bbbbb","ccccc","ddddd","eeeee","fffff","ggggg","hhhhh","iiiii","jjjjj","kkkkk"); > printf( "%s\n", b ); > return 0; > } > ------------------- > > * To build (assuming you named it bug.c): > c89 bug.c > > ------------------- > > * Then: > ./a.out > > ------------------- > > * I get this output on my z/OS system: > Test msg 10 parm P1: aaaaa P2: bbbbb P3: ccccc P4: ddddd P5: eeeee P6: > fffff P7: ggggg P8: hhhhh P9: iiiii P10: P11: < > > * That should have been: > Test msg 10 parm P1: aaaaa P2: bbbbb P3: ccccc P4: ddddd P5: eeeee P6: > fffff P7: ggggg P8: hhhhh P9: iiiii P10: jjjjj P11: kkkkk < > > ------------------- > > It appears that the XLC runtime doesn't handle more than 9 arguments using > the %n$s format (at least). We found this because some new code was blowing > up, and we of course assumed it was something wrong with one of the many > formats (they aren't all just s-type). > > The compiler listings say just: > 15650ZOS V2.4 z/OS XL C > > I'm hoping someone with a newer version can confirm that this is fixed. We're > going to have to work around it anyway, because it's not that hard (we only > have one such example) and I'd rather not require an IBM PTF for our > customers. > > Thanks... > > ...phsiii > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
