Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #57909 > unrolled thread

I need to vent some steam

Back to article view | Back to comp.lang.c

Contents

  I need to vent some steam Anders Wegge Keller <wegge@geostat.dk> - 2015-03-05 17:01 +0100
    Re: I need to vent some steam Morris Dovey <mrdovey@iedu.com> - 2015-03-05 10:32 -0600
    Re: I need to vent some steam Richard Heathfield <rjh@cpax.org.uk> - 2015-03-05 17:04 +0000
      Re: I need to vent some steam Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-05 17:42 +0000
      Re: I need to vent some steam glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-05 19:16 +0000
        Re: I need to vent some steam jacob navia <jacob@spamsink.net> - 2015-03-05 20:47 +0100
      Re: I need to vent some steam Anders Wegge Keller <wegge@geostat.dk> - 2015-03-05 20:52 +0100
      Re: I need to vent some steam Kaz Kylheku <kaz@kylheku.com> - 2015-03-05 22:20 +0000
    Re: I need to vent some steam Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-05 17:51 +0000
    Re: I need to vent some steam Kaz Kylheku <kaz@kylheku.com> - 2015-03-05 22:20 +0000
    Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-05 23:14 -0800
      Re: I need to vent some steam Bartc <bc@freeuk.com> - 2015-03-06 10:41 +0000
        Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-06 08:03 -0800
          Re: I need to vent some steam Bartc <bc@freeuk.com> - 2015-03-06 16:50 +0000
            Re: I need to vent some steam Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-06 15:32 -0800
            Re: I need to vent some steam Öö Tiib <ootiib@hot.ee> - 2015-03-07 07:59 -0800
              Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-07 16:22 -0800
                Re: I need to vent some steam James Kuyper <jameskuyper@verizon.net> - 2015-03-07 19:45 -0500
                  Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-07 17:21 -0800
                    Re: I need to vent some steam Bartc <bc@freeuk.com> - 2015-03-08 10:29 +0000
                      Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-08 13:37 -0700
            Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-07 16:20 -0800
          Re: I need to vent some steam Anders Wegge Keller <wegge@geostat.dk> - 2015-03-06 17:54 +0100
            Re: I need to vent some steam Geoff <geoff@invalid.invalid> - 2015-03-06 09:58 -0800
      Re: I need to vent some steam Morris Dovey <mrdovey@iedu.com> - 2015-03-07 02:29 -0600
        Re: I need to vent some steam Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-07 11:01 +0000
        Re: I need to vent some steam Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 10:46 -0700
    Re: I need to vent some steam Richard Damon <Richard@Damon-Family.org> - 2015-03-06 08:34 -0500
      Re: I need to vent some steam Les Cargill <lcargill99@comcast.com> - 2015-03-06 08:17 -0600
        Re: I need to vent some steam Keith Thompson <kst-u@mib.org> - 2015-03-06 08:02 -0800
        Re: I need to vent some steam Richard Damon <Richard@Damon-Family.org> - 2015-03-06 22:38 -0500
      Re: I need to vent some steam Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-06 15:44 -0800
        Re: I need to vent some steam Ian Collins <ian-news@hotmail.com> - 2015-03-07 13:35 +1300
    Re: I need to vent some steam Ian Collins <ian-news@hotmail.com> - 2015-03-07 07:42 +1300
    Re: I need to vent some steam raltbos@xs4all.nl (Richard Bos) - 2015-03-06 22:51 +0000
    Re: I need to vent some steam Michael Angelo Ravera <maravera@prodigy.net> - 2015-03-06 16:48 -0800
    Re: I need to vent some steam Xcott Craver <xcottcraver@gmail.com> - 2015-03-09 08:52 -0700
      Re: I need to vent some steam Anders Wegge Keller <wegge@geostat.dk> - 2015-03-09 21:11 +0100
        Re: I need to vent some steam Kaz Kylheku <kaz@kylheku.com> - 2015-03-09 20:16 +0000
          Re: I need to vent some steam Anders Wegge Keller <wegge@geostat.dk> - 2015-03-09 21:38 +0100
            Re: I need to vent some steam Kaz Kylheku <kaz@kylheku.com> - 2015-03-09 20:54 +0000
              Re: I need to vent some steam David Brown <david.brown@hesbynett.no> - 2015-03-10 09:02 +0100
                Re: I need to vent some steam Robert Wessel <robertwessel2@yahoo.com> - 2015-03-10 05:34 -0500
          Re: I need to vent some steam Robert Wessel <robertwessel2@yahoo.com> - 2015-03-09 19:15 -0500
        Re: I need to vent some steam Keith Thompson <kst-u@mib.org> - 2015-03-10 07:55 -0700

Page 1 of 3  [1] 2 3  Next page →

#57909 — I need to vent some steam

 While porting the code for a rather large airport from SCO to Linux, I've
come across this example of "Which wheel do you want to reinvent today?"

char *pint(char *buf, int len, int val) {
    int dval;

    for (len--; len >= 0; len--) {
        dval = val % 10;
        val -= dval;
        buf[len] = (char)('0' + dval);
        val /= 10;
    }
    return buf;
}

 The whole code base is filled with dubious constructs like this,
encompassing a strange mix of programming paradigms, including what looks
like an attempt at functional programming via RPC calls. This gem was the
straw that broke the camel's back.

-- 
//Wegge

[toc] | [next] | [standalone]

#57910

On 3/5/15 10:01 AM, Anders Wegge Keller wrote:
> char *pint(char *buf, int len, int val) {
>      int dval;
>
>      for (len--; len >= 0; len--) {
>          dval = val % 10;
>          val -= dval;
>          buf[len] = (char)('0' + dval);
>          val /= 10;
>      }
>      return buf;
> }

Just a WAG, but it looks like someone was having performance issues with 
printf()...

-- 
Morris Dovey

[toc] | [prev] | [next] | [standalone]

#57911

On 05/03/15 16:01, Anders Wegge Keller wrote:
>   While porting the code for a rather large airport from SCO to Linux, I've
> come across this example of "Which wheel do you want to reinvent today?"
>
> char *pint(char *buf, int len, int val) {
>      int dval;
>
>      for (len--; len >= 0; len--) {
>          dval = val % 10;
>          val -= dval;
>          buf[len] = (char)('0' + dval);
>          val /= 10;
>      }
>      return buf;
> }

Just out of curiosity, was the airport planning to null-terminate that 
string at some point?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#57912

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 05/03/15 16:01, Anders Wegge Keller wrote:
>>   While porting the code for a rather large airport from SCO to Linux, I've
>> come across this example of "Which wheel do you want to reinvent today?"
>>
>> char *pint(char *buf, int len, int val) {
>>      int dval;
>>
>>      for (len--; len >= 0; len--) {
>>          dval = val % 10;
>>          val -= dval;
>>          buf[len] = (char)('0' + dval);
>>          val /= 10;
>>      }
>>      return buf;
>> }
>
> Just out of curiosity, was the airport planning to null-terminate that
> string at some point?

You don't know it isn't null-terminated already!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#57915

Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 05/03/15 16:01, Anders Wegge Keller wrote:

(snip)
>> char *pint(char *buf, int len, int val) {
>>      int dval;
>>
>>      for (len--; len >= 0; len--) {
>>          dval = val % 10;
>>          val -= dval;
>>          buf[len] = (char)('0' + dval);
>>          val /= 10;
>>      }
>>      return buf;
>> }
 
> Just out of curiosity, was the airport planning to null-terminate that 
> string at some point?

Seems to me that it has the convenience that you can write into
the middle of an existing string.  That is often useful in filling
in pages for display.

-- glen

[toc] | [prev] | [next] | [standalone]

#57918

Le 05/03/2015 20:16, glen herrmannsfeldt a écrit :
> Seems to me that it has the convenience that you can write into
> the middle of an existing string.  That is often useful in filling
> in pages for display.

... and that makes any use of printf impossible, what would explain why 
this code is there

[toc] | [prev] | [next] | [standalone]

#57919

On Thu, 05 Mar 2015 17:04:34 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 05/03/15 16:01, Anders Wegge Keller wrote:
> >   While porting the code for a rather large airport from SCO to Linux,
> > I've come across this example of "Which wheel do you want to reinvent
> > today?"
> >
> > char *pint(char *buf, int len, int val) {
> >      int dval;
> >
> >      for (len--; len >= 0; len--) {
> >          dval = val % 10;
> >          val -= dval;
> >          buf[len] = (char)('0' + dval);
> >          val /= 10;
> >      }
> >      return buf;
> > }
> 
> Just out of curiosity, was the airport planning to null-terminate that 
> string at some point?

 The resulting buffer is used as input to the 400-line re-implementation of
sprintf(). So far I haven't found a place where the width of the destination
field have differed from the length passed to pint(). 



-- 
//Wegge

[toc] | [prev] | [next] | [standalone]

#57923

On 2015-03-05, Richard Heathfield <rjh@cpax.org.uk> wrote:
> On 05/03/15 16:01, Anders Wegge Keller wrote:
>>   While porting the code for a rather large airport from SCO to Linux, I've
>> come across this example of "Which wheel do you want to reinvent today?"
>>
>> char *pint(char *buf, int len, int val) {
>>      int dval;
>>
>>      for (len--; len >= 0; len--) {
>>          dval = val % 10;
>>          val -= dval;
>>          buf[len] = (char)('0' + dval);
>>          val /= 10;
>>      }
>>      return buf;
>> }
>
> Just out of curiosity, was the airport planning to null-terminate that 
> string at some point?

Yes; as soon as the control tower declared a runway for the pointer to land.

[toc] | [prev] | [next] | [standalone]

#57913

Anders Wegge Keller <wegge@geostat.dk> writes:

>  While porting the code for a rather large airport from SCO to Linux, I've
> come across this example of "Which wheel do you want to reinvent
> today?"

I feel your pain, but I don't think there's any existing wheel that is
quite as wonky as this!

> char *pint(char *buf, int len, int val) {
>     int dval;
>
>     for (len--; len >= 0; len--) {
>         dval = val % 10;
>         val -= dval;
>         buf[len] = (char)('0' + dval);
>         val /= 10;
>     }
>     return buf;
> }

I particularly like the cavalier attitude to negative numbers and the
silent truncation when val is large.  The pointless val -= dval is a
nice touch too, as is keeping everyone wondering if there's a null byte
anywhere near buf[len].

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#57922

On 2015-03-05, Anders Wegge Keller <wegge@geostat.dk> wrote:
>  While porting the code for a rather large airport from SCO to Linux, I've
> come across this example of "Which wheel do you want to reinvent today?"
>
> char *pint(char *buf, int len, int val) {
>     int dval;
>
>     for (len--; len >= 0; len--) {
>         dval = val % 10;
>         val -= dval;
>         buf[len] = (char)('0' + dval);
>         val /= 10;
>     }
>     return buf;
> }

This converts a positive value to a decimal representation, right adjusted in
the given buffer, and either truncated or padded with zeros to fill the whole
buffer. Also, the buffer is not null-terminated.

It works regardless of the range of integer; if int is 128 bits,
it will work fine.

If I had these requirements for a function, I'd hardly write it differently.

You cannot do all of this this with a single call to sprintf.

It would be something like:

  #define min(a, b) ((a) < (b) ? (a) : (b))

  char digs[64]; /* ugly guess at the maximum digits needed */
  int dlen;

  snprintf(digs, sizeof digs, "%d", val); /* prepare digits */
  dlen = strlen(digs);

  if (dlen >= len) {
    memcpy(buf, digs + dlen - len, len);
  } else {
    memset(buf, '0', len);
    memcpy(buf + len - dlen, digs, dlen);
  }

This is already longer, less efficient, and breaks if int is so wide
that it overflows digs, resulting in left truncation.
It also requires on the C99 snprintf, which the original doesn't.

[toc] | [prev] | [next] | [standalone]

#57925

On Thu, 5 Mar 2015 17:01:09 +0100, Anders Wegge Keller
<wegge@geostat.dk> wrote:

> While porting the code for a rather large airport from SCO to Linux, I've
>come across this example of "Which wheel do you want to reinvent today?"
>
>char *pint(char *buf, int len, int val) {
>    int dval;
>
>    for (len--; len >= 0; len--) {
>        dval = val % 10;
>        val -= dval;
>        buf[len] = (char)('0' + dval);
>        val /= 10;
>    }
>    return buf;
>}
>
> The whole code base is filled with dubious constructs like this,
>encompassing a strange mix of programming paradigms, including what looks
>like an attempt at functional programming via RPC calls. This gem was the
>straw that broke the camel's back.

Actually, it's a very interesting function. It is a very minimalist
implementation of a zero-filled, right-justified fixed-width numeric
to character conversion field that seems to have no equivalent in the
standard library functions. It's only deficiency seems to be a
complete lack of documentation or comments about it's contract of
usage.

Assume we have an airport with a kiosk with flight arrival departure
information and we'd like to keep all the flight numbers as 4 digit
fixed width fields after the two-letter airline code. Let's also
assume the buffer is properly prepared before it's used: 

#include <stdio.h>
#include <string.h>

char *pint(char *buf, int len, int val) {
    int dval;

    for (len--; len >= 0; len--) {
        dval = val % 10;
        val -= dval;
        buf[len] = (char)('0' + dval);
        val /= 10;
    }
    return buf;
}

int main(void) {
	char buf[5] = {'1','1','1','1','\0'};
	size_t len;

	len = sizeof(buf) - 1 ;
	pint(buf, len, 42);
	printf("Galactic Airlines GA%s\n", buf); 
	pint(buf, len, 0xa);
	printf("Hexadecimal Air   HA%s\n", buf); 
	return 0;
}

I'll bet it would work nicely with radar transponder codes too
although they might already have been converted to fixed-width
zero-filled four-digit strings.

[toc] | [prev] | [next] | [standalone]

#57927

On 06/03/2015 07:14, Geoff wrote:

> Actually, it's a very interesting function. It is a very minimalist
> implementation of a zero-filled, right-justified fixed-width numeric
> to character conversion field that seems to have no equivalent in the
> standard library functions. It's only deficiency seems to be a
> complete lack of documentation or comments about it's contract of
> usage.
>
> Assume we have an airport with a kiosk with flight arrival departure
> information and we'd like to keep all the flight numbers as 4 digit
> fixed width fields after the two-letter airline code. Let's also
> assume the buffer is properly prepared before it's used:
>
> #include <stdio.h>
> #include <string.h>
>
> char *pint(char *buf, int len, int val) {
>      int dval;
>
>      for (len--; len >= 0; len--) {
>          dval = val % 10;
>          val -= dval;
>          buf[len] = (char)('0' + dval);
>          val /= 10;
>      }
>      return buf;
> }
>
> int main(void) {
> 	char buf[5] = {'1','1','1','1','\0'};
> 	size_t len;
>
> 	len = sizeof(buf) - 1 ;
> 	pint(buf, len, 42);
> 	printf("Galactic Airlines GA%s\n", buf);
> 	pint(buf, len, 0xa);
> 	printf("Hexadecimal Air   HA%s\n", buf);
> 	return 0;
> }

The bigger question is why use C for such an application, when there are 
so many more apt languages to do this stuff.

But even in C, what is wrong with:

	printf("Galactic Airlines GA%04d\n", 42);

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#57932

On Fri, 06 Mar 2015 10:41:57 +0000, Bartc <bc@freeuk.com> wrote:

>On 06/03/2015 07:14, Geoff wrote:
>
>> Actually, it's a very interesting function. It is a very minimalist
>> implementation of a zero-filled, right-justified fixed-width numeric
>> to character conversion field that seems to have no equivalent in the
>> standard library functions. It's only deficiency seems to be a
>> complete lack of documentation or comments about it's contract of
>> usage.
>>
>> Assume we have an airport with a kiosk with flight arrival departure
>> information and we'd like to keep all the flight numbers as 4 digit
>> fixed width fields after the two-letter airline code. Let's also
>> assume the buffer is properly prepared before it's used:
>>
>> #include <stdio.h>
>> #include <string.h>
>>
>> char *pint(char *buf, int len, int val) {
>>      int dval;
>>
>>      for (len--; len >= 0; len--) {
>>          dval = val % 10;
>>          val -= dval;
>>          buf[len] = (char)('0' + dval);
>>          val /= 10;
>>      }
>>      return buf;
>> }
>>
>> int main(void) {
>> 	char buf[5] = {'1','1','1','1','\0'};
>> 	size_t len;
>>
>> 	len = sizeof(buf) - 1 ;
>> 	pint(buf, len, 42);
>> 	printf("Galactic Airlines GA%s\n", buf);
>> 	pint(buf, len, 0xa);
>> 	printf("Hexadecimal Air   HA%s\n", buf);
>> 	return 0;
>> }
>
>The bigger question is why use C for such an application, when there are 
>so many more apt languages to do this stuff.
>

C was the language chosen at the time the code was written. I'd like
to know what languages you think might be appropriate. The OP is
obviously involved in either a re-write or a conversion of the legacy
code and may enlighten us but anything we say here is pure
speculation. I was offering one such speculation and admiring the
offered function for what it was, simple, concise, free-standing.

For reasons unknown to us the original author of the code had a reason
for avoiding the printf family. I'd love to know why.

>But even in C, what is wrong with:
>
>	printf("Galactic Airlines GA%04d\n", 42);

It's wrong for the simple reason it fails to adhere to the functional
specification. It prints a _minimum_ of four digits, not _precisely_
four digits. Your solution malfunctions when offered more than a
four-digit decimal number such as 19999. The original code prints
precisely the specified number of digits of the length argument and no
more and therefore cannot "malfunction" in the manner of your
solution. Please try again.

[toc] | [prev] | [next] | [standalone]

#57933

On 06/03/2015 16:03, Geoff wrote:
> On Fri, 06 Mar 2015 10:41:57 +0000, Bartc <bc@freeuk.com> wrote:
>
>> On 06/03/2015 07:14, Geoff wrote:

>>> char *pint(char *buf, int len, int val) {

>>> int main(void) {
>>> 	char buf[5] = {'1','1','1','1','\0'};
>>> 	size_t len;
>>>
>>> 	len = sizeof(buf) - 1 ;
>>> 	pint(buf, len, 42);
>>> 	printf("Galactic Airlines GA%s\n", buf);
>>> 	pint(buf, len, 0xa);
>>> 	printf("Hexadecimal Air   HA%s\n", buf);
>>> 	return 0;
>>> }
>>
>> The bigger question is why use C for such an application, when there are
>> so many more apt languages to do this stuff.
>>
>
> C was the language chosen at the time the code was written. I'd like
> to know what languages you think might be appropriate.

Scripting ones, which can make strings jump through hoops with virtually 
no effort.

>> But even in C, what is wrong with:
>>
>> 	printf("Galactic Airlines GA%04d\n", 42);
>
> It's wrong for the simple reason it fails to adhere to the functional
> specification. It prints a _minimum_ of four digits, not _precisely_
> four digits.

I understand the original function to print exactly len digits. In the 
example above, len is 4.

> Your solution malfunctions when offered more than a
> four-digit decimal number such as 19999.

So does the example with a buffer of 5 characters and a len value of 4.

  The original code prints
> precisely the specified number of digits of the length argument and no
> more and therefore cannot "malfunction" in the manner of your
> solution. Please try again.

I suspect the original function wasn't intended to be truncating 
numbers. But you can get the same behaviour with printf with a minor 
adjustment:

	printf("Galactic Airlines GA%04d\n", n % 9999);


-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#57939

On Friday, March 6, 2015 at 4:51:27 PM UTC, Bart wrote:
> 
> Scripting ones, which can make strings jump through hoops with virtually 
> no effort.
> 
I wrote some drivers in Perl. But I never used it enough to get really proficient.

It encourages the use of regular expressions. I know what they are, but they're too
difficult to enter first time without any errors, and they rapidly become too complicated
for the programmer to glance and say what they should do. So it's a little metaprogramming
exercise, otherwise known as soft coding.

Then if you want heavy duty string processing, you need a suffix tree, I've got a C
implementation. There might be one written in Perl, but if there is, it's probably an
interface to an underlying C implemetation.

[toc] | [prev] | [next] | [standalone]

#57963

On Friday, 6 March 2015 18:51:27 UTC+2, Bart  wrote:
> On 06/03/2015 16:03, Geoff wrote:
> 
> > The original code prints
> > precisely the specified number of digits of the length argument and no
> > more and therefore cannot "malfunction" in the manner of your
> > solution. Please try again.
> 
> I suspect the original function wasn't intended to be truncating 
> numbers. But you can get the same behaviour with printf with a minor 
> adjustment:
> 
> 	printf("Galactic Airlines GA%04d\n", n % 9999);
> 

If it was intended to truncate n value 12345 to 2345 then your minor 
adjustment fails, since it outputs 2346. Please try again. ;)

[toc] | [prev] | [next] | [standalone]

#57982

On Sat, 7 Mar 2015 07:59:03 -0800 (PST), Öö Tiib <ootiib@hot.ee>
wrote:

>On Friday, 6 March 2015 18:51:27 UTC+2, Bart  wrote:
>> On 06/03/2015 16:03, Geoff wrote:
>> 
>> > The original code prints
>> > precisely the specified number of digits of the length argument and no
>> > more and therefore cannot "malfunction" in the manner of your
>> > solution. Please try again.
>> 
>> I suspect the original function wasn't intended to be truncating 
>> numbers. But you can get the same behaviour with printf with a minor 
>> adjustment:
>> 
>> 	printf("Galactic Airlines GA%04d\n", n % 9999);
>> 
>
>If it was intended to truncate n value 12345 to 2345 then your minor 
>adjustment fails, since it outputs 2346. Please try again. ;)

Not so easy, finding a replacement operation in the standard library,
is it?

[toc] | [prev] | [next] | [standalone]

#57984

On 03/07/2015 07:22 PM, Geoff wrote:
> On Sat, 7 Mar 2015 07:59:03 -0800 (PST), �� Tiib <ootiib@hot.ee>
> wrote:
> 
>> On Friday, 6 March 2015 18:51:27 UTC+2, Bart  wrote:
>>> On 06/03/2015 16:03, Geoff wrote:
>>>
>>>> The original code prints
>>>> precisely the specified number of digits of the length argument and no
>>>> more and therefore cannot "malfunction" in the manner of your
>>>> solution. Please try again.
>>>
>>> I suspect the original function wasn't intended to be truncating 
>>> numbers. But you can get the same behaviour with printf with a minor 
>>> adjustment:
>>>
>>> 	printf("Galactic Airlines GA%04d\n", n % 9999);
>>>
>>
>> If it was intended to truncate n value 12345 to 2345 then your minor 
>> adjustment fails, since it outputs 2346. Please try again. ;)
> 
> Not so easy, finding a replacement operation in the standard library,
> is it?

What's so hard about replacing 9999 with 10000?
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#57987

On Sat, 07 Mar 2015 19:45:06 -0500, James Kuyper
<jameskuyper@verizon.net> wrote:

>On 03/07/2015 07:22 PM, Geoff wrote:
>> On Sat, 7 Mar 2015 07:59:03 -0800 (PST), ?? Tiib <ootiib@hot.ee>
>> wrote:
>> 
>>> On Friday, 6 March 2015 18:51:27 UTC+2, Bart  wrote:
>>>> On 06/03/2015 16:03, Geoff wrote:
>>>>
>>>>> The original code prints
>>>>> precisely the specified number of digits of the length argument and no
>>>>> more and therefore cannot "malfunction" in the manner of your
>>>>> solution. Please try again.
>>>>
>>>> I suspect the original function wasn't intended to be truncating 
>>>> numbers. But you can get the same behaviour with printf with a minor 
>>>> adjustment:
>>>>
>>>> 	printf("Galactic Airlines GA%04d\n", n % 9999);
>>>>
>>>
>>> If it was intended to truncate n value 12345 to 2345 then your minor 
>>> adjustment fails, since it outputs 2346. Please try again. ;)
>> 
>> Not so easy, finding a replacement operation in the standard library,
>> is it?
>
>What's so hard about replacing 9999 with 10000?

It's hard because

	printf("Galactic Airlines\tGA%04.*d\n", 4, 42 % 10000);

is not a general solution that matches the functionality of the
originally posted function. Now write a general solution accepting an
arbitrary length len.

[toc] | [prev] | [next] | [standalone]

#57992

On 08/03/2015 01:21, Geoff wrote:
> On Sat, 07 Mar 2015 19:45:06 -0500, James Kuyper
> <jameskuyper@verizon.net> wrote:
>
>> On 03/07/2015 07:22 PM, Geoff wrote:
>>> On Sat, 7 Mar 2015 07:59:03 -0800 (PST), ?? Tiib <ootiib@hot.ee>
>>> wrote:
>>>
>>>> On Friday, 6 March 2015 18:51:27 UTC+2, Bart  wrote:
>>>>> On 06/03/2015 16:03, Geoff wrote:
>>>>>
>>>>>> The original code prints
>>>>>> precisely the specified number of digits of the length argument and no
>>>>>> more and therefore cannot "malfunction" in the manner of your
>>>>>> solution. Please try again.
>>>>>
>>>>> I suspect the original function wasn't intended to be truncating
>>>>> numbers. But you can get the same behaviour with printf with a minor
>>>>> adjustment:
>>>>>
>>>>> 	printf("Galactic Airlines GA%04d\n", n % 9999);
>>>>>
>>>>
>>>> If it was intended to truncate n value 12345 to 2345 then your minor
>>>> adjustment fails, since it outputs 2346. Please try again. ;)
>>>
>>> Not so easy, finding a replacement operation in the standard library,
>>> is it?
>>
>> What's so hard about replacing 9999 with 10000?
>
> It's hard because
>
> 	printf("Galactic Airlines\tGA%04.*d\n", 4, 42 % 10000);
>
> is not a general solution that matches the functionality of the
> originally posted function.

It wouldn't be, because that function only does a small part of the job.

We're talking about making use of it in a way that is difficult enough 
to do with standard functions that warrants yet another custom 
number-to-string converter.

But the issue isn't number-to-string conversion, it's formatting.

> Now write a general solution accepting an
> arbitrary length len.

The printf call would be:

   printf("Galactic Airlines   GA%0*d\n", 4, 42 % 10000);

The 4 is easily replaced by len. The 10000 is trickier to parametise, 
and maybe that could be customised if you don't want to bring in the pow 
function or use a look-up table.

But I don't think it would look any worse than trying to make use of 
pint. Here's another approach, using a buffer like pint(), but using 
standard functions only:

    char buf[50];
    int len;
    int n,width;

    len = sizeof(buf) - 1 ;
    snprintf(buf, len, "%0d",123456);
//   snprintf(buf, len, "%0d",56);
    width=4;
    printf("Galactic Airlines GA%0*.*s.\n", width,width,buf);

Now it is necessary to separate 'len' from 'width', as they don't mean 
the same thing; the length of the buffer is not the same as the field 
width we need. And if the number being printed is likely to be longer 
than the field width, it is necessary to specify the width twice as 
shown above, for minimum and maximum widths.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web