[9fans] uvlong does not work on 9legacy raspberry pi image

[9fans] uvlong does not work on 9legacy raspberry pi image

[hahahahacker2009]

[-- Attachment #1: Type: text/plain, Size: 542 bytes --]

I'm writing a program that use uvlong on 9legacy raspberry pi.
uvlong n;
scanf("%lld", &n);
print("%lld", n);
But after compiling the program and input a small number (8), it print 0. I modified it and compile with pcc, but it print a very big number then.
unsigned long works. What's the problem with uvlong?
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T3df06e15ad1bc104-Mac03b7f4a672ca1629a2c403
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1131 bytes --]

Re: [9fans] uvlong does not work on 9legacy raspberry pi image

[Ori Bernstein]

...Wait. I just realized that 9front has fixed this on
these commits. I should have remembered because I was
the one that fixed it...

Initial commit to ape:

        73f38fc5460cb68662dd237022bda636ad734045

Sync to /sys/src:

        bc1cc79225f0b006dd66d4fd81030d06f83bfca2

On Mon, 19 May 2025 10:26:15 -0400
ori@eigenstate.org wrote:

> Quoth hahahahacker2009 <hahahahacker2009@gmail.com>:
> > I'm writing a program that use uvlong on 9legacy raspberry pi.
> > uvlong n;
> > scanf("%lld", &n);
> > print("%lld", n);
> > But after compiling the program and input a small number (8), it print 0. I modified it and compile with pcc, but it print a very big number then.
> > unsigned long works. What's the problem with uvlong?
> 
> the problem is with scanf; it doesn't handle that case:
> 
> static int icvt_n(FILE *f, va_list *args, int store, int width, int type){
>         if(store){
>                 --ncvt; /* this assignment doesn't count! */
>                 switch(type){
>                 case 'h': *va_arg(*args, short *)=nread; break;
>                 case 'n': *va_arg(*args, int *)=nread; break;
>                 case 'l':
>                 case 'L': *va_arg(*args, long *)=nread; break;
>                 }
>         }
>         return 1;
> }
> 
> A patch to fix this would be welcome, but Plan 9 code doesn't
> tend to use scanf; Unix code is also best off avoiding scanf,
> it's an API that feels convienient but has a number of pitfalls.
> Specifically, if there's a format mismatch, the remainder of the
> input remains buffered, and you need fiddly error handling code
> to consume it.
> 
> Here's probably how I'd write it:
> 
> char *e;
> uvlong n;
> 
> ln = Brdstr(bfd, '\n', 1);
> n = strtoull(ln, &e, 0);
> if(*e != '\0')
>         print("trailing junk\n");
> printf("%llud\n", n);
> free(ln);
> 
> it's a little more code, but it keeps working as the code gets
> more functional.
> 
> If I want to handle more complex input, I'd tend to reach for
> tokenize(2) -- which loosely the format a lot of programs use.
> For example:
> 
> char *e, *sp[4];
> uvlong n1, n2;
> int n;
> 
> ln = Brdstr(bfd, '\n', 1);
> n = tokenize(ln, sp, nelem(sp));
> switch(n){
> case 1:
>         if(strcmp(sp[0], "greet") != 0)
>                 sysfatal("unknown command");
>         print("hello world\n");
>         break;
> case 3:
>         if(strcmp(sp[0], "sum") != 0)
>                 sysfatal("unknown command");
>         n1 = strtoull(sp[1], &e, 0);
>         if(*e != 0)
>                 sysfatal("invalid number\n");
>         n2 = strtoull(sp[2], &e, 0);
>         if(*e != 0)
>                 sysfatal("invalid number\n");
>         print("2*arg: %lld\n", n1+n2);
>         break;
> default:
>         sysfatal("invalid line");
>         break;
> }
> free(ln);
> 
> (Subtle point: I have n+1 entries in sp[] to detect that
> too many fields were passed).
> 


-- 
Ori Bernstein <ori@eigenstate.org>

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T3df06e15ad1bc104-M51109fdec96a1bb86f620204
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] uvlong does not work on 9legacy raspberry pi image

[Frank D. Engel, Jr.]

In standard C, the "u" replaces the "d", so no, I didn't mix it up.

That is, of course, unless the Plan 9 C compilers require using 
nonstandard format specifiers for unsigned integers - to be honest, I 
haven't really checked that.


On 5/19/25 06:35, sirjofri via 9fans wrote:
> 19.05.2025 11:06:20 Frank D. Engel, Jr. <fde101@fjrhome.net>:
>> Just to point it out, you should technically be using %llu instead of %lld for an unsigned value, though that would not explain the problems described here.
> Are you sure you don't mix this up with %ulld?
> 
> Idk, I never used scanf on plan 9. I can imagine that using the proper format fixes the problems, though I also don't fully understand why the problems occur like they're described.
> 
> sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T3df06e15ad1bc104-M955764cad20ccad45e3a8cda
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription