Actually I think they're origin-1 so limit is 9. My guess is that whoever implemented it got lazy, figured they'd just look at the first digit--the parser is a LOT more complex if you have to look ahead to find the end of the digits!
Hmm, and that got me curious about what C is *supposed* to do with an undefined substitution type, e.g., %Z. Apparently the C standard does not define the behavior! I tried it and z/OS does what it did in this case: eats it entirely. E.g., if your message was: Here is %Z < (where you perhaps meant %s) it would output Here is < as it does with %10%s. LLVM C apparently outputs the substitution type as a literal, i.e., Here is %Z < which I would submit follows the Principle of Least Astonishment more closely. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Charles Mills Sent: Thursday, October 2, 2025 7:16 PM To: [email protected] Subject: Re: Anyone using XL C? I have used the numbered printf arguments feature a whole bunch. I think the C standard allows an implementation to set a maximum argument number, and IBM chose 10, so it's not a bug, it's an implementation restriction. Annoying. If I were a billion dollar company implementing C on a multi-gigabyte machine I would have chosen 999 or something like that -- but that's just me. Charles On Thu, 2 Oct 2025 16:21:18 -0400, Phil Smith III <[email protected]> wrote: >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 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
