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

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

The portability sacred cow

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

Contents

  The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-20 23:14 +0200
    Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-20 23:34 +0200
      Re: The portability sacred cow Geoff <geoff@invalid.invalid> - 2014-04-20 21:20 -0700
        Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-21 04:35 +0000
        Re: The portability sacred cow Kaz Kylheku <kaz@kylheku.com> - 2014-04-21 05:10 +0000
          Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-21 05:31 +0000
          Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-20 23:50 -0700
    Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-20 23:39 +0200
    Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-20 23:37 -0700
      Re: The portability sacred cow Ian Collins <ian-news@hotmail.com> - 2014-04-21 20:25 +1200
    Re: The portability sacred cow glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-21 07:10 +0000
    Re: The portability sacred cow Ian Collins <ian-news@hotmail.com> - 2014-04-21 20:32 +1200
    Re: The portability sacred cow David Brown <david.brown@hesbynett.no> - 2014-04-21 16:46 +0200
      Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-21 10:04 -0700
        Re: The portability sacred cow David Brown <david.brown@hesbynett.no> - 2014-04-21 21:02 +0200
    Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 02:52 -0700
      Re: The portability sacred cow Ian Collins <ian-news@hotmail.com> - 2014-04-22 23:18 +1200
        Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-22 11:49 +0000
      Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 14:48 +0200
      Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-22 14:58 +0100
        Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 07:37 -0700
      Re: The portability sacred cow luser droog <luser.droog@gmail.com> - 2014-04-22 21:52 -0700
    Re: The portability sacred cow Johannes Bauer <dfnsonfsduifb@gmx.de> - 2014-04-22 16:58 +0200
      Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 17:24 +0200
        Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 17:25 +0200
      Re: The portability sacred cow Gareth Owen <gwowen@gmail.com> - 2014-04-22 19:11 +0100
    Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-22 21:59 +0200
      Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-22 14:02 -0700
        Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-23 01:04 +0200
          Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-22 17:52 -0700
            Re: The portability sacred cow <william@wilbur.25thandClement.com> - 2014-04-22 19:15 -0700
        Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-23 01:10 +0200
        Re: The portability sacred cow Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-23 09:53 +0200
          Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-25 02:21 +0000
            Re: The portability sacred cow JohnF <john@please.see.sig.for.email.com> - 2014-04-25 06:36 +0000
              Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-25 14:02 +0200
              Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-25 18:17 +0000
                Re: The portability sacred cow Kaz Kylheku <kaz@kylheku.com> - 2014-04-25 18:27 +0000
                  Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-25 21:57 -0700
                    Re: The portability sacred cow Stephen Sprunk <stephen@sprunk.org> - 2014-04-26 00:02 -0500
                    Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-26 11:35 +0200
                  Re: The portability sacred cow JohnF <john@please.see.sig.for.email.com> - 2014-04-26 06:04 +0000
                Re: The portability sacred cow jacob navia <jacob@spamsink.net> - 2014-04-25 23:08 +0200
                  Re: The portability sacred cow glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-25 21:52 +0000
            Re: The portability sacred cow Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-25 11:27 +0200
              Re: The portability sacred cow Richard <rgrdev_@gmail.com> - 2014-04-25 14:03 +0200
                Re: The portability sacred cow gazelle@shell.xmission.com (Kenny McCormack) - 2014-04-25 18:18 +0000
                Re: The portability sacred cow "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-26 20:04 -0400
              Re: The portability sacred cow Malcolm McLean <malcolm.mclean5@btinternet.com> - 2014-04-25 06:05 -0700
                Re: The portability sacred cow Thomas Jahns <jahns@idontlikespam.dkrz.de> - 2014-04-25 17:43 +0200
                  Re: The portability sacred cow Keith Thompson <kst-u@mib.org> - 2014-04-25 10:48 -0700

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

#43189 — The portability sacred cow

If there is a common sacred cow in this newsgroup it is the 
"portability" sacred cow.

In the name of it everything will be accepted. Portability means in this 
context, let's take the worst system around, and make it the common 
base. Reject all the improvements that other software contexts offer and 
just use the worst. This will guarantee that your code runs everywhere

Now, there is no free lunch and the portability crazyness has some 
obvious costs.

For instance, OpenBSD has a function free() that is security conscious 
and erases the freed memory before reuse. This would have stopped the 
heartbleed bug in OpenSSL but it wasn't used.

Why?

Because some systems had a very slow "malloc" function and the OpenSSL 
team decided to write their own malloc/free replacements. Also in the 
name of portability, all kinds of cruft was left cluttering the code to 
cater systems like VMS, for instance, that nobody uses today.

Because, portability has a REAL COST, in terms of levelling by the lower 
common denominator, making for a conservative attitude (that fits this 
newsgroup very well) that hinders progress in software development and 
provokes all kinds of cruft to be added to ALL implementation of a 
software to cater for the bug of some system.

Portability should be weighted with USABILITY and STABILITY, two things 
that we never discuss since they tend to be non portable :-)

In my opinion, portability comes AFTER STABILITY and USABILITY, well 
after those.

jacob

[toc] | [next] | [standalone]

#43196

Le 20/04/2014 23:25, Stefan Ram a écrit :
> What they did was (apparently, and according to your report)
>    in the name of/efficiency/, not portability.

No. There were systems that had a bad malloc. To be portable to those 
systems without unacceptable efficiency considerations they rewrote 
malloc. To port to bad systems was the basic motivation.

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

#43208

On Sun, 20 Apr 2014 23:34:59 +0200, jacob navia <jacob@spamsink.net>
wrote:

>Le 20/04/2014 23:25, Stefan Ram a écrit :
>> What they did was (apparently, and according to your report)
>>    in the name of/efficiency/, not portability.
>
>No. There were systems that had a bad malloc. To be portable to those 
>systems without unacceptable efficiency considerations they rewrote 
>malloc. To port to bad systems was the basic motivation.

So, there were systems that had a "bad implementation of malloc",
therefore the OpenSSL team wrote their own bad implementation of
malloc and free, neglected to keep security paramount in their
implementation and didn't properly review and test their
implementation. This is not a "portability" problem.

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

#43209

In article <tr69l999qclen6cak599plqr0grb48v9jm@4ax.com>,
Geoff  <geoff@invalid.invalid> wrote:
>On Sun, 20 Apr 2014 23:34:59 +0200, jacob navia <jacob@spamsink.net>
>wrote:
>
>>Le 20/04/2014 23:25, Stefan Ram a écrit :
>>> What they did was (apparently, and according to your report)
>>>    in the name of/efficiency/, not portability.
>>
>>No. There were systems that had a bad malloc. To be portable to those 
>>systems without unacceptable efficiency considerations they rewrote 
>>malloc. To port to bad systems was the basic motivation.
>
>So, there were systems that had a "bad implementation of malloc",
>therefore the OpenSSL team wrote their own bad implementation of
>malloc and free, neglected to keep security paramount in their
>implementation and didn't properly review and test their
>implementation. This is not a "portability" problem.

It is, when you get right down to it.  But I don't expect the trolls of CLC
to get it.  Or to ever admit that Jacob might have a valid point.

The point is that user-written stuff isn't ever as good as system-written
stuff (Yes, there are exceptions to this - but they are rare enough to not
be of interest to anyone - other than a CLC troll).  So, what Jacob is
saying is that they needlessly re-invented the wheel and the result was as
expected (by those of us who know and expect such things).  Essentially,
they fell victim to the "Not Invented Here" syndrome.

As an aside, note that the only CLC-acceptable, portable, way to introduce a
delay in a program is like this:

    for (i=1; i<=VERYBIGNUMBER; i++);

(And then, of course, you have to figure out a way to make sure this
doesn't get optimized away.  But I digress...)

-- 
"Every time Mitt opens his mouth, a swing state gets its wings."

(Should be on a bumper sticker)

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

#43210

On 2014-04-21, Geoff <geoff@invalid.invalid> wrote:
> On Sun, 20 Apr 2014 23:34:59 +0200, jacob navia <jacob@spamsink.net>
> wrote:
>
>>Le 20/04/2014 23:25, Stefan Ram a écrit :
>>> What they did was (apparently, and according to your report)
>>>    in the name of/efficiency/, not portability.
>>
>>No. There were systems that had a bad malloc. To be portable to those 
>>systems without unacceptable efficiency considerations they rewrote 
>>malloc. To port to bad systems was the basic motivation.
>
> So, there were systems that had a "bad implementation of malloc",
> therefore the OpenSSL team wrote their own bad implementation of
> malloc and free, neglected to keep security paramount in their
> implementation and didn't properly review and test their
> implementation. This is not a "portability" problem.

There is always:

  #if CONFIG_USE_XMALLOC
  void *xmalloc(size_t size); /* use ours */
  #else
  #define xmalloc malloc /* don't use ours */
  #endif

Unconditionally using your custom malloc everywhere because there is
something wrong with some mallocs is silly. (Is that really
the case in OpenSSL?)

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

#43213

In article <20140420220758.445@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> wrote:
...
>There is always:
>
>  #if CONFIG_USE_XMALLOC
>  void *xmalloc(size_t size); /* use ours */
>  #else
>  #define xmalloc malloc /* don't use ours */
>  #endif
>
>Unconditionally using your custom malloc everywhere because there is
>something wrong with some mallocs is silly.

It can be a real problem.  They had this problem with GAWK for quite a
while, in re: the strftime() function.  I don't know if they still do, so
this information may be out-of-date.  But anyway...

The GAWK distribution contains its own implementation of strftime(), which
is better (in some ways) and worse (in others) than some of the "built-in"
implementations of strftime().  Which one to use was often a non-trivial
question.  The config (autoconf) script attempted to guess, but wasn't
always right (since it wasn't clear that there [always] was a "right" answer).
In particular, on some systems, the distribution-supplied version didn't do
DST calculatons right, but did most other things better than the built-in
one.

I would imageine that much the same can be said of malloc() implementations.

>(Is that really the case in OpenSSL?)

Who knows?  Someone will have to actually research this and post here.
Until then, all we have is Jacob's word.

-- 
To most Christians, the Bible is like a software license. Nobody 
actually reads it. They just scroll to the bottom and click "I agree."

	- author unknown -

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

#43216

Kaz Kylheku <kaz@kylheku.com> wrote:
<snip>
> Unconditionally using your custom malloc everywhere because there is
> something wrong with some mallocs is silly. (Is that really
> the case in OpenSSL?)

Yes. The OpenBSD developers found out that it was impossible to disable the
custom allocator because some internal code evolved to depend on its
behavior. By disabling it you triggered several more bugs in OpenSSL, which
implies none of the mainline developers ever seriously bothered trying to
disable it.

See http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf

OpenBSD is forking OpenSSL in their base and cleaning up the code, including
changing the code formatting from its horrid style to traditional KNF, and
refactoring and auditing string and buffer management.

You can follow the play-by-play at http://opensslrampage.org/

Unfortunately, their version won't be portable as-is because they rely on
some of the saner semantics of their libc, such as a reliable snprintf, a
calloc which does overflow detection, etc. They ripped out OpenSSL's CSPRNG,
which now just forwards to arc4random_buf (which is actually based on a
DJB's ChaCha-20 stream cipher now).

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

#43197

Le 20/04/2014 23:25, Stefan Ram a écrit :
> No one forbids you to write programs for a specific platform,
>    OpenBSD, Windows, Android. Many people did just this and got rich.

Yes, but any mention of code specific to a single system (or to a family 
of systems like Unix/windows) is answered with:

go to another discussion group (windows/Posix, whatever)
Not portable, can't discuss here

etc

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

#43214

jacob navia <jacob@spamsink.net> wrote:
<snip>
> Because some systems had a very slow "malloc" function and the OpenSSL 
> team decided to write their own malloc/free replacements.

Well, Windows was notorious for it's slow malloc. Still is, AFAIK. But
that's kind of beside the point, 'cause nobody should be substituting malloc
that way throughout their entire application specfically because of the
attack mitigation measures that have become popular. Also because allocators
these days will return memory to the OS.

> Also in the name of portability, all kinds of cruft was left cluttering
> the code to cater systems like VMS, for instance, that nobody uses today.

Actually, there are plenty of VMS users today, and they have continued to
submit patches to OpenSSL up until this year. Whether it's worth maintaining
that port in the mainline code is another matter.
 
> Because, portability has a REAL COST, in terms of levelling by the lower 
> common denominator, making for a conservative attitude (that fits this 
> newsgroup very well) that hinders progress in software development and 
> provokes all kinds of cruft to be added to ALL implementation of a 
> software to cater for the bug of some system.
> 
> Portability should be weighted with USABILITY and STABILITY, two things 
> that we never discuss since they tend to be non portable :-)
> 
> In my opinion, portability comes AFTER STABILITY and USABILITY, well 
> after those.

In that case perhaps you should only use OpenBSD. They have nice features
like an async-signal-safe snprintf, whereas Linux snprintf uses heap memory
for the simplest formatting (which means you can't depend on it to never
fail, even when you know it shouldn't, which is why glibc's recommendation
to use snprintf instead of strlcpy is idiotic). And Windows _snprintf is
just a horror because it has all the wrong semantics.

OpenBSD puts a lot of effort into the small stuff, something that very few
other platforms bother with. And yet, nobody is advocating only targetting
OpenBSD. Linux and Windows are horrible targets if your primary concern is
security, because those platforms emphasize backwaard compatability and
performance more than OpenBSD. For example, OpenBSD just recently changed
time_t to 64-bits on all platforms, including 32-bits platforms. That would
be unthinkable on Windows or Linux.

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

#43220

william@wilbur.25thandClement.com wrote:
> jacob navia <jacob@spamsink.net> wrote:
>>
>> In my opinion, portability comes AFTER STABILITY and USABILITY, well
>> after those.
>
> In that case perhaps you should only use OpenBSD. They have nice features
> like an async-signal-safe snprintf, whereas Linux snprintf uses heap memory
> for the simplest formatting (which means you can't depend on it to never
> fail, even when you know it shouldn't, which is why glibc's recommendation
> to use snprintf instead of strlcpy is idiotic). And Windows _snprintf is
> just a horror because it has all the wrong semantics.

Or use Solaris/Illumos which has the same Async-Signal-Safe guarantee.

> OpenBSD puts a lot of effort into the small stuff, something that very few
> other platforms bother with. And yet, nobody is advocating only targetting
> OpenBSD. Linux and Windows are horrible targets if your primary concern is
> security, because those platforms emphasize backwaard compatability and
> performance more than OpenBSD.

Backwards compatibility and Linux in the same sentence, you jest??  A 
compiler writer told me porting their compilers between kernel revisions 
was almost as bad as porting between distributions.

> For example, OpenBSD just recently changed
> time_t to 64-bits on all platforms, including 32-bits platforms. That would
> be unthinkable on Windows or Linux.

I bet that broke a few things along the way.

-- 
Ian Collins

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

#43218

jacob navia <jacob@spamsink.net> wrote:

(snip)

> Because some systems had a very slow "malloc" function and the OpenSSL 
> team decided to write their own malloc/free replacements. Also in the 
> name of portability, all kinds of cruft was left cluttering the code to 
> cater systems like VMS, for instance, that nobody uses today.

There has been a lot of discussion about OpenSSL on the VMS newsgroup.

(By people actually running it.)

-- glen

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

#43221

jacob navia wrote:
> If there is a common sacred cow in this newsgroup it is the
> "portability" sacred cow.

<snip>

> Because, portability has a REAL COST, in terms of levelling by the lower
> common denominator, making for a conservative attitude (that fits this
> newsgroup very well) that hinders progress in software development and
> provokes all kinds of cruft to be added to ALL implementation of a
> software to cater for the bug of some system.
>
> Portability should be weighted with USABILITY and STABILITY, two things
> that we never discuss since they tend to be non portable :-)
>
> In my opinion, portability comes AFTER STABILITY and USABILITY, well
> after those.

I tend to agree, but there are degrees of portability that come at 
little cost.  As one who doesn't use Linux in production if I can help 
it, the fact that many open source projects care very little for 
portability makes porting some projects a real pain.

I do think that if more projects stuck to C99 and POSIX as portable 
specifications, (non-windows) developer's lives would be a lot easier.

-- 
Ian Collins

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

#43228

On 20/04/14 23:14, jacob navia wrote:

> For instance, OpenBSD has a function free() that is security conscious
> and erases the freed memory before reuse. This would have stopped the
> heartbleed bug in OpenSSL but it wasn't used.
>

That has no serious connection with the heartbleed bug.

(I am not disagreeing that making their own malloc/free is a bad idea, 
and I agree with you that obsessive portability is not good.)

First, if OpenBSD's free() would have been better than standard free() 
or OpenSSL's free(), then it would only have helped the Heartbleed bug 
on OpenBSD - not on the most commonly used platform (Linux).

Secondly, the problem was that the bug let an attacker read blocks of 
memory - while some of these areas might have been free'd, and therefore 
cleared if they had used OpenBSD's free(), lots of the rest of the space 
could still have been in use and still contain data.

At best, using OpenBSD's free() would have reduced the problem somewhat 
on a minor platform.  It would hardly have "stopped the heartbleed bug".

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

#43232

David Brown <david.brown@hesbynett.no> wrote:
> On 20/04/14 23:14, jacob navia wrote:
> 
>> For instance, OpenBSD has a function free() that is security conscious
>> and erases the freed memory before reuse. This would have stopped the
>> heartbleed bug in OpenSSL but it wasn't used.
> 
> That has no serious connection with the heartbleed bug.
> 
> (I am not disagreeing that making their own malloc/free is a bad idea, 
> and I agree with you that obsessive portability is not good.)
> 
> First, if OpenBSD's free() would have been better than standard free() 
> or OpenSSL's free(), then it would only have helped the Heartbleed bug 
> on OpenBSD - not on the most commonly used platform (Linux).

OpenBSD's mitigation measures have resulted in the silent remediation of
many such bugs in open source applications.

For example, when OpenBSD recently switched to a 64-bit time_t, many open
source applications broke. The ones which were caught were fixed in the
ports tree and patches submitted upstream.

(FWIW, I believe NetBSD beat OpenBSD to switching to a 64-bit time_t. The
same process would have happened in their ports tree, as well.)

> Secondly, the problem was that the bug let an attacker read blocks of 
> memory - while some of these areas might have been free'd, and therefore 
> cleared if they had used OpenBSD's free(), lots of the rest of the space 
> could still have been in use and still contain data.

OpenBSD has the ability to place a guard page after an allocated block, and
to align sub-page-sized allocations so that even a one-byte read overflow
hits the guard page and segfaults the application.

But to catch the heartbleed bug someone would have needed to fuzz the
protocol, and I'm unsure if anybody was doing that.

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

#43247

On 21/04/14 19:04, william@wilbur.25thandClement.com wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>> On 20/04/14 23:14, jacob navia wrote:
>>
>>> For instance, OpenBSD has a function free() that is security conscious
>>> and erases the freed memory before reuse. This would have stopped the
>>> heartbleed bug in OpenSSL but it wasn't used.
>>
>> That has no serious connection with the heartbleed bug.
>>
>> (I am not disagreeing that making their own malloc/free is a bad idea,
>> and I agree with you that obsessive portability is not good.)
>>
>> First, if OpenBSD's free() would have been better than standard free()
>> or OpenSSL's free(), then it would only have helped the Heartbleed bug
>> on OpenBSD - not on the most commonly used platform (Linux).
>
> OpenBSD's mitigation measures have resulted in the silent remediation of
> many such bugs in open source applications.

Perhaps - certainly zeroing out parts of memory that might be leaked 
would reduce the information leaked.  It will reduce the performance of 
the application too.  But zeroing free'd memory will not fix all 
problems (as noted below).

>
> For example, when OpenBSD recently switched to a 64-bit time_t, many open
> source applications broke. The ones which were caught were fixed in the
> ports tree and patches submitted upstream.

That's a completely different issue, with no connection to either 
malloc/free, OpenSSL, Heartbleed, or security leaks.  It is true that 
some applications use time_t in a way that depends on the size of the 
type - and it is fairly obvious that changing the size will therefore 
cause trouble with such applications.  It is a good thing for such code 
to be spotted and changed long before 2038 - and kudos to the OpenBSD 
community for working on that.  But there is no connection to Heartbleed 
here.

>
> (FWIW, I believe NetBSD beat OpenBSD to switching to a 64-bit time_t. The
> same process would have happened in their ports tree, as well.)
>
>> Secondly, the problem was that the bug let an attacker read blocks of
>> memory - while some of these areas might have been free'd, and therefore
>> cleared if they had used OpenBSD's free(), lots of the rest of the space
>> could still have been in use and still contain data.
>
> OpenBSD has the ability to place a guard page after an allocated block, and
> to align sub-page-sized allocations so that even a one-byte read overflow
> hits the guard page and segfaults the application.
>

That has all the pros and cons of tools such as Valgrind.  It will help 
spot errors (either "normal" bugs, or security holes) - but at a 
significant run-time cost.  The OpenSSL developers should have used 
tools like this during development and testing, and should have tested 
against malformed packets (a simple test aginst random data would have 
triggered this bug).


> But to catch the heartbleed bug someone would have needed to fuzz the
> protocol, and I'm unsure if anybody was doing that.
>

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

#43270

On Sunday, April 20, 2014 10:14:27 PM UTC+1, jacob navia wrote:
> If there is a common sacred cow in this newsgroup it is the
> "portability" sacred cow.
> 
> Portability should be weighted with USABILITY and STABILITY, two things 
> that we never discuss since they tend to be non portable :-)
> 
> In my opinion, portability comes AFTER STABILITY and USABILITY, well 
> after those.
> 
My view is that you need to separate programs into the bit-shuffling section and the the IO section.
Some parts of the program rearrange bits in memory, other parts manipulate output devices.

Any code that is interesting in a computer science, mathematical, logical, artistic or other sense
will be bit shuffling code. That should be written portably, there's no reason to use any non-portable
constructs, there's no reason to be interested in what type of processor you're running on. (OK,
I haven't addressed parallellisation and other forms of hardware acceleration, it's a general scheme).

The code that does IO is essentially a job for a hacker. It's not necessarily easy to write, but the 
difficulties aren't of a fundamental order. It's a case of one human understanding a system designed
by another human and knowing how to interact with it. A lot of it isn't portable, and portability means
something else. It means devising common interfaces, not agreeing on a common language for
specifying algorithms. 

Now what do we need to specify an algorithm? Essentially a human-usable Turing complete system.
A way of getting an arbitrary-sized memory buffer, a way of reading and writing to it, conditional
jumps, and, to make things usable, arithmetical and logical operations on scalars and a way of
dividing up code into human-meaningful units or modules . But that's it. Just a thin layer of syntax 
over these.
  

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

#43274

Malcolm McLean wrote:
>
> The code that does IO is essentially a job for a hacker.

Bullshit.

-- 
Ian Collins

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

#43278

In article <brn1g4F43uvU11@mid.individual.net>,
Ian Collins  <ian-news@hotmail.com> wrote:
>Malcolm McLean wrote:
>>
>> The code that does IO is essentially a job for a hacker.
>
>B******t.

Issues much?

Maybe you need to check into this:

    http://en.wikipedia.org/wiki/Anger_management

-- 
Both the  leader of  the Mormon  Church and the  leader of  the Catholic
church  claim infallibility.  Is it  any  surprise that  these two  orgs
revile each other?  Anybody with any sense knows that  80-yr old codgers
are hardly infallible. Some codgers this age do well to find the crapper
in time and remember to zip-up.

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

#43282

Le 22/04/2014 11:52, Malcolm McLean a écrit :
> Any code that is interesting in a computer science, mathematical, logical, artistic or other sense
> will be bit shuffling code.

When you see the big picture this is in general true.

Problem is, even there you need physical ressources that will change 
from machine to machine.

Can you read all your data into RAM at once?

Or should you redesign your algorithm to process in variable chunks to 
cater for the bad systems that do not have so much RAM?

Should you assume a floating point coprocessor?


Or should you use fixed point for representing your data?

Etc.

Decisions, decisions...

What I propose is to keep in mind those "portability" considerations but 
making them a secondary view AFTER the usability and stability issues 
are solved.

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

#43285

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Sunday, April 20, 2014 10:14:27 PM UTC+1, jacob navia wrote:
>> If there is a common sacred cow in this newsgroup it is the
>> "portability" sacred cow.
>> 
>> Portability should be weighted with USABILITY and STABILITY, two things 
>> that we never discuss since they tend to be non portable :-)
>> 
>> In my opinion, portability comes AFTER STABILITY and USABILITY, well 
>> after those.
>> 
> My view is that you need to separate programs into the bit-shuffling section and the the IO section.
> Some parts of the program rearrange bits in memory, other parts manipulate output devices.
>
> Any code that is interesting in a computer science, mathematical, logical, artistic or other sense
> will be bit shuffling code. That should be written portably, there's no reason to use any non-portable
> constructs, there's no reason to be interested in what type of processor you're running on. (OK,
> I haven't addressed parallellisation and other forms of hardware
> acceleration, it's a general scheme).

And there's also no reason whatsoever to think for one minute it needs
to be portable.

You do go on.

And IO is applicable to any "Computer Science" if not more so.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

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

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

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

csiph-web