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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#58002

On Sun, 08 Mar 2015 10:29:49 +0000, Bartc <bc@freeuk.com> wrote:

>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.

I don't think snprintf existed in 1991, or if it did, it was POSIX. I
know it wasn't in K&R C in 1988. I never used SCO so I don't know what
was available in that system at that time.

I admire Ben Bacarisse's version of it for it's simplicity.

If we were writing it today it might look like this but I still think
this is uglier than the original:

#include <stdio.h>

/* convert int to leading-zero-filled string */
/* assumes:                                  */
/* buf is nul-terminated array of char       */
/* len is length of buf - 1                  */
char *inttolzfstring(char *buf, size_t len, int val)
{
	unsigned i;

	unsigned width = 10;
	for (i = 1; i < len; i++)
		width *= 10;
	sprintf(buf, "%0*.*d", len, len, val % width);
	return buf;
}

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

	len = sizeof(buf) - 1 ;
	inttolzfstring(buf, len, 12345);
	printf("Galactic Airlines\tGA%s\n", buf);
	return 0;
}

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

#57981

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

>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);

As Anders pointed out, the input isn't allowed to overflow the widths
but the function nevertheless does truncate them if they do. This may
or may not have been intentional but without comments or documentation
we can't say for certain. Your solution still doesn't behave exactly
like the original, care to try again?

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

#57934

On Fri, 06 Mar 2015 08:03:49 -0800
Geoff <geoff@invalid.invalid> wrote:

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

> >> 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:

 The code in question is a part of the interface between the luggage sorting
system, and a high level system, that has the information about which
luggage tag goes to which spur line. So the assumption is off, but as a
guess, it's pretty good.
...

> >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.

 The code is written in the late nineties. It's an adaptation of the generic
control system, that was written in the start of that decade. Given the
realtime requirements of the system, and the hardware available at that
time, C was one of the few available options at that time. 

> 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.

 My rationale for posting the code, was to vent the frustration over working
with code that reinvents large parts of the standard library. As i wrote
elsewhere, there is also a 400-line function, that reimplements printf(). 

> 
> >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. 

 In this case, a simple sprintf() would have been enough. The range of input
values cannot overflow the widths.

-- 
//Wegge

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

#57936

On Fri, 6 Mar 2015 17:54:32 +0100, Anders Wegge Keller
<wegge@geostat.dk> wrote:

>On Fri, 06 Mar 2015 08:03:49 -0800
>Geoff <geoff@invalid.invalid> wrote:
>
>> On Fri, 06 Mar 2015 10:41:57 +0000, Bartc <bc@freeuk.com> wrote:
>> 
>> >On 06/03/2015 07:14, Geoff wrote:
>
>> >> 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:
>
> The code in question is a part of the interface between the luggage sorting
>system, and a high level system, that has the information about which
>luggage tag goes to which spur line. So the assumption is off, but as a
>guess, it's pretty good.
>...

I had imagined it was something like that... an embedded application
with some kind of need for fixed-length fields. A numeric display on
an LCD for instance.

>
>> >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.
>
> The code is written in the late nineties. It's an adaptation of the generic
>control system, that was written in the start of that decade. Given the
>realtime requirements of the system, and the hardware available at that
>time, C was one of the few available options at that time. 
>

Now, they'd be putting it on Windows and putting pretty graphics on
it, probably touch-screens too. But I can remember a CNC control
running OS2 and a touch screen in 1996. 

>> 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.
>
> My rationale for posting the code, was to vent the frustration over working
>with code that reinvents large parts of the standard library. As i wrote
>elsewhere, there is also a 400-line function, that reimplements printf(). 
>

Well, the Linux printf and its supporting functions are pushing 300
LOC and they depend on other library functions like puts, putchar, so
the sum of all that is approaching 400 LOC, I'm sure. Add support for
vsnprintf & friends and you've got 1500+ LOC. 

Apparently your predecessor was a roll-your-own kind of programmer who
preferred having his library source exposed rather than simply
imported from his compiler vendor. I suspect he was using an available
tool chain of that era and the library was not tooled for his platform
so he had to write it. 

Been there, done that. In 1991 I was writing an RTOS on the Z80 using
a cross-compiler on a 486 or Pentium PC and had to write some pretty
strange stuff, including my own sbrk function. It was a pretty
frustrating time since compiler vendors often charged big money for
their library sources and if you needed to fix or get the library to
conform you either paid up for support or rolled your own.

>> 
>> >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. 
>
> In this case, a simple sprintf() would have been enough. The range of input
>values cannot overflow the widths.

I didn't expect they would. The code you posted had that implied in
its implementation. Nevertheless, the pint function is remarkable in
the way it goes about confining its output to the specified, and
variable, length. Doing it with printf, you're either hard coding
format strings as above or massaging numbers in preparation.

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

#57949

On 3/6/15 1:14 AM, 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.

A minimalist implementation might look more like this:

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

-- 
Morris Dovey

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

#57952

Morris Dovey <mrdovey@iedu.com> writes:

> On 3/6/15 1:14 AM, 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.
>
> A minimalist implementation might look more like this:
>
> char *pint(char *buf, int len, int val)
> {  for (len--; len >= 0; len--)
>    {  buf[len] = (char)('0' + val % 10);
>       val /= 10;
>    }
>    return buf;
> }

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

-- 
Ben.

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

#58857

Morris Dovey <mrdovey@iedu.com> writes:

> On 3/6/15 1:14 AM, 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.
>
> A minimalist implementation might look more like this:
>
> char *pint(char *buf, int len, int val)
> {  for (len--; len >= 0; len--)
>    {  buf[len] = (char)('0' + val % 10);
>       val /= 10;
>    }
>    return buf;
> }

I would call that a common or conventional implementation.

A really minimalist implementation should look more like this
(please disregard differences in lexical style):

    char *
    pint( char b[], int const n, int const v ){
        return  n > 0  ?  b[n-1] = '0' + v%10,  pint( b, n-1, v/10 )  :  b;
    }

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

#57928

On 3/5/15 11:01 AM, 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;
> }
>
>   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.
>

I will have to say that I have built functions like that in my code, and 
in some applications it is very justified.

Much of my code ends up in embedded processors with limited resources 
and are multi-threaded with real time requirements. In many cases the 
solution of "use printf and friends" is not applicable. The printf 
family is a monster, it can pull in a lot of library code (like the 
floating point library, though some platforms will allow you to use a 
downgraded version that omits floating point). It can also you a lot of 
stack space and may not be thread safe.

Having a few functions like this instead of printf may be a big win for 
the application size.

Now, in your case, if you are running under a "real" operating system, 
you likely have a lot more resources so this shouldn't be an issue.

One big question is "How old is this code base?", I could see that there 
could be pieces old enough in there that it predates being on a bigger 
processor and you may be seeing remnants of the space saving I was 
talking about. If it is really old, it could that some of what you think 
of as "standard", weren't practically available (sprintf goes back a 
long ways, but some of the early versions gave you reasons to want to 
use something else if practical).

The mix of paradigms is a likely indicator of this too, it probably has 
gone through a bunch of hands, and unless you are really going to go 
through and rewrite the whole thing, you may well add another one or two 
to the mix.

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

#57929

Richard Damon wrote:
> On 3/5/15 11:01 AM, 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;
>> }
>>
>>   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.
>>
>
> I will have to say that I have built functions like that in my code, and
> in some applications it is very justified.
>
> Much of my code ends up in embedded processors with limited resources
> and are multi-threaded with real time requirements. In many cases the
> solution of "use printf and friends" is not applicable. The printf
> family is a monster, it can pull in a lot of library code (like the
> floating point library, though some platforms will allow you to use a
> downgraded version that omits floating point). It can also you a lot of
> stack space and may not be thread safe.
>


In general, if the thing is small enough to worry about these issues,
thread safety should not be at issue ( all operation should be 
run-to-completion ). You're mainly defending the main
loop from the ISRs and there's just no good way to do that except 
manually - you have to enforce consumer/producer relationships in
a manner that is tractable by inspection.

Hoisting in mass quantities of code is a real problem, but  it's
something you can measure for. And it's been a long time since having
to have the floating point library was a problem for me
personally.

As ... hazardous as floating point is, it can also be frequently more 
correct than fixed point and easier to read.

> Having a few functions like this instead of printf may be a big win for
> the application size.
>

It certainly can be.

> Now, in your case, if you are running under a "real" operating system,
> you likely have a lot more resources so this shouldn't be an issue.
>
> One big question is "How old is this code base?", I could see that there
> could be pieces old enough in there that it predates being on a bigger
> processor and you may be seeing remnants of the space saving I was
> talking about. If it is really old, it could that some of what you think
> of as "standard", weren't practically available (sprintf goes back a
> long ways, but some of the early versions gave you reasons to want to
> use something else if practical).
>

I am thinking that in this case the suite of routines surrounding atoi() 
and itoa() should be enough to get things done. That would be my
starting place, anyway.

atoi() & itoa() proper are deprecated and there are
replacements for them.

Still, there are basic style issues with the shown example. It's
relatively hard to understand - not in a despair inducing way,
more like a "rock in your shoe" way.

> The mix of paradigms is a likely indicator of this too, it probably has
> gone through a bunch of hands, and unless you are really going to go
> through and rewrite the whole thing, you may well add another one or two
> to the mix.

-- 
Les Cargill

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

#57930

Les Cargill <lcargill99@comcast.com> writes:
[...]
> I am thinking that in this case the suite of routines surrounding
> atoi() and itoa() should be enough to get things done. That would be
> my starting place, anyway.
>
> atoi() & itoa() proper are deprecated and there are
> replacements for them.

In what sense are they deprecated?

itoa() is not defined by the C (or POSIX) standard, and does not appear
to exist on my system.

atoi() is defined by the C standard, which says nothing about it being
deprecated or obsolescent.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#57945

On 3/6/15 9:17 AM, Les Cargill wrote:
> Richard Damon wrote:
>>
>> Much of my code ends up in embedded processors with limited resources
>> and are multi-threaded with real time requirements. In many cases the
>> solution of "use printf and friends" is not applicable. The printf
>> family is a monster, it can pull in a lot of library code (like the
>> floating point library, though some platforms will allow you to use a
>> downgraded version that omits floating point). It can also you a lot of
>> stack space and may not be thread safe.
>>
>
>
> In general, if the thing is small enough to worry about these issues,
> thread safety should not be at issue ( all operation should be
> run-to-completion ). You're mainly defending the main
> loop from the ISRs and there's just no good way to do that except
> manually - you have to enforce consumer/producer relationships in
> a manner that is tractable by inspection.
>

Small doesn't mean limited requirements. I often don't HAVE a "main 
loop", but the main function initializes the hardware and starts up a 
set of real-time tasks and then disappears. Each piece has its set of 
responsibilities and requirements.

ISRs handle the things that need to be done quick (order of 
microseconds). If an interrupt needs to do something longer, it queue 
the work to a task setup for it.

High priority tasks handle quick light weight operations that have tight 
time limits (fractions of a millisecond to a few milliseconds). These 
tasks may need to prepare log messages that are queued up for logging 
(the actual logging may be too slow to be done here). These messages may 
need some simple formatting.

Lower priority tasks handle operations that take longer, and have more 
time allowed (some may not even have a actual deadline).

You can define these tasks with well defined interfaces, and be able to 
show you have handled the various data interactions. The problem comes 
that the C language "runtime" wasn't defined in an era when 
multi-tasking was common, some parts are inherently NOT thread safe, and 
much more might be able to be made thread safe but might not be by 
default (things like errno). It turns out that printf often falls into 
this category.

Using small, inherently thread safe, formatting routines can be a win 
here for showing your code is correct.

> Hoisting in mass quantities of code is a real problem, but  it's
> something you can measure for. And it's been a long time since having
> to have the floating point library was a problem for me
> personally.
>
> As ... hazardous as floating point is, it can also be frequently more
> correct than fixed point and easier to read.
>

It very much depends on the problem domain. Sometimes there really isn't 
any math, so floating point doesn't even enter the picture. If your 
machine doesn't have hardware support for floating point, sometimes the 
cost to use it get very large. The speed difference between building 
things on 16 bit math (with 16x16=>32 bit multiply, normally followed by 
a 32/16 => 16 divide), with direct hardware support, vs even 32 bit 
longs needed multiple precision adds and multiplies and shift loops to 
normalize the results is major.

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

#57940

On Friday, March 6, 2015 at 1:34:51 PM UTC, Richard Damon wrote:
>
>The printf family is a monster, it can pull in a lot of library code (like the 
> floating point library, though some platforms will allow you to use a 
> downgraded version that omits floating point).
>
You needs %s and %d, maybe the odd %c, if the program isn't going to report
numerical results to the user. That's easy enough to write in a medium-length
function. If you support all the flags, widths, and do a really solid job on
floating point, it turns into quite a task. 

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

#57941

Malcolm McLean wrote:
> On Friday, March 6, 2015 at 1:34:51 PM UTC, Richard Damon wrote:
>>
>> The printf family is a monster, it can pull in a lot of library code (like the
>> floating point library, though some platforms will allow you to use a
>> downgraded version that omits floating point).
>>
> You needs %s and %d, maybe the odd %c, if the program isn't going to report
> numerical results to the user. That's easy enough to write in a medium-length
> function. If you support all the flags, widths, and do a really solid job on
> floating point, it turns into quite a task.

I concur.  I've often used a stripped down version of printf in resource 
constrained environments.  Start with little more than a puts wrapper 
and only add the comparisons the project needs.  Such projects seldom 
use floating point.

-- 
Ian Collins

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

#57937

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) {

I would change the name.  The function has nothing to do with beer.

-- 
Ian Collins

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

#57938

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

>  While porting the code for a rather large airport from SCO to Linux,

Not Schiphol, then; the signs there have been known to show Windows
BSODs.

Richard

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

#57942

On Thursday, March 5, 2015 at 8:16:48 AM UTC-8, 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;
> }
> 
>  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.

Most coding in C is an effort to remedy perceived deficiencies in the standard library. The big advantage of C is that you *CAN* do it.
You need an input format that isn't exactly free form text or a decimal, hex, or octal number? You need an output format that isn't exactly dropping characters into a number for readability? And the maximum killer: Expression localization where the variables might appear in a different order. Some "standard" libraries even help you out with the last one. But, good luck getting close otherwise.

In the above code would you prefer that the code use a standard function and then go to work on the results of that? Yes, if it had been written in 2010, that's what would have been done.
In an era when 4 MB was a lot of memory, 8 MHz was a fast processor, and an 80 MB hard drive was a dream, people often did things "for efficiency" that no one would DREAM of doing today.

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

#58021

On Thursday, March 5, 2015 at 11:16:48 AM UTC-5, Anders Wegge Keller wrote:

>  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.

I have no joke here, but I'd like to point out that the 2009 Underhanded C
Contest was to write bad luggage handling code:

http://underhanded-c.org/_page_id_22.html

The goal was to design the code so that a weird comment field would 
re-route an unruly customer's luggage to the wrong place by "accident."
Many of the entries took advantage of ambiguity in string termination.

So if you ever get frustrated with horrible C code to manage a real 
airport, you can always take a break and look at a simulation of the same
thing.

--S

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

#58032

On Mon, 9 Mar 2015 08:52:33 -0700 (PDT)
Xcott Craver <xcottcraver@gmail.com> wrote:

> On Thursday, March 5, 2015 at 11:16:48 AM UTC-5, Anders Wegge Keller wrote:
> 
> >  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.
> 
> I have no joke here, but I'd like to point out that the 2009 Underhanded C
> Contest was to write bad luggage handling code:
> 
> http://underhanded-c.org/_page_id_22.html
> 
> The goal was to design the code so that a weird comment field would 
> re-route an unruly customer's luggage to the wrong place by "accident."
> Many of the entries took advantage of ambiguity in string termination.
> 
> So if you ever get frustrated with horrible C code to manage a real 
> airport, you can always take a break and look at a simulation of the same
> thing.

Don't get me started...

 * "What do you mean 'You cannot check in 187 bags at this flight'?" [1]
 * External systems infinitely retrying with the same message on a NACK. [2]
 * Destination redirects within the critical 50ms time window. [3]

1. A tour guide checking in all bags for the entire party. The system
   kaboomed over the ensuing buffer overflow.

2. The IATA standard for information about flights is a key-value system,
   encoded as key/value/key/value/... For some reason the flight planning
   system at one airport was sending N/A when a Gate wasn't yet planned. And
   when it got a NACK on that telegram, it resent it infinitely.

3. An item being re-routed at the same time where a destination unavailable
   message was received from the lower level. As the upper level control did
   not expect that reply, no further actions took place. Even though the
   critical window was <50ms, it happened 5-10 times a month. 

 Working in aftersales/L2 hotline/EOL support bring up all kind of corner
cases. Long time ago, I decided that contributing bugs that I've found and
fixed to the IOCCC would be unethical. But maybe I should start collecting
notes, and write a book when I retire.
-- 
//Wegge

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

#58033

On 2015-03-09, Anders Wegge Keller <wegge@geostat.dk> wrote:
> 2. The IATA standard for information about flights is a key-value system,
>    encoded as key/value/key/value/... For some reason the flight planning
>    system at one airport was sending N/A when a Gate wasn't yet planned. And
>    when it got a NACK on that telegram, it resent it infinitely.

You mean the N/A was literally marshaled as a value in that silly
slash-delimited format, with no escaping, thus screwing the syntax?

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

#58034

On Mon, 9 Mar 2015 20:16:41 +0000 (UTC)
Kaz Kylheku <kaz@kylheku.com> wrote:

> On 2015-03-09, Anders Wegge Keller <wegge@geostat.dk> wrote:
> > 2. The IATA standard for information about flights is a key-value system,
> >    encoded as key/value/key/value/... For some reason the flight planning
> >    system at one airport was sending N/A when a Gate wasn't yet planned.
> > And when it got a NACK on that telegram, it resent it infinitely.
> 
> You mean the N/A was literally marshaled as a value in that silly
> slash-delimited format, with no escaping, thus screwing the syntax?

 Yes. And that airport reminds me of brainfart #4:

 IATA fallback-tags. A proper IATA bag tag is a 10-digit number starting
with 1. All others are designated as fallback, subject to local
interpretation. At the same airport, a regional carrier had the habit of
using the same fallback on each and every bag. That was all fine, because
the fallback tag got rerouted to a manual handling station, where the
destination would be entered. Until the day, where the Ops people noted that
it would be an improvement "If a manually coded FB tag could be entered in
the system, so the operators at [other terminal] don't have to code it
again." And thus, one day all luggage for people travelling with said local
carrier was rerouted to Kinshasa.

-- 
//Wegge

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web